Hva er fordelene med å bygge skript?

Automatisering.

Når du utvikler, er det bare i de mest enkle prosjektene vil standard «build» -knappen gjøre alt du trenger å gjøre; Det kan hende du må lage WS ut av API-er, generere dokumenter, koble til eksterne ressurser, distribuere endringene til en server osv. Noen IDE-er lar deg tilpasse byggeprosessen ved å legge til ekstra trinn eller byggere, men det betyr bare at du er generere build-skriptet ditt gjennom IDE-varene.

Men å utvikle et system er ikke bare å skrive kode. Det er flere trinn involvert. Et IDE-uavhengig skript kan kjøres automatisk, noe som betyr at:

• Når du foretar en endring i versjonskontroll, kan en ny versjon startes automatisk av serveren. Det vil sikre at du ikke har glemt å begå noe som trengs for byggingen.

• Tilsvarende, etter at byggingen er gjort, kan tester automatisk kjøres for å se om du har brutt noe.

• Nå har resten av organisasjonen (QA, sysadmins) et innebygd produkt som

  a) er perfekt reproduserbart bare fra kontrollversjonen.

  b) er felles for dem alle.

Selv når jeg har jobbet som et enmannsteam, har jeg brukt manus til det formålet; Da jeg hadde utviklet løsningen, ville jeg forplikte meg til SVN, eksportere SVN tilbake i en annen katalog og bruke build-skriptet til å generere løsningen, som deretter gikk til Preproduction-systemer og senere til Production. Hvis noen få uker senere (med min lokale kodebase allerede endret) noen klaget over en feil, ville jeg vite nøyaktig hvilken SVN-revisjon jeg måtte kasse for å feilsøke systemet riktig.

Kommentarer

• Dette er det beste svaret IMHO. Alle har rett i ideen sin, men denne viser virkelig hvorfor du vil bygge skript. Fordi de støtter automatisering som kommer fremover når prosjektet utvides, vil du spare deg for mye tid.
• @Alexus Ikke bare tid, men dumme feil også. 😉 » Gjentakelse fører til kjedsomhet. Kjedsomhet fører til forferdelige feil. Fryktelige feil fører til, ‘ Jeg skulle ønske jeg fortsatt kjedet meg.’ » (Du kan også måle dumme feil i tide, men det ‘ s viktig å innse at det ‘ sparer deg tid fra flere årsaker.)
• Selv for enmannsprosjekter, kjører du en lokal Jenkins-server for å automatisere » bygg i egen katalog » kan hjelpe. Jeg ‘ jobber med noe under Windows som jeg trenger å bekrefte, også kryss-kompiler, så å ha Jenkins til å bygge og kjøre tester, og deretter bygge den kryss-kompilerte versjonen gjør meg mye mer trygg og effektiv, selvfølgelig!) når jeg trenger å frigjøre feilrettinger.
• Jeg er ikke ‘ Jeg er ikke enig i argumentet om reproduserbare builds. Det er så mange ukontrollerte variabler i dagens byggesystemer at det er ganske vanskelig å få reproduserbare bygninger. Argumentet ditt høres ut som om du får det ut av boksen, noe som ikke er sant.
• @JonasGr ö ger Automation tar ut en av største variabler: mennesker.

Som kode, blir et build-skript utført av datamaskinen. Datamaskiner er usedvanlig gode på å følge et sett med instruksjoner. Faktisk (utenfor den selvmodifiserende koden) vil datamaskiner utføre den samme sekvensen av instruksjoner nøyaktig på samme måte, gitt samme inngang. Dette gir et nivå av konsistens som vel, bare en datamaskin kan matche.

Derimot er oss vannfylte kjøttposer rett og slett foraktelige når det gjelder å følge trinnene. Den irriterende analytiske hjernen har en tendens til å stille spørsmål ved alt den kommer over. «Åh … det trenger jeg ikke», eller «Skal jeg virkelig bruke dette flagget? Eh … Jeg vil bare ignorere det. I tillegg har vi en tendens til å bli selvtilfreds. Når vi har gjort noe noen ganger, begynner vi å tro at vi kjenner instruksjonene, og ikke trenger å se på instruksjonsarket.

Fra «The Pragmatic Programmer»:

