Vilka är fördelarna med att bygga skript?

Automation.

När du utvecklar är det bara i de enklaste projekten kommer standard ”build” -knappen att göra allt du behöver för att göra; du kan behöva skapa WS ur API: er, generera dokument, länka till externa resurser, distribuera ändringarna till en server etc. Vissa IDE: er låter dig anpassa byggprocessen genom att lägga till extra steg eller byggare, men det betyder bara att du är generera ditt build-skript genom IDE-varorna.

Men att utveckla ett system är inte bara att skriva kod. Det finns flera steg inblandade. Ett IDE-oberoende skript kan köras automatiskt, vilket innebär att:

• När du gör en ändring av versionskontroll kan en ny version startas automatiskt av servern. Det kommer att säkerställa att du inte har glömt att begå något som behövs för byggnaden.

• På samma sätt kan test automatiskt köras för att se om du bröt något efter att byggnaden är klar.

• Nu har resten av organisationen (QA, sysadmins) en inbyggd produkt som

  a) är perfekt reproducerbar bara från kontrollversionen.

  b) är gemensamt för dem alla.

Även när jag har arbetat som ett enmanslag har jag använt manus för det ändamålet; när jag hade utvecklat fixen skulle jag förbinda mig till SVN, exportera SVN tillbaka i en annan katalog och använda build-skriptet för att generera lösningen, som sedan går till förproduktionssystem och senare till produktion. Om några veckor senare (med min lokala kodbas redan ändrad) klagade någon på ett fel, skulle jag veta exakt vilken SVN-version jag skulle behöva checka ut för att felsöka systemet ordentligt. >

• Detta är det bästa svaret IMHO. Alla har rätt med sin idé, men den här visar verkligen varför du vill bygga manus. Eftersom de stöder automatisering som kommer framåt när ditt projekt expanderar kommer du att spara massor av tid.
• @Alexus Inte bara tid utan dumma misstag också. 😉 ” Upprepning leder till tristess. Tristess leder till skrämmande misstag. Skrämmande misstag leder till ’ Jag önskar att jag fortfarande var uttråkad.’ ” (Du kan också mäta dumma misstag i tiden, men det ’ s viktigt att inse att det ’ sparar tid från flera orsaker.)
• Även för enmansprojekt kör du en lokal Jenkins-server för att automatisera ” inbyggd separat katalog ” kan hjälpa till. Jag ’ Jag arbetar på något under Windows som jag måste bekräfta också korskompilerar, så att Jenkins bygger och kör test och sedan bygger den korskompilerade versionen gör mig mycket mer säker ( och effektivt, naturligtvis!) när jag behöver släppa felkorrigeringar.
• Jag ’ håller inte med argumentet om reproducerbara builds. Det finns så många okontrollerade variabler i dagens byggsystem att det är ganska svårt att få reproducerbara byggnader. Ditt argument låter som om du kommer att få det out-of-the-box, vilket är helt sant.
• @JonasGr ö ger Automation tar ut en av största variablerna: människor.

Precis som kod körs ett build-skript av datorn. Datorer är exceptionellt bra på att följa en uppsättning instruktioner. Faktum är att (utanför den självmodifierande koden) kommer datorer att utföra samma sekvens av instruktioner på exakt samma sätt, med samma ingång. Detta ger en nivå av konsistens som, ja, bara en dator kan matcha.

Däremot är oss vattenfyllda köttpåse bara direkt föraktliga när det gäller följande steg. Den irriterande analytiska hjärnan har en tendens att ifrågasätta allt den stöter på. ”Åh … det behöver jag inte”, eller ”Behöver jag verkligen använda den här flaggan? Eh … Jag ignorerar det bara. Dessutom har vi en tendens att bli självbelåtna. När vi väl har gjort något några gånger börjar vi tro att vi känner till instruktionerna och behöver inte titta på instruktionsbladet.

Från ”The Pragmatic Programmer”:

Dessutom vill vi säkerställa konsekvens och repeterbarhet i projektet. Manuella procedurer låter konsekvensen ändras; repeterbarhet är inte garanterat, särskilt om aspekter av proceduren är öppna för tolkning av olika människor.

