Hvad er fordelene ved build-scripts?

Automatisering.

Når du udvikler, er det kun i de mest enkle projekter vil standard “build” -knappen gøre alt hvad du behøver at gøre; Det kan være nødvendigt at du opretter WS ud af APIer, genererer docs, linker til eksterne ressourcer, distribuerer ændringer til en server osv. Nogle IDEer giver dig mulighed for at tilpasse byggeprocessen ved at tilføje ekstra trin eller buildere, men det betyder kun, at du er generere dit build-script gennem IDE-varerne.

Men at udvikle et system er ikke kun at skrive kode. Der er flere trin involveret. Et IDE-uafhængigt script kan udføres automatisk, hvilket betyder at:

• Når du foretager en ændring i versionskontrol, kan en ny build startes automatisk af serveren. Det vil sikre, at du ikke har glemt at begå noget, der er nødvendigt til build.

• På samme måde kan test automatisk køres for at se, om du har brudt noget, efter buildet er udført.

• Nu har resten af organisationen (QA, sysadmins) et indbygget produkt, der

  a) er perfekt reproducerbart lige fra kontrolversionen.

  b) er fælles for dem alle.

Selv når jeg har arbejdet som et enmandsteam, har jeg brugt scripts til det formål; da jeg havde udviklet den rettelse, ville jeg forpligte mig til SVN, eksportere SVN tilbage i en anden mappe og bruge build-scriptet til at generere løsningen, som derefter gik til præproduktionssystemer og senere til produktion. Hvis nogle få uger senere (med min lokale kodebase allerede ændret) klagede nogen over en fejl, ville jeg vide nøjagtigt, hvilken SVN-revision jeg skulle tjekke for at kunne fejle systemet korrekt.

Kommentarer

• Dette er det bedste svar IMHO. Alle har ret med deres idé, men denne viser virkelig, hvorfor du vil bygge scripts. Fordi de understøtter automatisering, som kommer fremad, når dit projekt udvides, sparer du masser af tid.
• @Alexus Ikke kun tid, men også dumme fejl. 😉 ” Gentagelse fører til kedsomhed. Kedsomhed fører til forfærdelige fejl. Forfærdelige fejl fører til ‘ Jeg ville ønske, at jeg stadig kede mig.’ ” (Du kan også måle dumme fejl i tide, men det ‘ s vigtigt at indse, at det ‘ sparer dig tid fra flere årsager.)
• Selv for enmandsprojekter kører du en lokal Jenkins-server til automatisering af ” indbygget i separat mappe ” kan hjælpe. Jeg ‘ arbejder på noget under Windows, som jeg har brug for at bekræfte, også krydskompileringer, så at have Jenkins til at bygge og køre tests og derefter opbygge den kryds-kompilerede version gør mig meget mere selvsikker og effektiv, selvfølgelig!) når jeg har brug for at frigive fejlrettelser.
• Jeg ‘ er ikke enig i argumentet om reproducerbare builds. Der er så mange ukontrollerede variabler i dagens build-systemer, at det er ret svært at få reproducerbare builds. Dit argument lyder som om, du får det ud af kassen, hvilket ikke er sandt.
• @JonasGr ö ger Automation tager en af de ud største variabler: mennesker.

Ligesom kode udføres et build-script af computeren. Computere er usædvanligt gode til at følge et sæt instruktioner. Faktisk (uden for den selvmodificerende kode) udfører computere den samme sekvens af instruktioner nøjagtigt på samme måde, givet den samme input. Dette leverer et niveau af konsistens, som kun en computer kan matche.

I modsætning hertil er os vandfyldte kødposer bare direkte foragtelige, når det kommer til følgende trin. Den irriterende analytiske hjerne har en tendens til at sætte spørgsmålstegn ved alt, hvad den støder på. “Åh … det behøver jeg ikke” eller “Skal jeg virkelig bruge dette flag? Øh … Jeg ignorerer det bare. Derudover har vi en tendens til at blive selvtilfredse. Når vi først har gjort noget et par gange, begynder vi at tro, at vi kender instruktionerne, og ikke behøver at se på instruktionsarket.

Fra “The Pragmatic Programmer”:

Derudover ønsker vi at sikre konsistens og repeterbarhed i projektet. Manuelle procedurer lader konsekvensen ændre sig; repeterbarhed er ikke garanteret, især hvis aspekter af proceduren er åbne for fortolkning af forskellige mennesker. sammenlignet med en computer). På et stort projekt med hundredvis af filer og konfigurationer vil det tage år at udføre alle trin manuelt i en byggeproces manuelt.

Jeg giver dig et eksempel på en reel verden. Jeg arbejdede med indlejret software, hvor det meste af koden blev delt på få forskellige hardwareplatforme. Hver platform havde forskellig hardware, men det meste af softwaren var den samme. Men der var små stykker, der var specifikke for hver hardware. Ideelt set ville de almindelige stykker placeres i et bibliotek og linkes til hver version. De almindelige stykker kunne imidlertid ikke kompileres i et delt bibliotek. Det skulle kompileres med alle forskellige konfigurationer.

Først kompilerede jeg manuelt hver konfiguration. Det tog kun et par sekunder at skifte mellem konfigurationer, og var ikke så stor smerte. Mod slutningen af projektet blev der opdaget en kritisk defekt i den delte kode, hvor en enhed i det væsentlige ville overtage kommunikationsbussen. Dette var DÅRLIGT! Rigtig dårligt. Jeg fandt fejlen i koden, fikset den og kompilerede hver version igen. Undtagen en. Under byggeprocessen blev jeg distraheret og glemte en. Binærfiler blev frigivet, maskinen blev bygget, og en dag senere får jeg et telefonopkald, der siger, at maskinen stoppede med at svare. Jeg tjekkede det ud og opdagede, at en enhed havde låst bussen. “Men jeg rettede den fejl!”.

Jeg har muligvis rettet den, men den fandt aldrig vej på det ene bord. Hvorfor? Fordi jeg ikke havde en automatiseret byggeproces, der byggede hver eneste version med et enkelt klik.

Kommentarer

• Og du kan gå på kaffe, mens build-script kører!