I tillegg ønsker vi å sikre konsistens og repeterbarhet i prosjektet. Manuelle prosedyrer lar konsistensen endres; repeterbarhet er ikke garantert, spesielt hvis aspekter av prosedyren er åpen for tolkning av forskjellige mennesker. sammenlignet med en datamaskin). På et stort prosjekt, med hundrevis av filer og konfigurasjoner, vil det ta år å utføre alle trinnene manuelt i en byggeprosess.

Jeg gir deg et eksempel fra den virkelige verden. Jeg jobbet med noe innebygd programvare, hvor det meste av koden ble delt på noen få forskjellige maskinvareplattformer. Hver plattform hadde forskjellig maskinvare, men det meste av programvaren var den samme. Men det var små biter som var spesifikke for hver maskinvare. Ideelt sett ville vanlige brikker bli plassert i et bibliotek og koblet til hver versjon. Vanlige brikker kunne imidlertid ikke kompileres til et delt bibliotek. Det måtte kompileres med alle forskjellige konfigurasjoner.

Først kompilerte jeg manuelt hver konfigurasjon. Det tok bare noen få sekunder å veksle mellom konfigurasjoner, og var ikke så vondt. Mot slutten av prosjektet ble det oppdaget en kritisk feil i den delte delen av koden, der en enhet i det vesentlige ville ta over kommunikasjonsbussen. Dette var DÅRLIG! Veldig dårlig. Jeg fant feilen i koden, fikset den og kompilerte alle versjoner på nytt. Unntatt en. Under byggeprosessen ble jeg distrahert, og glemte en. Binærfilene ble utgitt, maskinen ble bygget, og en dag senere får jeg en telefonsamtale som sier at maskinen sluttet å svare. Jeg sjekket det ut, og oppdaget at en enhet hadde låst bussen. «Men jeg fikset den feilen!».

Jeg har kanskje fikset den, men den fant aldri veien på det ene brettet. Hvorfor? Fordi jeg ikke hadde en automatisert byggeprosess som bygde hver eneste versjon med ett klikk.

Kommentarer

• Og du kan gå på kaffe mens build-skript kjører!

