Jaké jsou výhody sestavovacích skriptů?

Automatizace.

Když vyvíjíte, pouze v nejjednodušších projektech bude výchozí tlačítko „stavět“ vše, co k tomu potřebujete; možná budete muset vytvořit WS z API, generovat dokumenty, propojit s externími prostředky, nasadit změny na server atd. Některá IDE vám umožňují přizpůsobit proces sestavení přidáním dalších kroků nebo stavitelů, ale to znamená pouze to, že jste generování sestavovacího skriptu prostřednictvím komodit IDE.

Vývoj systému však není jen psaní kódu. Jedná se o několik kroků. Skript nezávislý na IDE lze spustit automaticky, což znamená, že:

• Když provedete změnu v řízení verzí, může server automaticky spustit nové sestavení. Zajistí, že jste nezapomněli spáchat cokoli potřebné pro sestavení.

• Podobně po dokončení sestavení lze automaticky spustit testy, abyste zjistili, zda jste něco nezlomili.

• Zbytek organizace (QA, sysadmins) má nyní vytvořený produkt, který je

  a) dokonale reprodukovatelný pouze z kontrolní verze.

  b) je společný pro všechny.

I když jsem pracoval jako tým jednoho člověka, použil jsem pro tento účel skripty; když jsem vyvinul opravu, zavázal bych se k SVN, exportovat SVN zpět do jiného adresáře a pomocí build skriptu vygenerovat řešení, které by pak šlo do Preproduction systems a později do Production. Pokud si o několik týdnů později (s již změněnou místní databází kódů) někdo stěžoval na chybu, věděl bych přesně, kterou revizi SVN budu muset zkontrolovat, abych mohl správně ladit systém.

Komentáře

• Toto je nejlepší odpověď IMHO. Každý má pravdu se svým nápadem, ale tento opravdu ukazuje, proč chcete vytvářet skripty. Protože podporují automatizaci, která bude postupovat, jak se projekt rozšiřuje, vám ušetří spoustu času.
• @Alexus Nejen čas, ale i hloupé chyby. 😉 “ Opakování vede k nudě. Nuda vede k děsivým chybám. Děsivé chyby vedou k, ‚ přál bych si, abych se stále nudil.‘ “ (Mohli byste také měřit hloupé chyby v čase, ale ‚ s důležité si uvědomit, že ‚ vám šetří čas z několika příčin.)
• Dokonce iu projektů s jednou osobou je spuštěn místní server Jenkins pro automatizaci “ sestavení v samostatném adresáři “ může pomoci. ‚ Pracuji na něčem pod Windows, které potřebuji potvrdit také křížové kompilace, takže mít Jenkins sestavovat a spouštět testy, pak vytvořit křížově kompilovanou verzi mě dělá mnohem jistější ( a samozřejmě efektivní!), když potřebuji vydat opravy chyb.
• Nesouhlasím s argumentem reprodukovatelných verzí ‚. V dnešních sestavovacích systémech je tolik nekontrolovaných proměnných, že je docela těžké získat reprodukovatelné sestavení. Váš argument zní, jako byste to dostali z krabice, což zcela není pravda.
• @JonasGr ö ger Automation vyřadí jednu z největší proměnné: lidé.

Podobně jako u kódu je i skript sestavení spuštěn počítačem. Počítače jsou výjimečně dobré v dodržování řady pokynů. Ve skutečnosti (mimo samočinně se měnící kód) budou počítače při stejném vstupu provádět stejnou posloupnost pokynů přesně stejným způsobem. Tím je zajištěna úroveň konzistence, které se může vyrovnat pouze počítač.

Naproti tomu my vodou plněné fleshbagy jsme při následujících krocích prostě vyloženě opovrženíhodní. Ten otravný analytický mozek má tendenci zpochybňovat všechno, na co narazí. „Ach … to nemusím,“ nebo „Opravdu použiji tuto vlajku? No … já to prostě ignoruji. Kromě toho máme tendenci se uspokojovat. Jakmile několikrát něco uděláme, začneme věřit, že pokyny známe, a nemusíme se dívat na instruktážní list.

Od „Pragmatického programátora“:

Kromě toho chceme v projektu zajistit konzistenci a opakovatelnost. Ruční postupy ponechávají konzistenci na změně; opakovatelnost není zaručena, zvláště pokud jsou aspekty postupu otevřené interpretaci různými lidmi.

