Wat zijn de voordelen van build-scripts?

Automatisering.

Alleen in de meest eenvoudige projecten zal de standaard “build” -knop alles doen wat nodig is om te doen; Mogelijk moet u WS maken van APIs, documenten genereren, linken met externe bronnen, de wijzigingen implementeren op een server, enz. Met sommige IDEs kunt u het buildproces aanpassen door extra stappen of builders toe te voegen, maar dat betekent alleen dat u dat bent het genereren van uw build-script via de IDE-commodities.

Maar het ontwikkelen van een systeem is niet alleen het schrijven van code. Er zijn meerdere stappen bij betrokken. Een IDE-onafhankelijk script kan automatisch worden uitgevoerd, wat betekent dat:

• Wanneer u een wijziging in versiebeheer vastlegt, kan er automatisch een nieuwe build worden gestart door de server. Het zorgt ervoor dat u niet bent vergeten iets te doen wat nodig is voor de build.

• Op dezelfde manier kunnen, nadat de build is voltooid, automatisch tests worden uitgevoerd om te zien of u iets kapot heeft gemaakt.

• Nu heeft de rest van de organisatie (QA, sysadmins) een gebouwd product dat

  a) perfect reproduceerbaar is vanaf de controleversie.

  b) hebben ze allemaal gemeen.

Zelfs als ik als een eenmans team heb gewerkt, heb ik scripts voor dat doel gebruikt; toen ik de fix had ontwikkeld, zou ik me committeren aan SVN, de SVN terug exporteren naar een andere directory en het build-script gebruiken om de oplossing te genereren, die vervolgens naar Preproductiesystemen en later naar Productie zou gaan. Als een paar weken later (met mijn lokale codebase al veranderd) iemand klaagde over een bug, zou ik precies weten welke SVN-revisie ik zou moeten uitchecken om het systeem correct te debuggen.

Opmerkingen

• Dit is het beste antwoord IMHO. Iedereen heeft gelijk met zijn idee, maar deze laat echt zien waarom je scripts wilt bouwen. Omdat ze automatisering ondersteunen die vooruitgaat naarmate uw project groter wordt, bespaart u veel tijd.
• @Alexus Niet alleen tijd, maar ook domme fouten. 😉 ” Herhaling leidt tot verveling. Verveling leidt tot gruwelijke fouten. Gruwelijke fouten leiden tot: ‘ Ik wou dat ik me nog steeds verveelde.’ ” (Je zou ook domme fouten in de tijd kunnen meten, maar het is ‘ belangrijk om te beseffen dat het ‘ je tijd bespaart door verschillende oorzaken.)
• Zelfs voor eenmansprojecten kan het draaien van een lokale Jenkins-server voor het automatiseren van de ” ingebouwd in een aparte directory ” kan helpen. Ik ‘ m bezig met iets onder Windows dat ik moet bevestigen, ook cross-compileren, dus Jenkins laten bouwen en testen uitvoeren, en vervolgens de cross-gecompileerde versie bouwen geeft me veel meer vertrouwen ( en efficiënt, natuurlijk!) wanneer ik bugfixes moet vrijgeven.
• Ik ben het niet eens met het argument van reproduceerbare builds ‘. Er zijn zoveel ongecontroleerde variabelen in de huidige build-systemen dat het vrij moeilijk is om reproduceerbare builds te krijgen. Uw argument klinkt alsof u dat out-of-the-box krijgt, wat helemaal niet waar is.
• @JonasGr ö ger Automation haalt een van de grootste variabelen: mensen.

Net als code wordt een build-script uitgevoerd door de computer. Computers zijn uitzonderlijk goed in het volgen van een reeks instructies. In feite (buiten de zelfmodificerende code) zullen computers dezelfde reeks instructies op precies dezelfde manier uitvoeren, met dezelfde invoer. Dit levert een niveau van consistentie op dat, nou ja, alleen een computer kan evenaren.

Daarentegen zijn wij met water gevulde vleeszakken gewoon ronduit verachtelijk als het gaat om de volgende stappen. Dat vervelende analytische brein heeft de neiging om alles wat het tegenkomt in twijfel te trekken. “Oh … dat heb ik niet nodig”, of “Moet ik deze vlag echt gebruiken? Eh … ik negeer het gewoon. Bovendien hebben we de neiging om zelfgenoegzaam te worden. Zodra we “een paar keer iets hebben gedaan, gaan we geloven dat we de instructies kennen en hoeven we niet naar het instructieblad te kijken.

Van” The Pragmatic Programmer “:

Bovendien willen we de consistentie en herhaalbaarheid van het project garanderen. Handmatige procedures laten consistentie toe aan verandering; herhaalbaarheid is niet gegarandeerd, vooral niet als aspecten van de procedure openstaan voor interpretatie door verschillende mensen.