Hvis alt du noen gang vil gjøre er <compiler> **/*.<extension>, byggeskripter tjener lite formål (selv om man kan hevde at hvis du ser en Makefile i prosjektet vet du at du kan bygge den med make). Saken er – ikke-trivielle prosjekter krever vanligvis mer enn det – i det minste trenger du vanligvis å legge til biblioteker og (når prosjektet modnes) konfigurere byggeparametere.

IDEer er vanligvis i det minste konfigurerbare – men nå er byggeprosessen avhengig av IDE-spesifikke alternativer.Hvis du bruker Formørkelse , foretrekker Alice NetBeans , og Bob vil bruke IntelliJ IDEA , du kan ikke dele konfigurasjonen, og når en av dere skyver en endring i kildekontrollen, må de enten manuelt redigere de IDE-opprettede konfigurasjonsfilene til de andre utviklerne, eller gi beskjed til de andre utviklerne slik at de vil gjøre det selv (som betyr at det vil være forpliktelser der IDE-konfigurasjonen er feil for noen av IDEene …).

Du må også finne ut hvordan du kan gjøre den endringen i hver og en av IDEene som brukes av teamet, og hvis en av dem ikke støtter den spesielle innstillingen …

Nå er dette problemet kulturavhengig – utviklerne dine vil kanskje synes det er akseptabelt å ikke ha valg av IDEer. Men utviklere som har erfaring med en IDE er vanligvis både lykkeligere og mer effektive når de bruker det, og tekstredigeringsbrukere har en tendens til å bli religiøst ivrige om sin favoritt ols, så dette er et av stedene hvor du vil gi utviklerne frihet – og bygge systemer lar deg gjøre nettopp det. Noen mennesker kan ha et byggesystempreferanse, men det er ikke så fanatisk som IDE / editorens preferanser …

Selv om du får alle utviklerne til å bruke samme IDE – lykke til med å overbevise bygningen serveren for å bruke den …

Nå, det er for de enkle tilpasningene for byggeprosessen, som IDEer har en god GUI for. Hvis du vil ha mer komplekse ting – som forbehandling / automatisk generering av kildefiler før kompileringen – må du vanligvis skrive et pre-build-skript i et grunnleggende tekstområde innenfor IDE-konfigurasjonen. Hvilke byggesystemer du fremdeles vil ha for å kode den delen, men du kan gjøre det i selve redigeringsprogrammet du skriver koden i, og enda viktigere: selve byggesystemets rammeverk gir vanligvis litt støtte for å organisere disse skriptene.

Til slutt – byggesystemer er bra for mer enn bare å bygge prosjektet – du kan programmere dem til å gjøre andre oppgaver som alle i teamet måtte trenge å utføre. I Ruby on Rails , for eksempel, er det bygge systemoppgaver for å kjøre databasemigrasjoner, for å rense de midlertidige filene osv. Å legge disse oppgavene i byggesystemet sørger for at alle i teamet kan gjøre dem konsekvent.

Kommentarer

• Det ‘ er ikke bare et spørsmål om forskjellige IDEer. Noen utviklere hater og avskyr IDEer av alle typer.
• @DavidHammen I ‘ er en av disse utviklerne (selv om jeg ‘ har konfigurert min Vim så vanskelig er ‘ er mulig at jeg kan ha gjort det om til en IDE …), og mens jeg skrev det avsnittet skrev jeg automatisk » redaktører » og måtte fikse det til IDE, fordi jeg tror fast inventar på IDE er en viktig del av svaret mitt. Spørgeren kommer tydeligvis fra IDEs verden, og spørsmålet snakker om IDE-mindre utvikling som noe du blir tvunget til å gjøre når det ikke er noen ordentlig IDE tilgjengelig. Poenget med dette svaret er å vise hvordan byggesystemer er gunstige selv for team som består av IDE-brukere.
• Også jeg er en av disse utviklerne. Jeg vil ikke ‘ ikke at fingrene mine må forlate tastaturet. Å gjøre det forstyrrer tankeprosessene mine.
• Jeg er uenig. Jeg foretrekker IDEer. De tillater meg å ikke bry meg om navn, enkle oppslag, refactoring, hyggelig brukergrensesnitt. Jeg mener, hvis en IDE kan gjøre noe for meg som jeg ellers ville gjort med sed ack osv., Bruker jeg det.
• Poenget er at med byggeskripter kan hver utvikler på teamet bruke det de foretrekker, mens du med IDE ‘ byggefunksjonaliteten tvinger alle ikke bare til å bruke en IDE, men til å bruke den helt spesifikke IDE prosjektet er konfigurert for (med mindre du har det konfigurert for flere IDEer, og lykke til med å synkronisere det …)

Mange IDEer pakker ganske enkelt kommandoene som brukes for å bygge noe og deretter generere et skript og kalle det!

I Visual Studio kan du for eksempel se kommandolinjeparametrene for en C ++ – kompilering i «kommandolinje» -boksen. Hvis du ser nøye på build-utgangen, vil du se den midlertidige filen som inneholder build-skriptet som ble brukt til å kjøre kompileringen.

I dag er det alt MSBuild , men det kjøres fortsatt direkte av IDE.

Så grunnen til at du bruker kommandolinjen er at du går rett til kilden og hopper over mellommannen, en mellommann som kanskje har blitt oppdatert eller krever en mengde avhengigheter som du bare ikke vil ha eller trenger på en hodeløs server som fungerer som kontinuerlig integrering (CI) server.

I tillegg gjør skriptene dine mer enn de vanlige utviklerorienterte trinnene de er designet for.For eksempel, etter en build, kan det hende du vil at binærfilene dine skal pakkes og kopieres til et spesielt sted, eller at det opprettes en installasjonspakke, eller at et dokumentasjonsverktøy kjøres på dem. Mange forskjellige oppgaver utføres av en CI-server som er meningsløs på en utviklermaskin, mens du kan lage et IDE-prosjekt som utførte alle disse trinnene, men du må da opprettholde to av dem – et prosjekt for utviklere og et annet for bygg. Noen byggeoppgaver (statisk analyse for eksempel) kan ta lang tid du ikke vil ha for utviklerprosjekter.

Kort fortalt er det bare enklere – lag et skript for å gjøre alle tingene du ønsker og det er raskt og enkelt å starte det på kommandolinjen eller en konfigurasjon av en server.

make 

er mye lettere å huske og skrive enn

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h 

Og prosjekter kan ha svært komplekse kompileringskommandoer. Et build-skript har også muligheten til å bare kompilere ting som endret seg. Hvis du vil gjøre en ren build, er

make clean 

enklere og mer pålitelig når den er konfigurert riktig enn å prøve å huske hvert sted en mellomfil kan ha blitt produsert.

Hvis du bruker en IDE, er det enkelt å klikke på en bygge- eller renseknapp også. Imidlertid er det mye vanskeligere å automatisere flytting av markøren til et bestemt sted på skjermen, spesielt når dette stedet kan bevege seg hvis vinduet beveger seg, enn det er å automatisere en enkel tekstkommando.

Hvordan ville du ellers gjort det? Den eneste andre måten er å spesifisere en lang kommandolinjekommando.

En annen grunn er at makefiles tillater inkrementell kompilering, noe som gir raskere kompileringstid.

Makefiles kan også lage en byggeprosess på tvers av plattformer. CMake genererer forskjellige byggeskripter basert på plattformen.

Rediger:

Med en IDE er du bundet til en bestemt måte å gjøre ting på. Mange bruker vim eller emacs selv om de ikke har mange IDE-lignende funksjoner. De gjør det fordi de vil ha kraften disse redaktører gir. Byggeskripter er nødvendige for de som ikke bruker IDE.

Selv for de som bruker IDE, vil du kanskje virkelig vite hva som skjer, så build-skriptet gir deg detaljer om lav ned av implementering som en GUI-tilnærming ikke har.

IDE «s bruker ofte også skript internt; løpsknappen er bare en annen måte å kjøre make-kommandoen på.

Svarene ovenfor dekker mye god grunn, men et eksempel fra den virkelige verden som jeg «vil legge til (som jeg ikke kan legge til som en kommentar på grunn av ingen karma), er fra Android-programmering.

Jeg er profesjonell Android / iOS / Windows Telefonutvikler, og jeg bruker API-er fra Google-tjenester (for det meste Google Maps) a lot .

I Android , krever disse tjenestene at jeg legger til en keystore , eller en type utvikler-ID-fil som forteller Google at jeg er den jeg sier jeg er, til en utviklerkonsoll. Hvis appen min er samlet med en annen nøkkelbutikk, fungerer ikke Google Maps-delen av appen.

I stedet for å legge til og administrere et dusin nøkkelbutikker til utviklerkonsollen, hvor bare en av dem faktisk kan brukes til å oppdatere appen uansett, inkluderer jeg denne nøkkelbutikken i vår sikre repo og bruk Gradle til å fortelle Android Studio nøyaktig hvilken nøkkelbutikk du skal bruke når du bygger for «feilsøking» eller «utgivelse». Nå må jeg bare legge til to nøkkellagre i Google-utviklerkonsollen min, en for «feilsøking» og en for «utgivelse», og alle teammedlemmene mine kan klone repoen og få rett til å utvikle seg uten å måtte gå inn på utvikleren konsoll og legg til SHA-hash for deres spesielle nøkkellager, eller verre, slik at jeg administrerer dem . Dette har den ekstra fordelen av å gi hvert teammedlem en kopi av signeringsnøkkelbutikken, noe som betyr at hvis jeg er ute av kontoret og en oppdatering er planlagt, trenger et teammedlem bare å følge en veldig kort liste med instruksjoner for å presse en oppdatering.

Bygningsautomatisering som dette holder bygninger konsistente, og reduserer teknisk gjeld ved å kutte ned på oppsettingstid når vi får en ny utvikler, en ny maskin, eller når vi må gjenta en maskin.

Bygg skriptfordeler:

• endringer ser ut som kode (for for eksempel i en git diff-kommando), ikke som forskjellige avmerkede alternativer i en dialog

• skaper mer utdata enn en enkel build

I noen av mine tidligere prosjekter har jeg brukt byggeskriptene til å:

• generere prosjektdokumentasjonen (doxygenbasert)
• bygge
• kjør enhetstester
• generer rapporter om enhetstestdekning
• pakke binærfiler i et utgivelsesarkiv
• generere interne versjonsmerknader (basert på «git log» -meldinger )
• automatisert testing

Ofte kan du ringe «build» -knappen på en automatisert måte (Visual Studio godtar f.eks. kommandolinjeargumenter. Folk skriver byggeskript så snart de trenger noe som byggeknappen ikke kan gi.

For eksempel vil de fleste IDEer bare la deg bygge én plattform om gangen. Eller bare en språk om gangen. Så er det hva du gjør med de innebygde utgangene: kan IDE-en rulle dem alle sammen til en installasjonspakke?