Care sunt avantajele scripturilor de construire?

Automatizare.

Când vă dezvoltați, numai în cele mai simple proiecte, butonul implicit „construiți” va face tot ce aveți nevoie; poate fi necesar să creați WS din API-uri, să generați documente, să faceți legătura cu resurse externe, să implementați modificările pe un server etc. Unele IDE vă permit să personalizați procesul de compilare adăugând pași suplimentari sau constructori, dar asta înseamnă doar că sunteți generarea scriptului de compilare prin mărfurile IDE.

Dar dezvoltarea unui sistem nu înseamnă doar scrierea codului. Există mai mulți pași implicați. Un script independent IDE poate fi executat automat, ceea ce înseamnă că:

• Când comiteți o modificare a controlului de versiune, o nouă versiune poate fi lansată automat de server. Se va asigura că nu ați uitat să comiteți nimic necesar pentru construire.

• În mod similar, după ce se realizează construirea, testele pot fi executate automat pentru a vedea dacă ați spart ceva.

• Acum, restul organizației (QA, sysadmins) are un produs încorporat care

  a) este perfect reproductibil doar din versiunea de control.

  b) este comun tuturor.

Chiar și când am lucrat ca o echipă one man, am folosit scripturi în acest scop; când am dezvoltat remedierea, mă angajam la SVN, exportam SVN înapoi în alt director și foloseam scriptul de construire pentru a genera soluția, care urma să meargă apoi la sistemele de preproducție și mai târziu la producție. Dacă câteva săptămâni mai târziu (cu baza mea de cod locală deja modificată) cineva s-a plâns de o eroare, aș ști exact ce revizie SVN ar trebui să verific pentru a depana corect sistemul.

Comentarii

• Acesta este cel mai bun răspuns IMHO. Toată lumea are dreptate cu ideea sa, dar aceasta arată cu adevărat de ce doriți să construiți scripturi. Deoarece acestea acceptă automatizarea, care se desfășoară pe măsură ce proiectul se extinde, vă va economisi o mulțime de timp.
• @Alexus Nu doar timp, ci și greșeli stupide. 😉 ” Repetarea duce la plictiseală. Plictiseala duce la greșeli îngrozitoare. Greșelile îngrozitoare duc la, ‘ Aș vrea să mă plictisesc în continuare.’ ” (Ați putea măsura și greșeli stupide în timp, dar ‘ s important să ne dăm seama că ‘ vă economisește timp din mai multe cauze.)
• Chiar și pentru proiecte individuale, rularea unui server Jenkins local pentru automatizarea ” construirea într-un director separat ” vă poate ajuta. ‘ Mă lucrez la ceva sub Windows pe care trebuie să-l confirm și pentru compilații încrucișate, așa că dacă Jenkins construiește și rulează teste, apoi construiesc versiunea încrucișată mă face mult mai sigur ( și eficient, bineînțeles!) când trebuie să lansez remedieri de erori.
• Nu ‘ nu sunt de acord cu argumentul versiunilor reproductibile. Există atât de multe variabile necontrolate în sistemele de construcții de astăzi încât este destul de greu să obții versiuni reproductibile. Argumentul dvs. sună de parcă veți obține acest lucru imediat, ceea ce nu este total adevărat.
• @JonasGr ö ger Automation scoate unul dintre cele mai mari variabile: oameni.

La fel ca codul, un script de compilare este executat de computer. Computerele sunt excepțional de bune când respectă un set de instrucțiuni. De fapt, (în afara codului de auto-modificare), computerele vor executa aceeași secvență de instrucțiuni exact în același mod, având aceeași intrare. Acest lucru oferă un nivel de consistență pe care, bine, numai un computer îl poate potrivi.

În schimb, sacii de carne plini de apă sunt pur și simplu de dispreț când vine vorba de următorii pași. Creierul analitic plictisitor are tendința de a pune la îndoială tot ce întâlnește. „Oh … nu am nevoie de asta” sau „Chiar trebuie să folosesc acest steag? Eh … doar o voi ignora. În plus, avem tendința de a ne mulțumi. Odată ce am „făcut ceva de câteva ori, începem să credem că știm instrucțiunile și nu trebuie să ne uităm la foaia de instrucțiuni.

Din„ Programatorul pragmatic ”:

În plus, dorim să asigurăm coerența și repetabilitatea proiectului. Procedurile manuale lasă coerența la schimbare; repetabilitatea nu este garantată, mai ales dacă aspectele procedurii sunt deschise interpretării de către diferiți oameni.