Bovendien zijn we HILARISCH traag in het uitvoeren van instructies ( vergeleken met een computer). Bij een groot project, met honderden bestanden en configuraties, zou het jaren duren om alle stappen in een bouwproces handmatig uit te voeren.

Ik zal je een voorbeeld uit de echte wereld geven. Ik werkte aan embedded software, waarbij de meeste code werd gedeeld met een paar verschillende hardwareplatforms. Elk platform had verschillende hardware, maar de meeste software was hetzelfde. Maar er waren kleine stukjes die specifiek waren voor elke hardware. Idealiter zouden de gewone stukken in een bibliotheek worden geplaatst en aan elke versie worden gekoppeld. De gewone stukken konden echter niet in een gedeelde bibliotheek worden gecompileerd. Het moest met elke andere configuratie worden gecompileerd.

In eerste instantie heb ik elke configuratie handmatig gecompileerd. Het kostte maar een paar seconden om tussen configuraties, en het was niet zo erg. Tegen het einde van het project werd een kritiek defect ontdekt in het gedeelde gedeelte van de code, waar een apparaat in wezen de communicatiebus zou overnemen. Dit was SLECHT! Echt slecht. Ik heb de bug in de code gevonden, deze gerepareerd en elke versie opnieuw gecompileerd. Behalve een. Tijdens het bouwproces raakte ik afgeleid en vergat ik er een. De binaire bestanden zijn vrijgegeven, de machine is gebouwd en een dag later krijg ik een telefoontje dat de machine niet meer reageert. Ik keek ernaar en ontdekte dat een apparaat de bus had vergrendeld. “Maar ik heb die bug gerepareerd!”.

Ik heb het misschien gerepareerd, maar het is nooit op dat ene bord terechtgekomen. Waarom? Omdat ik geen geautomatiseerd bouwproces had dat elke versie met 1 klik bouwde.

Opmerkingen

• En je kunt koffie gaan drinken terwijl de build-script wordt uitgevoerd!

Als alles wat je ooit wilt doen , build-scripts dienen weinig doel (hoewel je kunt beweren dat als je een Makefile in het project ziet, je weet dat je het kunt bouwen met make). Het punt is – niet-triviale projecten vereisen meestal meer dan dat – je” zult op zijn minst gewoonlijk bibliotheken moeten toevoegen en (naarmate het project ouder wordt) buildparameters configureren.

IDEs zijn meestal tenminste zo configureerbaar – maar nu vertrouwt het bouwproces op IDE-specifieke opties.Als je Eclipse gebruikt, geeft Alice de voorkeur aan NetBeans en wil Bob IntelliJ IDEA , u kunt “de configuratie niet delen, en wanneer een van u een wijziging doorvoert in het bronbeheer, moeten ze de door IDE gemaakte configuratiebestanden van de andere ontwikkelaars, of breng de andere ontwikkelaars op de hoogte, zodat ze het zelf zullen doen (wat betekent dat er commits zullen zijn waar de IDE-configuratie verkeerd is voor sommige IDEs …).

Je moet ook zoek uit hoe je die verandering kunt aanbrengen in elk van de IDEs die door het team worden gebruikt, en of een van hen die specifieke instelling niet ondersteunt …

Nu is dit probleem cultuurafhankelijk – uw ontwikkelaars vinden het misschien acceptabel om niet de keuze uit IDEs te hebben. Maar ontwikkelaars die ervaring hebben met een IDE zijn meestal zowel gelukkiger als efficiënter bij het gebruik ervan, en gebruikers van teksteditors hebben de neiging om religieus ijverig te worden over hun favoriet om ols, dus dit is een van de plaatsen waar je de ontwikkelaars vrijheid wilt geven – en door systemen te bouwen kun je dat ook doen. Sommige mensen hebben misschien een voorkeur voor een build-systeem, maar het is lang niet zo fanatiek als IDE / editor-voorkeuren …

Zelfs als je alle ontwikkelaars dezelfde IDE laat gebruiken – veel succes met het overtuigen van de build server om het te gebruiken …

Nu, dat is voor de eenvoudige aanpassingen van het bouwproces, waar IDEs vaak een mooie GUI voor bieden. Als je meer complexe dingen wilt – zoals voorverwerken / automatisch genereren van bronbestanden voor de compilatie – zul je meestal een voorgebouwd script moeten schrijven in een basistekstgebied binnen de configuratie van de IDE. In welke build-systemen zou je dat gedeelte nog moeten coderen, maar je kunt het doen in de eigenlijke editor waarin je de code schrijft, en nog belangrijker: het framework van het build-systeem zelf biedt meestal enige ondersteuning voor het organiseren van deze scripts.