Kromě toho jsme při provádění pokynů HILARIOUSLIVÍ ( ve srovnání s počítačem). U velkého projektu se stovkami souborů a konfigurací by trvalo několik let, než ručně provedete všechny kroky procesu sestavení.

Uvedu příklad ze skutečného světa. Pracoval jsem s nějakým vestavěným softwarem, kde byla většina kódu sdílena na několika různých hardwarových platformách. Každá platforma měla jiný hardware, ale většina softwaru byla stejná. Existovaly však malé kousky, které byly specifické pro každý hardware. V ideálním případě by běžné kousky byly umístěny do knihovny a propojeny do každé verze. Běžné kousky však nemohly být zkompilovány do sdílené knihovny. Muselo to být zkompilováno s každou jinou konfigurací.

Zpočátku jsem každou konfiguraci zkompiloval ručně. Přepínání mezi nimi trvalo jen několik sekund. konfigurací a nebyla to tak velká bolest. Ke konci projektu byla objevena kritická vada ve sdílené části kódu, kde by zařízení v podstatě převzalo komunikační sběrnici. To bylo ŠPATNÉ! Opravdu špatné. Našel jsem chybu v kódu, opravil ji a překompiloval každou verzi. Až na jednoho. Během procesu sestavování jsem se rozptýlil a jeden jsem zapomněl. Binární soubory byly uvolněny, stroj byl postaven a o den později mi telefonoval, že stroj přestal reagovat. Zkontroloval jsem to a zjistil jsem, že zařízení zamklo autobus. „Ale opravil jsem tu chybu!“.

Možná jsem ji opravil, ale nikdy se na tu jednu desku nedostal. Proč? Protože jsem neměl automatizovaný proces sestavování, který by vytvořil jednu verzi s jediným kliknutím.

Komentáře

• A můžete jít na kávu, zatímco Sestavovací skript běží!