În plus, suntem lente în instrucțiunile de executare ( în comparație cu un computer). Pe un proiect mare, cu sute de fișiere și configurații, ar dura ani pentru a executa manual toți pașii dintr-un proces de construire.

Vă voi oferi un exemplu real. Lucram la un software încorporat, unde cea mai mare parte a codului a fost partajată pe câteva platforme hardware diferite. Fiecare platformă avea hardware diferit, dar majoritatea software-ului era același. Dar existau mici piese care erau specifice fiecărui hardware. În mod ideal, piesele comune ar fi plasate într-o bibliotecă și conectate la fiecare versiune. Cu toate acestea, piesele comune nu au putut fi compilate într-o bibliotecă partajată. Trebuia să fie compilată cu fiecare configurație diferită.

La început, am compilat manual fiecare configurație. A trecut doar câteva secunde pentru a comuta între configurații și nu era atât de dureros. Spre sfârșitul proiectului, a fost descoperit un defect critic în porțiunea partajată de cod, unde un dispozitiv ar prelua în esență magistrala de comunicații. A fost RĂU! Într-adevăr rău. Am găsit eroarea în cod, am remediat-o și am recompilat fiecare versiune. Cu excepția unuia. În timpul procesului de construcție, m-am distras și am uitat unul. Binarele au fost eliberate, mașina a fost construită și, o zi mai târziu, primesc un telefon spunând că mașina a încetat să mai răspundă. Am verificat-o și am descoperit că un dispozitiv a blocat autobuzul. „Dar am remediat acea eroare!”.

Poate că am rezolvat-o, dar niciodată nu și-a găsit drumul pe acea placă. De ce? Deoarece nu am avut un proces de construire automatizat care să construiască fiecare versiune cu un singur clic.

Comentarii

• Și puteți merge la cafea în timp ce scriptul de compilare rulează!