Hvis alt hvad du nogensinde vil gøre er <compiler> **/*.<extension>, build-scripts tjener lidt formål (selvom man kan argumentere for, at hvis du ser en Makefile i projektet, ved du, at du kan bygge den med make). Sagen er – ikke-trivielle projekter kræver normalt mere end det – i det mindste skal du normalt tilføje biblioteker og (når projektet modnes) konfigurere build-parametre.

IDEer er normalt mindst konfigurerbare – men nu bygger byggeriet på IDE-specifikke muligheder.Hvis du bruger Formørkelse , foretrækker Alice NetBeans , og Bob vil bruge IntelliJ IDEA , du kan ikke dele konfigurationen, og når en af jer skubber en ændring til kildekontrollen, skal de enten manuelt redigere de IDE-oprettede konfigurationsfiler af de andre udviklere, eller underret de andre udviklere, så de gør det selv (hvilket betyder, at der vil være forpligtelser, hvor IDE-konfigurationen er forkert for nogle af IDEerne …).

Du skal også finde ud af, hvordan du foretager denne ændring i hver eneste af de IDEer, der bruges af holdet, og hvis en af dem ikke understøtter den særlige indstilling …

Nu er dette problem kulturafhængigt – dine udviklere finder det måske acceptabelt at ikke have valget af IDEer. Men udviklere, der har erfaring med en IDE, er normalt både lykkeligere og mere effektive, når de bruger det, og teksteditorbrugere har tendens til at blive religiøst nidkær over deres favorit til ols, så dette er et af de steder, hvor du vil give udviklerne frihed – og bygge systemer giver dig mulighed for netop det. Nogle mennesker har muligvis en build-systempræference, men det er ikke så fanatisk som IDE / editor-præferencer …

Selvom du får alle udviklerne til at bruge den samme IDE – held og lykke med at overbevise buildet server til at bruge det …

Nu, det er til de enkle tilpasningsprocesser til byggeprocesser, som IDEer har en god GUI til. Hvis du vil have mere komplekse ting – som forbehandling / automatisk generering af kildefiler inden kompileringen – bliver du normalt nødt til at skrive et præ-build-script i et eller andet grundlæggende tekstområde inden for IDE-konfigurationen. Hvilke build-systemer du stadig skal kode for den del, men du kan gøre det i den aktuelle editor, du skriver koden i, og vigtigere: selve build-systemets ramme giver normalt en vis støtte til organisering af disse scripts.

Endelig – build-systemer er gode til mere end bare at opbygge projektet – du kan programmere dem til at udføre andre opgaver, som alle i teamet muligvis skal udføre. I Ruby on Rails , for eksempel, er der build-systemopgaver til kørsel af databasemigrationer, til rengøring af de midlertidige filer osv. At sætte disse opgaver i build-systemet sikrer, at alle i teamet kan udføre dem konsekvent.

Kommentarer

• Det ‘ handler ikke kun om forskellige IDEer. Nogle udviklere hader og afskyr IDEer af alle typer.
• @DavidHammen I ‘ er en af disse udviklere (selvom jeg ‘ har konfigureret min Vim så hårdt er ‘ er muligt, at jeg måske har forvandlet det til en IDE …), og mens jeg skrev dette afsnit, skrev jeg automatisk ” redaktører ” og var nødt til at rette det til IDE, fordi jeg tror, at inventar på IDEer er en vigtig del af mit svar. Askeren kommer tydeligt fra IDEs verden, og spørgsmålet taler om IDE-mindre udvikling som noget, du er tvunget til at gøre, når der ikke er nogen ordentlig IDE tilgængelig. Pointen med dette svar er at vise, hvordan build-systemer er gavnlige selv for hold, der udelukkende består af IDE-brugere.
• Også jeg er en af disse udviklere. Jeg ønsker ikke ‘ at mine fingre skal forlade tastaturet. Dette afbryder mine tankeprocesser.
• Jeg er uenig. Jeg foretrækker IDEer. De tillader mig ikke at bekymre mig om navne, lette opslag, refactoring, flot brugergrænseflade. Jeg mener, hvis en IDE kan gøre noget for mig, som jeg ellers ville gøre med sed ack osv., Bruger jeg det.
• Pointen er, at med build-scripts kan enhver udvikler på teamet bruge hvad de foretrækker, mens du med IDE ‘ -funktionaliteten tvinger alle ikke kun til at bruge en IDE, men til at bruge den meget specifikke IDE, som projektet er konfigureret til (medmindre du har konfigureret det til flere IDEer, og held og lykke med at synkronisere det …)

Mange IDEer pakker simpelthen de anvendte kommandoer at bygge noget og derefter generere et script og kalde det!

For eksempel kan du i Visual Studio se kommandolinjeparametrene for en C ++ – kompilering i feltet “kommandolinje”. Hvis du ser nøje på build-output, vil du se den midlertidige fil, der indeholder build-scriptet, der blev brugt til at køre kompilering.

I dag er det alt MSBuild , men det køres stadig direkte af IDE.

Så grunden til at du bruger kommandolinjen er, at du går direkte til kilden og springer mellemmand, en mellemmand, der muligvis er blevet opdateret eller har brug for en bunke afhængigheder, som du bare ikke ønsker eller har brug for på en hovedløs server, der fungerer som din kontinuerlig integration (CI) server.

Derudover udfører dine scripts mere end de sædvanlige udviklerorienterede trin, de er designet til.For eksempel efter en build vil du muligvis have dine binære filer pakket og kopieret til en særlig placering eller oprettet en installationspakke eller et dokumentationsværktøj kørt på dem. Mange forskellige opgaver udføres af en CI-server, der er meningsløs på en udviklermaskine, så mens du kunne oprette et IDE-projekt, der udførte alle disse trin, skulle du derefter vedligeholde to af dem – et projekt til udviklere og et andet til builds. Nogle bygningsopgaver (f.eks. Statisk analyse) kan tage lang tid, som du ikke ønsker for udviklerprojekter.

Kort sagt er det bare nemmere – lav et script til at gøre alle de ting, du ønsker, og det er hurtigt og nemt at starte det på kommandolinjen eller en konfigurationsserver til en byggeserver.

make 

er meget lettere at huske og skrive end

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 projekter kan have meget komplekse kompileringskommandoer. Et build-script har også evnen til kun at kompilere de ting, der ændrede sig. Hvis du vil udføre en ren build, er

make clean 

lettere og mere pålidelig, når den er konfigureret korrekt, end at prøve at huske hvert sted, en mellemfil kan have er produceret.

Selvfølgelig, hvis du bruger en IDE, er det også nemt at klikke på en build- eller renseknap. Det er dog meget sværere at automatisere at flytte markøren til et bestemt sted på skærmen, især når dette sted kan bevæge sig, hvis vinduet bevæger sig, end det er at automatisere en simpel tekstkommando.

Hvordan ville du ellers gøre det? Den eneste anden måde er at angive en lang kommandolinjekommando.

En anden grund er, at makefiles tillader inkrementel kompilering, hvilket fremskynder kompileringstiden meget.

Makefiles kan også lave en byggeproces på tværs af platforme. CMake genererer forskellige build-scripts baseret på platformen.

Rediger:

Med en IDE er du bundet til en bestemt måde at gøre ting på. Mange mennesker bruger vim eller emacs, selvom de ikke har mange IDE-lignende funktioner. De gør det, fordi de vil have kraften til disse redaktører leverer. Build-scripts er nødvendige for dem, der ikke bruger en IDE.

Selv for dem, der bruger en IDE, vil du måske virkelig vide, hvad der foregår, så build-scriptet giver dig detaljerne lavt ned af implementering, som en GUI-tilgang ikke har.

IDEer bruger selv ofte også scripts internt; køreknappen er bare en anden måde at køre make-kommandoen på.

Ovenstående svar dækker meget god grund, men et eksempel fra den virkelige verden, som jeg gerne vil tilføje (som jeg ikke kan tilføje som en kommentar på grund af ingen karma), er fra Android-programmering.

Jeg er en professionel Android / iOS / Windows Telefonudvikler, og jeg bruger Google-tjenester-APIer (for det meste Google Maps) en lot .

I Android , kræver disse tjenester, at jeg tilføjer en keystore , eller en type udvikler-id-fil, der fortæller Google, at jeg er den, jeg siger, jeg er, til en udviklerkonsol. Hvis min app er sammensat med en anden nøglelager, fungerer Google Maps-sektionen i appen ikke.

I stedet for at tilføje og administrere et dusin nøgleforretninger til udviklerkonsollen, hvoraf kun en faktisk kan bruges til at opdatere appen alligevel, inkluderer jeg denne nøglelager i vores sikre repo og brug Gradle til at fortælle Android Studio nøjagtigt, hvilken nøglebutik der skal bruges, når du bygger til “fejlretning” eller “frigivelse”. Nu skal jeg kun tilføje to nøglelagre til min Google-udviklerkonsol, en til “fejlretning” og en til “frigivelse”, og alle mine teammedlemmer kan klone repoen og få ret til at udvikle sig uden at skulle gå ind på dev konsol og tilføj SHA-hash af deres bestemte keystore, eller værre, får mig til at administrere dem . Dette har den ekstra fordel, at hvert teammedlem får en kopi af signaturnøglelageret, hvilket betyder, at hvis jeg er ude af kontoret, og der er planlagt en opdatering, behøver et teammedlem kun at følge en meget kort liste med instruktioner for at skubbe en opdatering.

Bygningsautomation som denne holder builds konsistente og reducerer teknisk gæld ved at skære ned på opsætningstid, når vi får en ny udvikler, en ny maskine, eller når vi skal gendanne en maskine.

Byg scriptfordele:

• ændringer ligner kode (for f.eks. i en git diff-kommando), ikke som forskellige kontrollerede indstillinger i en dialog

• hvilket skaber mere output end en simpel build

I nogle af mine tidligere projekter har jeg brugt build-scripts til at:

• generere projektdokumentationen (doxygenbaseret)
• build
• køre enhedstest
• generere enhedstestdækningsrapporter
• pakke binære filer i et udgivelsesarkiv
• generere interne udgivelsesnotater (baseret på “git log” -meddelelser )
• automatiseret test

Ofte kan du kalde “build” -knappen på en automatisk måde (Visual Studio accepterer f.eks. kommandolinjeargumenter. Folk skriver build-scripts, så snart de har brug for noget, som build-knappen ikke kan levere.

For eksempel vil de fleste IDEer kun lade dig bygge én platform ad gangen. Eller kun en sprog ad gangen. Så er der, hvad du gør med de indbyggede output: kan din IDE rulle dem alle sammen til en installationspakke?