Pokud vše, co kdy chcete, je <compiler> **/*.<extension> vytvářejí skripty málo účelné (lze však namítnout, že pokud v projektu uvidíte Makefile, víte, že jej můžete vytvořit pomocí make). Jde o to – netriviální projekty obvykle vyžadují víc než to – přinejmenším budete obvykle muset přidat knihovny a (jak projekt zraje) konfigurovat parametry sestavení.

IDE jsou obvykle přinejmenším tak konfigurovatelná – nyní se však proces sestavování spoléhá na možnosti specifické pro IDE.Pokud používáte Eclipse , Alice dává přednost NetBeans a Bob chce použít IntelliJ IDEA , nemůžete sdílet konfiguraci, a když jeden z vás provede změnu zdroje, musí buď ručně upravit konfigurační soubory vytvořené IDE ostatním vývojářům, nebo informujte ostatní vývojáře, aby si to udělali sami (což znamená, že budou existovat závazky, pokud bude konfigurace IDE u některých IDE chybná …).

Musíte také přijít na to, jak provést tuto změnu v každém IDE používaném týmem, a pokud jeden z nich nepodporuje konkrétní nastavení …

Nyní je tento problém závislý na kultuře – vašim vývojářům se může zdát přijatelné, že nemají na výběr IDE. Vývojáři, kteří mají zkušenosti s IDE, jsou však při jeho používání obvykle šťastnější a efektivnější a uživatelé textových editorů mají tendenci být nábožensky nadšení pro své oblíbené ols, takže toto je jedno z míst, kde chcete dát svobodu vývojářům – a sestavovací systémy vám umožňují právě to. Někteří lidé mohou mít předvolby systému sestavení, ale není to tak fanatické jako předvolby IDE / editoru …

I když přimíte všechny vývojáře používat stejné IDE – hodně štěstí při přesvědčování sestavení server, aby jej použil …

Nyní, kvůli jednoduchému přizpůsobení procesu sestavení, mají IDE tendenci poskytovat pěkné grafické uživatelské rozhraní. Pokud chcete složitější věci – například předzpracování / automatické generování zdrojových souborů před kompilací – obvykle musíte napsat skript před sestavením v nějaké základní textové oblasti uvnitř konfigurace IDE. Které systémy sestavení byste tuto část ještě museli kódovat, ale můžete to udělat ve skutečném editoru, do kterého kód napíšete, a co je důležitější: samotný rámec systému sestavení obvykle poskytuje určitou podporu pro organizaci těchto skriptů.

Nakonec – sestavovací systémy jsou dobré nejen pro stavbu projektu – můžete je naprogramovat tak, aby plnily další úkoly, které by všichni v týmu mohli potřebovat. V Ruby on Rails , například, existují úlohy sestavení systému pro spuštění migrace databáze, čištění dočasných souborů atd. Umístěním těchto úkolů do systému sestavení zajistíte, aby je každý v týmu mohl provádět konzistentně.

Komentáře

• Není to ‚ jen záležitostí různých IDE. Někteří vývojáři nenávidí a nenávidí IDE všech typů.
• @DavidHammen Jsem ‚ jedním z těchto vývojářů (i když jsem ‚ nakonfiguroval svůj Vim tak tvrdě, je ‚ je možné, že jsem z něj mohl udělat IDE …) a při psaní tohoto odstavce jsem automaticky psal “ editory “ a musel jsem to opravit na IDE, protože si myslím, že přípravek na IDE je důležitou součástí mé odpovědi. Asker zjevně pochází ze světa IDE a otázka hovoří o vývoji bez IDE jako o něčem, k čemu jste nuceni dělat, když není k dispozici správné IDE. Smyslem této odpovědi je ukázat, jak jsou systémy sestavení výhodné i pro týmy složené čistě z uživatelů IDE.
• I já jsem jedním z těchto vývojářů. Nechci ‚, aby mé prsty musely opustit klávesnici. Přeruší to moje myšlenkové pochody.
• Nesouhlasím. Dávám přednost IDE. Umožňují mi nezajímat se o jména, snadné vyhledávání, refaktorování, pěkné uživatelské rozhraní. Mám na mysli, že pokud pro mě IDE může udělat něco, co bych jinak udělal se sed ack atd., Používám to.
• Jde o to, že s vývojovými skripty může každý vývojář v týmu použít vše, co preferuje, zatímco s funkcemi sestavení IDE ‚ nutíte každého nejen používat IDE, ale také používat velmi specifické IDE, pro které je projekt nakonfigurován (pokud jej nemáte nakonfigurovaný pro více IDE a hodně štěstí při synchronizaci …)

Mnoho IDE jednoduše zabalí použité příkazy vytvořit něco a poté vygenerovat skript a zavolat ho!

Například v Visual Studio můžete vidět parametry příkazového řádku pro kompilaci C ++ v poli „příkazového řádku“. Pokud se podíváte pozorně na výstup sestavení, uvidíte dočasný soubor obsahující skript sestavení, který byl použit ke spuštění kompilace.

V dnešní době je to vše MSBuild , ale ten je stále spuštěn přímo z IDE.

Takže důvod, proč používáte příkazový řádek, je ten, že jdete přímo ke zdroji a přeskočíte prostředníka, prostředník, který mohl být aktualizován nebo vyžadovat hromadu závislostí, které právě nechcete nebo nepotřebujete na bezhlavém serveru, který funguje jako vaše kontinuální integrace (CI) server.

Kromě toho vaše skripty dělají více než obvyklé kroky pro vývojáře, pro které jsou navrženy.Například po sestavení můžete chtít své binární soubory zabalit a zkopírovat do zvláštního umístění nebo vytvořit instalační balíček nebo na nich spustit dokumentační nástroj. Server CI provádí mnoho různých úkolů, které jsou na vývojářském počítači nesmyslné, takže zatímco byste mohli vytvořit projekt IDE, který provedl všechny tyto kroky, musíte udržovat dva z nich – projekt pro vývojáře a další pro sestavení. Některé úlohy sestavení (například statická analýza) mohou trvat dlouho, co byste pro vývojářské projekty nechtěli.

Stručně řečeno, je to prostě jednodušší – vytvořte skript, který vám umožní dělat všechny věci chtít a je to rychlé a jednoduché nastartovat pomocí příkazového řádku nebo konfigurace serveru sestavení.

make 

je mnohem snadnější zapamatovat si a psát než

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 

A projekty mohou mít velmi složité příkazy pro kompilaci. Skript sestavení má také schopnost pouze překompilovat věci, které se změnily. Pokud chcete vytvořit čisté sestavení,

make clean 

je snadnější a spolehlivější, jakmile je správně nastaveno, než se snažit zapamatovat si každé místo, které může mít přechodný soubor byly samozřejmě vyrobeny.

Samozřejmě, pokud používáte IDE, snadné je také kliknutí na tlačítko sestavení nebo vyčištění. Je však mnohem obtížnější automatizovat přesun kurzoru na konkrétní místo na obrazovce, zejména když se toto místo může pohybovat, pokud se okno pohne, než automatizovat jednoduchý textový příkaz.

Jak jinak byste to udělali? Jediným dalším způsobem je zadat jeden dlouhý příkaz z příkazového řádku.

Dalším důvodem je, že makefiles umožňují inkrementální kompilaci, což hodně zkrátí čas kompilace.

Makefiles může také vytvořit proces sestavení napříč platformami. CMake generuje různé skripty sestavení na základě platformy.

Upravit:

S IDE jste svázáni s konkrétním způsobem, jak dělat věci. Mnoho lidí používá vim nebo emacs, i když nemají mnoho funkcí podobných IDE. Dělají to proto, že chtějí sílu těchto poskytují redaktoři. Sestavovací skripty jsou nezbytné pro ty, kteří nepoužívají IDE.

I pro ty, kteří používají IDE, možná budete chtít opravdu vědět, o co jde, takže skript pro sestavení vám nabídne podrobné podrobnosti implementace, kterou přístup pomocí grafického uživatelského rozhraní nemá.

Samotná IDE často používají skripty také interně; tlačítko spuštění je jen další způsob spuštění příkazu make.

Výše uvedené odpovědi pokrývají hodně dobrého základu, ale jeden příklad z reálného světa, který bych chtěl přidat (který nemohu přidat jako komentář kvůli žádné karmě), je z programování pro Android.

Jsem profesionální Android / iOS / Windows Vývojář telefonů a já používám API služeb Google (většinou Mapy Google) lot .

V systému Android , tyto služby vyžadují, abych přidal úložiště klíčů , nebo typ souboru ID vývojáře, který Googlu řekne, že jsem, kdo říkám, že jsem, do vývojářské konzole. Pokud je moje aplikace kompilována s jiným úložištěm klíčů, část aplikace Mapy Google nebude fungovat.

Místo přidání a správy tuctu úložišť klíčů do vývojářské konzole, z nichž pouze jeden může být skutečně použit k aktualizaci aplikace, zahrnuji tento úložiště klíčů do našeho zabezpečeného úložiště a pomocí Gradle řekněte Android Studio přesně, jaký úložiště klíčů použít při vytváření pro „ladění“ nebo „vydání“. Nyní musím do své vývojářské konzole Google přidat pouze dvě úložiště klíčů, jedno pro „debug“ a druhé pro „vydání“, a všichni členové mého týmu mohou klonovat repo a dostat právo na vývoj, aniž by museli jít do dev konzole a přidejte hash SHA jejich konkrétního úložiště klíčů, nebo ještě hůř, což mě přiměje spravovat je . To má další výhodu v tom, že každému členovi týmu dáte kopii úložiště klíčů pro podepisování, což znamená, že pokud jsem mimo kancelář a je naplánována aktualizace, musí člen týmu postupovat podle velmi krátkého seznamu pokynů, aby mohl aktualizovat.

Automatizace sestavení, jako je tato, udržuje konzistentní sestavení a snižuje technický dluh snížením doby nastavení, když získáme nového vývojáře, nový stroj nebo když musíme znovu vytvořit obraz stroj.

Vytvoření výhod skriptu:

• Změny vypadají jako kód (pro například v příkazu git diff), ne jako různé zaškrtnuté možnosti v dialogu

• vytváření více výstupu než jednoduché sestavení

V některých svých předchozích projektech jsem pomocí sestavovacích skriptů:

• vygeneroval projektovou dokumentaci (založenou na doxygenu)
• sestavil
• spusťte testy jednotek
• generujte zprávy o pokrytí testů jednotek
• zabalte binární soubory do archivu vydání
• vygenerujte interní poznámky k vydání (na základě zpráv „git log“) )
• automatické testování

často můžete volat tlačítko „build“ automatizovaným způsobem (Visual Studio přijímá například argumenty příkazového řádku). Lidé píší sestavovací skripty, jakmile potřebují něco, co tlačítko sestavení nemůže poskytnout.

Například většina IDE vám umožní pouze sestavení jedna platforma najednou. Nebo pouze jedna jazyk najednou. Pak je tu to, co děláte s vestavěnými výstupy: může je vaše IDE převést všechny do instalačního balíčku?