Dacă tot ce vrei să faci este <compiler> **/*.<extension>, scripturile de construire nu au un scop prea mic (deși se poate argumenta că, dacă vedeți un Makefile în proiect, știți că îl puteți construi cu ). Lucrul este că – proiectele non-banale necesită de obicei mai mult decât atât – cel puțin, va trebui de obicei să adăugați biblioteci și (pe măsură ce proiectul se maturizează) să configurați parametrii de construire.

IDE-urile sunt de obicei cel puțin configurabile – dar acum procesul de construire se bazează pe opțiuni specifice IDE.Dacă utilizați Eclipse , Alice preferă NetBeans , iar Bob vrea să utilizeze IntelliJ IDEA , nu puteți partaja configurația și, atunci când unul dintre voi împinge o modificare la controlul sursă, trebuie să editeze manual fișierele de configurare create de IDE ale ceilalți dezvoltatori sau anunțați-i pe ceilalți dezvoltatori, astfel încât să o facă singuri (ceea ce înseamnă că vor exista confirmări în care configurația IDE este greșită pentru unele IDE-uri …).

De asemenea, trebuie să aflați cum să faceți această schimbare în fiecare dintre IDE-urile utilizate de echipă și, dacă una dintre ele nu acceptă setarea respectivă …

Acum, această problemă depinde de cultură – dezvoltatorii dvs. ar putea considera acceptabil să nu aibă posibilitatea de a alege IDE-urile. Dar dezvoltatorii care au experiență cu un IDE sunt, de obicei, atât mai fericiți, cât și mai eficienți atunci când îl folosesc, iar utilizatorii editorului de text tind să devină fanatic religios cu privire la ols, deci acesta este unul dintre locurile în care doriți să dați libertate dezvoltatorilor – iar sistemele de construcție vă permit să faceți exact acest lucru. Unii oameni ar putea avea o preferință de sistem de compilare, dar nu este la fel de fanatică ca preferințele IDE / editor …

Chiar dacă îi faci pe toți dezvoltatorii să folosească același IDE – noroc să convingi construirea server să-l folosească …

Acum, asta este pentru personalizările simple ale procesului de construire, pentru care IDE-urile tind să ofere o interfață grafică bună. Dacă doriți lucruri mai complexe – cum ar fi pre-procesarea / generarea automată a fișierelor sursă înainte de compilare – va trebui, de obicei, să scrieți un script de pre-compilare într-o anumită zonă de text de bază din configurația IDE. Ce sisteme de construcție ar trebui să codificați în continuare acea parte, dar o puteți face în editorul propriu-zis în care scrieți codul și, mai important: cadrul sistemului de construire în sine oferă de obicei un anumit suport pentru organizarea acestor scripturi.

În cele din urmă – sistemele de construcție sunt bune pentru mai mult decât simpla construire a proiectului – le puteți programa pentru a îndeplini alte sarcini de care ar putea avea nevoie toată lumea din echipă. Rails , de exemplu, există sarcini ale sistemului de construire pentru executarea migrărilor bazei de date, pentru curățarea fișierelor temporare etc. Punerea acestor sarcini în sistemul de construire asigură faptul că toată lumea din echipă le poate face în mod consecvent.

Comentarii

• ‘ nu este doar o chestiune de IDE diferite. Unii dezvoltatori urăsc și detestă IDE-urile de toate tipurile.
• @DavidHammen Sunt ‘ unul dintre acești dezvoltatori (deși am ‘ configurat Vim-ul atât de greu este ‘ este posibil să-l fi transformat într-un IDE …), iar în timp ce scria acel paragraf scriam automat ” editori ” și a trebuit să-l fixez la IDE, deoarece cred că dispozitivul de pe IDE este o parte importantă a răspunsului meu. Întrebarea provine în mod clar din lumea IDE, iar întrebarea vorbește despre dezvoltarea fără IDE ca pe un lucru pe care ești obligat să îl faci atunci când nu există un IDE adecvat disponibil. Scopul acestui răspuns este de a arăta cum sistemele de construcție sunt benefice chiar și pentru echipele compuse exclusiv din utilizatori IDE.
• Și eu sunt unul dintre acei dezvoltatori. Nu vreau ‘ să vreau ca degetele mele să părăsească tastatura. Procedând astfel, îmi întrerupe procesele de gândire.
• Nu sunt de acord. Prefer IDE-urile. Îmi permit să nu-mi pese de nume, căutări ușoare, refactorizare, interfață UI frumoasă. Adică, dacă un IDE poate face ceva pentru mine pe care altfel l-aș face cu sed ack etc., îl folosesc.
• Ideea este că, cu scripturile de construire, fiecare dezvoltator din echipă poate folosi orice preferă, în timp ce funcționalitatea de construire a IDE ‘ forțează pe toată lumea nu numai să utilizeze un IDE, ci să utilizeze IDE foarte specific pentru care este configurat proiectul (cu excepția cazului în care îl aveți configurat pentru mai multe IDE și noroc sincronizând asta …)

Multe IDE pur și simplu împachetează comenzile folosite pentru a construi ceva și apoi a genera un script și a-l apela!

De exemplu, în Visual Studio, puteți vedea parametrii liniei de comandă pentru o compilare C ++ în caseta „linie de comandă”. Dacă vă uitați cu atenție la ieșirea de compilare, veți vedea fișierul temporar care conține scriptul de construcție care a fost folosit pentru a rula compilarea.

În zilele noastre, totul este MSBuild , dar acesta este încă executat direct de IDE.

Deci, motivul pentru care utilizați linia de comandă este că mergeți direct la sursă și săriți omul de mijloc, un intermediar care s-ar putea să fi fost actualizat sau să necesite o grămadă de dependențe pe care tocmai nu le doriți sau nu le aveți nevoie pe un server fără cap care acționează ca integrare continuă (CI) server.

În plus, scripturile dvs. fac mai mult decât pașii obișnuiți orientați spre dezvoltatori pentru care au fost proiectați.De exemplu, după o construcție, este posibil să doriți ca binarele dvs. să fie ambalate și copiate într-o locație specială sau să fie creat un pachet de instalare sau să ruleze un instrument de documentare pe ele. Multe sarcini diferite sunt efectuate de un server CI care sunt inutile pe o mașină de dezvoltator, așa că, în timp ce ați putea crea un proiect IDE care să efectueze toți acești pași, atunci ar trebui să întrețineți doi dintre ei – un proiect pentru dezvoltatori și altul pentru versiuni. Unele sarcini de construire (analiza statică, de exemplu) pot dura mult timp pe care nu le-ați dori pentru proiectele de dezvoltatori.

Pe scurt, totuși, este mai ușor – creați un script pentru a face toate lucrurile doresc și este rapid și simplu să dai startul pe linia de comandă sau pe o configurație a serverului de construire.

make 

este mult mai ușor de reținut și de tastat decât

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 

Și proiectele pot avea comenzi de compilare foarte complexe. Un script de construire are, de asemenea, capacitatea de a recompila numai lucrurile care s-au schimbat. Dacă doriți să faceți o construcție curată,

make clean 

este mai ușor și mai fiabil după configurarea corectă decât încercarea de a vă aminti fiecare loc în care poate avea un fișier intermediar a fost produs.

Desigur, dacă utilizați un IDE, faceți clic și pe un buton de compilare sau de curățare. Cu toate acestea, este mult mai dificil să automatizați mutarea cursorului într-un anumit loc de pe ecran, mai ales atunci când acel loc se poate mișca dacă se mișcă fereastra, decât este să automatizați o comandă simplă de text.

Cum altfel ai face asta? Singura altă modalitate este să specifici o comandă lungă din linia de comandă.

Un alt motiv este că makefiles permit compilarea incrementală, ceea ce accelerează mult timpul de compilare.

Makefiles pot face, de asemenea, un proces de construire pe mai multe platforme. CMake generează diferite scripturi de construire pe baza platformei.

Editați:

Cu un IDE, sunteți legat de un anumit mod de a face lucrurile. Mulți oameni folosesc vim sau emacs, chiar dacă nu au multe caracteristici asemănătoare IDE. O fac pentru că vor puterea acestor editorii furnizează. Scripturile de construcție sunt necesare pentru cei care nu utilizează un IDE.

Chiar și pentru cei care utilizează un IDE, este posibil să doriți să știți cu adevărat ce se întâmplă, astfel încât scriptul de construcție vă oferă detaliile reduse. de implementare pe care o abordare GUI nu o are.

IDE utilizează ei înșiși scripturi de construcție și intern; butonul de rulare este doar un alt mod de a rula comanda make.

Răspunsurile de mai sus acoperă o mulțime de terenuri bune, dar un exemplu din lumea reală pe care „aș dori să-l adaug (pe care nu îl pot adăuga ca un comentariu din cauza lipsei de karma), este din programarea Android.

Sunt un profesionist Android / iOS / Windows Dezvoltator de telefon și folosesc API-urile serviciilor Google (în principal Google Maps) un lot .

În Android , aceste servicii necesită adăugarea unui keystore , sau un tip de fișier de identificare a dezvoltatorului care îi spune Google că sunt cine spun că sunt, într-o consolă pentru dezvoltatori. Dacă aplicația mea este compilată cu un depozit de chei diferit, secțiunea Google Maps a aplicației nu va funcționa.

În loc să adăugăm și să gestionăm o duzină de magazii de chei în consola pentru dezvoltatori, dintre care doar unul poate fi de fapt folosit pentru a actualiza aplicația oricum, includ acest magazin de chei în repo-ul nostru securizat și utilizați Gradle pentru a spune Android Studio exact ce magazin de chei să utilizați atunci când creați pentru „depanare” sau „lansare”. Acum, trebuie să adaug doar două magazii de chei în consola mea pentru dezvoltatori Google, unul pentru „depanare” și unul pentru „lansare”, iar toți membrii echipei mele pot clona repo și pot ajunge direct la dezvoltare fără a fi nevoie să intrați în programul de dezvoltare consola și adăugați hash-ul SHA al magazinului lor de chei special sau, mai rău, făcându-mă să le gestionez . Acest lucru are avantajul suplimentar de a oferi fiecărui membru al echipei o copie a depozitului de chei de semnare, ceea ce înseamnă că dacă sunt în afara biroului și este programată o actualizare, un membru al echipei trebuie să urmeze doar o listă foarte scurtă de instrucțiuni pentru a împinge un actualizare.

Automatizarea construcțiilor astfel păstrează construcțiile constante și reduce datoriile tehnice reducând timpul de configurare atunci când obținem un nou dezvoltator, o nouă mașină sau când trebuie să reimaginăm o mașinărie.

Construiți avantajele scriptului:

• modificările arată ca un cod (pentru de exemplu, într-o comandă git diff), nu ca diferite opțiuni bifate într-un dialog

• creând mai multe rezultate decât o simplă compilare

În unele dintre proiectele mele anterioare, am folosit scripturile de compilare pentru a:

• genera documentația proiectului (pe bază de doxigen)
• a construi
• rulați teste unitare
• generați rapoarte de acoperire a testelor unitare
• împachetați binarele într-o arhivă de versiuni
• generați note de lansare interne (pe baza mesajelor „jurnal jurnal”) )
• testare automată

Adesea puteți apela butonul „build” într-un mod automat (Visual Studio acceptă argumente din linia de comandă, de exemplu). Oamenii scriu scripturi de compilare imediat ce au nevoie de ceva pe care butonul de construire nu îl poate oferi.

De exemplu, majoritatea IDE-urilor vă vor permite să construiți doar o platformă la un moment dat. Sau doar una limbă la un moment dat. Apoi, ce faceți cu ieșirile încorporate: IDE-ul dvs. le poate rula pe toate în pachet de instalare?