Eindelijk – build-systemen zijn goed voor meer dan alleen het bouwen van het project – je kunt ze programmeren om andere taken uit te voeren die iedereen in het team mogelijk moet uitvoeren. In Ruby on Rails , er zijn bijvoorbeeld build-systeemtaken voor het uitvoeren van databasemigraties, voor het opschonen van tijdelijke bestanden, enz. Door deze taken in het build-systeem te plaatsen, zorgt u ervoor dat iedereen in het team ze consistent kan uitvoeren.

Reacties

• Het ‘ is niet alleen een kwestie van verschillende IDEs. Sommige ontwikkelaars haten en verafschuwen alle soorten IDEs.
• @DavidHammen Ik ‘ ben een van deze ontwikkelaars (hoewel ik ‘ heb mijn Vim zo moeilijk geconfigureerd dat ‘ s mogelijk dat ik er een IDE van heb gemaakt …), en tijdens het schrijven van die paragraaf schreef ik automatisch ” editors ” en moest het repareren op IDE, omdat ik denk dat de armatuur op IDEs een belangrijk onderdeel is van mijn antwoord. De vragensteller komt duidelijk uit de IDE-wereld, en de vraag spreekt over IDE-loze ontwikkeling als iets dat je moet doen als er geen goede IDE beschikbaar is. Het punt van dit antwoord is om te laten zien hoe het bouwen van systemen zelfs gunstig is voor teams die puur uit IDE-gebruikers bestaan.
• Ik ben ook een van die ontwikkelaars. Ik wil niet ‘ niet dat mijn vingers het toetsenbord moeten verlaten. Dit onderbreekt mijn denkprocessen.
• Ik ben het daar niet mee eens. Ik geef de voorkeur aan IDEs. Ze zorgen ervoor dat ik me niet druk maak om namen, gemakkelijke opzoekingen, refactoring, mooie gebruikersinterface. Ik bedoel, als een IDE iets voor me kan doen dat ik anders zou doen met sed ack etc, dan gebruik ik dat.
• Het punt is dat met build-scripts elke ontwikkelaar in het team kan gebruiken wat hij maar wil, terwijl je met de IDE ‘ s build-functionaliteit iedereen dwingt om niet alleen een IDE te gebruiken, maar ook om de zeer specifieke IDE te gebruiken waarvoor het project is geconfigureerd (tenzij je het hebt geconfigureerd voor meerdere IDEs, en veel succes met het synchroniseren van dat …)

Veel IDEs verpakken de gebruikte commandos eenvoudigweg om iets te bouwen en vervolgens een script te genereren en het aan te roepen!

In Visual Studio kunt u bijvoorbeeld de opdrachtregelparameters voor een C ++ – compilatie zien in het “opdrachtregel” -vak. Als je de build-uitvoer goed bekijkt, “zie je het tijdelijke bestand dat het build-script bevat dat werd gebruikt om de compilatie uit te voeren.

Tegenwoordig is het allemaal MSBuild , maar dat wordt nog steeds rechtstreeks door de IDE uitgevoerd.

Dus de reden dat u de opdrachtregel gebruikt, is dat u rechtstreeks naar de bron gaat en de middelste man overslaat, een tussenpersoon die mogelijk is bijgewerkt of een hoop afhankelijkheden nodig heeft die u gewoon niet wilt of nodig hebt op een headless-server die fungeert als uw continue integratie (CI) server.

Bovendien doen uw scripts meer dan de gebruikelijke ontwikkelaargerichte stappen waarvoor ze zijn ontworpen.Na een build wilt u bijvoorbeeld misschien dat uw binaire bestanden worden verpakt en naar een speciale locatie worden gekopieerd, of een installatiepakket wordt gemaakt of een documentatietool erop wordt uitgevoerd. Veel verschillende taken worden uitgevoerd door een CI-server die zinloos zijn op een ontwikkelaarsmachine, dus hoewel je een IDE-project zou kunnen maken dat al deze stappen heeft uitgevoerd, zou je er dan twee moeten onderhouden – een project voor ontwikkelaars en een ander voor builds. Sommige build-taken (bijvoorbeeld statische analyse) kunnen lang duren die u niet zou willen voor ontwikkelaarsprojecten.

Kortom, het is gewoon eenvoudiger – maak een script om alle dingen te doen die u want en het is snel en eenvoudig om dat te starten op de opdrachtregel of een build-serverconfiguratie.

make 

is veel gemakkelijker te onthouden en te typen dan

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 

En projecten kunnen zeer complexe compilatieopdrachten hebben. Een build-script heeft ook de mogelijkheid om alleen de dingen die zijn gewijzigd, opnieuw te compileren. Als je een schone build wilt doen, is