Dessutom är vi TILLGÄNGLIG tröga i att utföra instruktioner ( jämfört med en dator). I ett stort projekt, med hundratals filer och konfigurationer, skulle det ta år att manuellt utföra alla steg i en byggprocess.

Jag ger dig ett verkligt exempel. Jag arbetade med inbäddad programvara, där det mesta av koden delades över några olika hårdvaruplattformar. Varje plattform hade olika hårdvaror, men de flesta av programvarorna var desamma. Men det fanns små bitar som var specifika för varje hårdvara. Helst skulle de vanliga bitarna placeras i ett bibliotek och länkas till varje version. De vanliga bitarna kunde dock inte kompileras i ett delat bibliotek. Det måste kompileras med alla olika konfigurationer.

Först kompilerade jag varje konfiguration manuellt. Det tog bara några sekunder att växla mellan konfigurationer, och det var inte så svårt. Mot slutet av projektet upptäcktes en kritisk defekt i den delade delen av koden, där en enhet i huvudsak skulle ta över kommunikationsbussen. Det här var DÅLIGT! Riktigt dåligt. Jag hittade felet i koden, fixade det och kompilerade varje version på nytt. Förutom en. Under byggprocessen blev jag distraherad och glömde en. Binärerna släpptes, maskinen byggdes och en dag senare får jag ett telefonsamtal där jag säger att maskinen slutade svara. Jag kollade ut det och upptäckte att en enhet hade låst bussen. ”Men jag fixade det där felet!”.

Jag kanske har fixat det, men det hittade aldrig vägen på det ena kortet. Varför? Eftersom jag inte hade en automatiserad byggprocess som byggde varje enskild version med ett klick.

Kommentarer

• Och du kan ta kaffe medan byggskript kör!