make clean 

gemakkelijker en betrouwbaarder eenmaal correct ingesteld dan elke plaats die een tussenbestand kan hebben te onthouden geproduceerd.

Natuurlijk, als je een IDE gebruikt, is klikken op een build- of clean-knop natuurlijk ook gemakkelijk. Het is echter veel moeilijker om het verplaatsen van de cursor naar een specifieke plaats op het scherm te automatiseren, vooral wanneer die plaats kan bewegen als het venster beweegt, dan om een eenvoudig tekstcommando te automatiseren.

Hoe zou je het anders doen? De enige andere manier is om een lange opdrachtregelopdracht op te geven.

Een andere reden is dat makefiles maken incrementele compilatie mogelijk, wat de compilatietijd aanzienlijk versnelt.

Makefiles kan ook een platformoverschrijdend buildproces maken. CMake genereert verschillende build-scripts op basis van het platform.

Bewerken:

Met een IDE ben je gebonden aan een bepaalde manier om dingen te doen. Veel mensen gebruiken vim of emacs, ook al hebben ze niet veel IDE-achtige functies. Ze doen het omdat ze de kracht willen die deze editors voorzien. Build-scripts zijn nodig voor degenen die geen IDE gebruiken.

Zelfs voor degenen die een IDE gebruiken, wil je misschien echt weten wat er aan de hand is, dus het build-script biedt je de laagste details van implementatie die een GUI-benadering niet heeft.

IDEs zelf gebruiken vaak ook intern scripts; de run-knop is gewoon een andere manier om het make-commando uit te voeren.

De bovenstaande antwoorden bestrijken veel goeds, maar een voorbeeld uit de echte wereld dat ik zou willen toevoegen (dat ik niet als commentaar kan toevoegen omdat ik geen karma heb), is van Android-programmering.

Ik ben een professionele Android / iOS / Windows Telefoonontwikkelaar en ik gebruik APIs voor Google-services (meestal Google Maps) een lot .

In Android , voor deze services moet ik een keystore toevoegen, of een type ontwikkelaar-ID-bestand dat Google vertelt dat ik ben wie ik zeg dat ik ben, naar een ontwikkelaarsconsole. Als mijn app is gecompileerd met een andere keystore, werkt het Google Maps-gedeelte van de app niet.

In plaats van een dozijn keystores aan de ontwikkelaarsconsole toe te voegen en te beheren, waarvan er maar één daadwerkelijk kan worden gebruikt om de app toch bij te werken, neem ik deze keystore op in onze beveiligde opslagplaats en gebruik Gradle om Android Studio precies te vertellen welke keystore moet worden gebruikt bij het bouwen voor “debug” of “release”. Nu hoef ik nog maar twee keystores toe te voegen aan mijn Google-ontwikkelaarsconsole, één voor “debug” en één voor “release”, en al mijn teamleden kunnen de repo klonen en direct beginnen met ontwikkelen zonder naar de ontwikkelaar te hoeven gaan console en voeg de SHA-hash van hun specifieke keystore toe, of erger nog, waardoor ik ze beheer . Dit heeft als bijkomend voordeel dat elk teamlid een kopie krijgt van de ondertekeningssleutelopslag, wat betekent dat als ik niet op kantoor ben en er een update is gepland, een teamlid slechts een zeer korte lijst met instructies hoeft te volgen om een update.

Door automatisering op deze manier te bouwen, blijft de opbouw consistent en worden technische schulden verminderd door de insteltijd te verkorten wanneer we een nieuwe ontwikkelaar of een nieuwe machine krijgen, of wanneer we een machine.

Voordelen van build-script:

• wijzigingen zien eruit als code (voor voorbeeld, in een git diff commando), niet zoals verschillende aangevinkte opties in een dialoogvenster

• meer output creëren dan een simpele build

In sommige van mijn vorige projecten heb ik “de build-scripts gebruikt om:

• de projectdocumentatie te genereren (op doxygen gebaseerd)
• build
• eenheidstests uitvoeren
• dekkingsrapporten voor eenheidstests genereren
• binaire bestanden in een release-archief verpakken
• interne release-opmerkingen genereren (op basis van “git log” -berichten )
• geautomatiseerd testen

Vaak kun je de “build” -knop aanroepen op een geautomatiseerde manier (Visual Studio accepteert bijvoorbeeld opdrachtregelargumenten). Mensen schrijven build-scripts zodra ze iets nodig hebben dat de build-knop niet kan bieden.

De meeste IDEs laten u bijvoorbeeld alleen bouwen één platform tegelijk. Of slechts één taal per keer. Dan is er wat je doet met de ingebouwde outputs: kan je IDE ze allemaal samenvoegen tot een installatiepakket?