Om allt du någonsin vill göra är <compiler> **/*.<extension>, byggskript tjänar lite syfte (även om man kan argumentera för att om du ser en Makefile i projektet vet du att du kan bygga den med make). Saken är – icke-triviala projekt kräver vanligtvis mer än så – åtminstone måste du vanligtvis lägga till bibliotek och (när projektet mognar) konfigurera byggparametrar.

IDE är vanligtvis åtminstone så konfigurerbara – men nu bygger byggprocessen på IDE-specifika alternativ.Om du använder Eclipse föredrar Alice NetBeans och Bob vill använda IntelliJ IDEA , du kan inte dela konfigurationen, och när en av er trycker på en ändring i källkontrollen måste de antingen manuellt redigera de IDE-skapade konfigurationsfilerna för de andra utvecklarna, eller meddela de andra utvecklarna så att de kommer att göra det själva (vilket innebär att det kommer åtaganden där IDE-konfigurationen är fel för vissa IDE: er …).

Du måste också ta reda på hur man gör den förändringen i varje IDE som används av teamet, och om en av dem inte stöder just den inställningen …

Nu är detta problem kulturberoende – dina utvecklare kanske tycker att det är acceptabelt att inte ha valet av IDE: er. Men utvecklare som har erfarenhet av en IDE är vanligtvis både lyckligare och effektivare när de använder det, och textredigeringsanvändare tenderar att bli religiöst ivriga om sin favorit till ols, så det här är en av platserna där du vill ge utvecklarna frihet – och bygga system gör att du kan göra just det. Vissa människor kan ha ett byggsystemspreferens, men det är inte alls lika fanatiskt som IDE / redigeringsinställningar …

Även om du får alla utvecklare att använda samma IDE – lycka till att övertyga byggnaden servern för att använda den …

Nu, det är för de enkla byggprocessanpassningarna, som IDE: er tenderar att ge bra GUI för. Om du vill ha mer komplexa saker – som förbehandling / automatisk generering av källfiler före kompileringen – måste du vanligtvis skriva ett förbyggda skript i något grundläggande textområde inom IDE: s konfiguration. Vilka byggsystem du fortfarande skulle behöva koda den delen, men du kan göra det i själva redigeraren du skriver koden i, och ännu viktigare: själva byggsystemets ram ger vanligtvis lite stöd för att organisera dessa skript.

Slutligen – byggsystem är bra för mer än bara att bygga projektet – du kan programmera dem för att utföra andra uppgifter som alla i teamet kan behöva utföra. I Ruby on Rails , till exempel finns det systemuppgifter för att köra databasmigreringar, för rengöring av tillfälliga filer etc. Att lägga dessa uppgifter i byggsystemet säkerställer att alla i teamet kan göra dem konsekvent.

Kommentarer

• Det ’ handlar inte bara om olika IDE: er. Vissa utvecklare hatar och avskyr IDE av alla slag.
• @DavidHammen I ’ jag är en av dessa utvecklare (även om jag ’ har konfigurerat min Vim så svårt är ’ är möjligt att jag kanske har gjort det till en IDE …), och när jag skrev det stycket skrev jag automatiskt ” redaktörer ” och var tvungen att fixa det till IDE, för jag tror att fixturen på IDE är en viktig del av mitt svar. Askaren kommer helt klart från IDE: s värld, och frågan talar om IDE-mindre utveckling som något du tvingas göra när det inte finns någon ordentlig IDE tillgänglig. Poängen med detta svar är att visa hur byggsystem är fördelaktiga även för lag som består av IDE-användare.
• Jag är också en av dessa utvecklare. Jag vill inte ’ att mina fingrar måste lämna tangentbordet. Att göra det avbryter mina tankeprocesser.
• Jag håller inte med. Jag föredrar IDE. De tillåter mig att inte bry mig om namn, enkla sökningar, refactoring, trevligt användargränssnitt. Jag menar, om en IDE kan göra något åt mig som jag annars skulle göra med sed ack etc, använder jag det.
• Poängen är att med build-skript kan varje utvecklare i teamet använda vad de föredrar, medan du med IDE ’ s byggfunktionalitet tvingar du alla inte bara att använda en IDE utan också att använda den mycket specifika IDE som projektet är konfigurerat för (såvida du inte har konfigurerat det för flera IDE: er, och lycka till att synkronisera det …)

Många IDE paketerar helt enkelt kommandona som används att bygga något och sedan skapa ett skript och kalla det!

Till exempel, i Visual Studio kan du se kommandoradsparametrarna för en C ++ – kompilering i rutan ”kommandorad”. Om du tittar noggrant på build-utdata ser du den tillfälliga filen som innehåller build-skriptet som användes för att köra kompileringen.

Numera är det allt MSBuild , men det körs fortfarande direkt av IDE.

Så anledningen till att du använder kommandoraden är att du går direkt till källan och hoppar över mitten, en mellanhand som kanske har uppdaterats eller kräver en massa beroenden som du inte vill eller behöver på en huvudlös server som fungerar som din kontinuerlig integration (CI) server.

Dessutom gör dina skript mer än de vanliga utvecklarorienterade stegen de är avsedda för.Till exempel, efter en build kanske du vill att dina binära filer ska packas och kopieras till en speciell plats, eller att ett installationspaket skapas eller att ett dokumentationsverktyg körs på dem. Många olika uppgifter utförs av en CI-server som är meningslösa på en utvecklarmaskin, så medan du kan skapa ett IDE-projekt som utförde alla dessa steg måste du behålla två av dem – ett projekt för utvecklare och ett annat för byggnader. Vissa bygguppgifter (statisk analys till exempel) kan ta lång tid som du inte vill ha för utvecklarprojekt.

Kort sagt, det är bara enklare – skapa ett manus för att göra alla saker du vill ha det och det är snabbt och enkelt att starta det på kommandoraden eller i en konfigurationsserverkonfiguration.

make 

är mycket lättare att komma ihåg och skriva än

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 

Och projekt kan ha mycket komplexa kompileringskommandon. Ett build-skript har också förmågan att bara kompilera om de saker som förändrats. Om du vill göra en ren byggnad är

make clean 

enklare och mer tillförlitlig när du har ställt in den korrekt än att försöka komma ihåg varje plats som en mellanfil kan ha har producerats.

Om du använder en IDE är det naturligtvis också enkelt att klicka på en bygg- eller rengöringsknapp. Det är dock mycket svårare att automatisera flytta markören till en viss plats på skärmen, särskilt när den platsen kan röra sig om fönstret rör sig än att automatisera ett enkelt textkommando.

Hur annars skulle du göra det? Det enda andra sättet är att ange ett långt kommandoradskommando.

En annan anledning är att makefiles tillåter inkrementell kompilering, vilket påskyndar kompileringstiden mycket.

Makefiles kan också göra en byggprocess plattform. CMake genererar olika build-skript baserat på plattformen.

Redigera:

Med en IDE är du bunden till ett visst sätt att göra saker på. Många använder vim eller emacs även om de inte har många IDE-liknande funktioner. De gör det för att de vill ha kraften redaktörer tillhandahåller. Byggskript är nödvändiga för dem som inte använder en IDE.

Även för dem som använder en IDE kanske du verkligen vill veta vad som händer, så build-skriptet ger dig detaljerna av implementering som ett GUI-tillvägagångssätt inte har.

IDE ”s själva använder ofta också skript internt; kör-knappen är bara ett annat sätt att köra make-kommandot.

Svaren ovan täcker mycket bra mark, men ett verkligt exempel som jag ”vill lägga till (som jag inte kan lägga till som en kommentar på grund av ingen karma), är från Android-programmering.

Jag är en professionell Android / iOS / Windows Telefonutvecklare och jag använder Googles tjänster-API: er (mestadels Google Maps) a lot .

I Android , dessa tjänster kräver att jag lägger till en keystore , eller en typ av utvecklar-ID-fil som berättar för Google att jag är den jag säger att jag är, till en utvecklarkonsol. Om min app är kompilerad med en annan nyckellager fungerar inte Google Maps-delen av appen.

Istället för att lägga till och hantera ett dussin nyckellager till utvecklarkonsolen, varav endast en faktiskt kan användas för att uppdatera appen ändå, inkluderar jag den här nyckellagret i vår säkra repo och använd Gradle för att berätta för Android Studio exakt vilken keystore du ska använda när du bygger för ”felsökning” eller ”release”. Nu behöver jag bara lägga till två nyckellager till min Google-utvecklarkonsol, en för ”felsökning” och en för ”släpp”, och alla mina teammedlemmar kan klona repo och få rätt att utvecklas utan att behöva gå in i utvecklaren konsol och lägg till SHA-hash för deras specifika keystore, eller värre, så att jag kan hantera dem . Detta har den extra fördelen att varje teammedlem får en kopia av signeringstangenten, vilket innebär att om jag inte är på kontoret och en uppdatering är planerad behöver en teammedlem bara följa en mycket kort lista med instruktioner för att driva en uppdatering.

Byggautomatisering som denna håller byggnader konsekventa och minskar den tekniska skulden genom att sänka lång tid när vi får en ny utvecklare, en ny maskin eller när vi måste återbilda en maskin.

Bygg skriptfördelar:

• ändringar ser ut som kod (för exempel, i ett git diff-kommando), inte som olika markerade alternativ i en dialogruta

• skapar mer utdata än en enkel uppbyggnad

I några av mina tidigare projekt har jag använt build-skript för att:

• generera projektdokumentationen (doxygen-baserad)
• build
• kör enhetstester
• generera enhetstestrapporter
• packa binärer i ett släpparkiv
• generera interna release-anteckningar (baserat på ”git log” -meddelanden )
• automatiserad testning

Ofta kan du ringa ”build” -knappen automatiskt (Visual Studio accepterar exempelvis kommandoradsargument). Människor skriver build-skript så snart de behöver något som byggknappen inte kan tillhandahålla.

Till exempel låter de flesta IDE dig bara bygga en plattform i taget. Eller bara en språk åt gången. Sedan finns det vad du gör med de inbyggda utgångarna: kan din IDE rulla upp dem alla till ett installationspaket?