Programozói pályafutásom nagy részében a “build / compile / run” parancsot használtam bármilyen IDE-vel, amivel dolgozom, hogy futtatható program. Ez egy gomb, nagyon egyszerű. Amint azonban többet megtudok a különböző nyelvekről és keretrendszerekről, egyre több beszédet látok a “build szkriptekről” (ANT, Maven, Gradle stb.) A projekt futtatásához. Megértettem, hogy ezek az utasítások a fordítóhoz / linkelőhöz / mágikus program-készítőhöz, amelyek meghatározzák a konfiguráció részleteit – apróságokat.
Emlékszem, hogy még az iskolában írtam makefile-eket, de akkor még nem láttam különösebb előnyt (csak Unix terminálban írtuk őket, ahol egy IDE, amelyen “praktikus” build “gomb volt, nem volt Ezen túlmenően más kérdéseket is láttam itt, amelyek megvitatják, hogy a build szkriptek nem csak a programot hozhatják létre – futtathatnak egységteszteket valamint a biztonságos erőforrások, a gazdagéptől függetlenül .
Nem tudom megingatni azt az érzést, hogy a szkriptek összeállítását fontos megérteni fejlesztő, de szeretnék értelmes magyarázatot; miért kell használnom / írni build szkripteket?
A Build Script és a Build Server felelőssége tárgyalja a tágabb körben betöltött szerepet. A build szkript által kínált előnyöket keresem egy IDE “build / run” paranccsal vagy hasonlóan egyszerű módszerekkel szemben.
Kommentárok
Válasz
Automatizálás.
Fejlesztéskor csak a legegyszerűbb projektekben az alapértelmezett “build” gomb mindent megtesz, amire szüksége van; előfordulhat, hogy WS-t kell létrehoznia API-kból, dokumentumokat kell generálnia, külső erőforrásokkal kell összekapcsolnia, telepítenie kell a módosításokat egy kiszolgálóra stb. Egyes IDE-k lehetővé teszik az építési folyamat testreszabását további lépések vagy építők hozzáadásával, de ez csak azt jelenti, a build szkript generálása az IDE árucikkeken keresztül.
De a rendszer fejlesztése nem csak kódírást jelent. Több lépésről van szó. Az IDE-től független parancsfájl automatikusan végrehajtható, ami azt jelenti, hogy:
-
Amikor változtatást hajt végre a verziókezelésen, a szerver automatikusan elindíthat egy új buildet. Biztosítani fogja, hogy ne felejtsen el eltenni semmit, ami szükséges az összeállításhoz.
-
Hasonlóképpen, a build elkészülte után automatikusan futtathatók tesztek is, hogy meghibásodtak-e valamit.
-
Most a szervezet többi részének (QA, sysadmins) van egy beépített terméke, amely
a) tökéletesen reprodukálható csak a vezérlő verzióból.
b) mindegyikük közös.
Még akkor is, ha egyszemélyes csapatként dolgoztam, szkripteket használtam erre a célra; Amikor kidolgoztam a javítást, elkötelezném magam az SVN mellett, exportálnám az SVN-t egy másik könyvtárba, és a build szkript segítségével generálnám a megoldást, amely az előkészítési rendszerekbe, később pedig a produkcióba kerül. Ha néhány héttel később (miután a helyi kódbázisom már megváltozott) valaki hibára panaszkodott, pontosan tudtam, hogy melyik SVN verziót kell kifizetnem a rendszer megfelelő hibakereséséhez.
Megjegyzések
- Ez a legjobb válasz IMHO. Mindenkinek igaza van az ötletével, de ez valóban megmutatja, miért akarsz építeni szkripteket. Mivel támogatják az automatizálást, amely a projekt bővülésével megy előre, rengeteg időt takarít meg.
- @Alexus Nem csak idő, hanem néma hibák is. 😉 ” Az ismétlés unalomhoz vezet. Az unalom szörnyű hibákhoz vezet. Ijesztő hibák vezetnek, ‘ bárcsak unatkoznék.’ ” (Időben is mérhetnél néma hibákat, de ‘ s fontos felismerni, hogy ‘ több okból időt takarít meg.)
- Még egyszemélyes projektek esetén is futtat egy helyi Jenkins szervert a ” külön könyvtárba építés ” segíthet. ‘ Olyan dolgon dolgozom a Windows alatt, amelyet meg kell erősítenem a keresztfordításokat is, tehát ha Jenkins teszteket épít és futtat, majd a keresztfordított verziót elkészítem, akkor sokkal magabiztosabb leszek ( és természetesen hatékony!), amikor hibajavításokat kell kiadnom.
- Nem értek egyet a reprodukálható összeállítások érvével.
Annyi kontrollálatlan változó van a mai build rendszerekben, hogy elég nehéz megismételhető buildeket létrehozni. Az érvelése úgy hangzik, hogy megkapja a dobozon kívüli adatot, ami teljesen nem igaz.
Válasz
A kódhoz hasonlóan a számítógép egy végrehajtó parancsfájlt is végrehajt. A számítógépek kivételesen jól képesek követni az utasításokat. Valójában (az önmódosító kódon kívül) a számítógépek ugyanazt az utasítássorozatot pontosan ugyanúgy hajtják végre, ugyanazon bemenet mellett. Ez olyan konzisztenciát eredményez, amelyhez csak a számítógép képes.
Ezzel szemben mi, vízzel töltött húszsákok csak egyenesen megvetendőek, amikor a következő lépéseket kell végrehajtani. Ez a bosszantó elemző agy hajlamos megkérdőjelezni mindent, amivel csak találkozik. “Ó … erre nincs szükségem”, vagy “Tényleg használjam ezt a zászlót? Eh … csak figyelmen kívül hagyom. Ezenkívül hajlamosak vagyunk az önelégültségre. Miután valamit megtettünk néhányszor, elkezdjük azt hinni, hogy ismerjük az utasításokat, és nem kell megnéznünk az utasításokat.
A “The Pragmatic Programmer” részből:
Ezen felül biztosítani akarjuk a projekt következetességét és ismételhetőségét. A manuális eljárások a következetességet megváltoztathatják; az ismételhetőség nem garantált, különösen akkor, ha az eljárás bizonyos aspektusait különböző emberek értelmezhetik. számítógéphez képest.) Egy nagy projektnél, több száz fájllal és konfigurációval, évekbe telik, mire manuálisan végrehajtja az összes lépést egy építési folyamatban.
Valódi világra példát adok. Néhány beágyazott szoftveren dolgoztam, ahol a kód nagy részét néhány különböző hardverplatformon osztották meg. Mindegyik platformnak más hardvere volt, de a szoftverek nagy része ugyanaz volt. De voltak olyan darabok, amelyek minden hardverre jellemzőek voltak. Ideális esetben a közös darabokat egy könyvtárba helyezik, és összekapcsolják az egyes verziókkal. A közös darabokat azonban nem sikerült megosztott könyvtárba fordítani. Minden más konfigurációval le kellett fordítani.
Eleinte minden egyes konfigurációt kézzel állítottam össze. Csak néhány másodpercig tartott a váltás konfigurációk, és nem volt akkora fájdalom. A projekt vége felé kritikus hibát fedeztek fel a kód megosztott részében, ahol egy eszköz lényegében átveszi a kommunikációs buszt. Ez ROSSZ volt! Nagyon rossz. Megtaláltam a hibát a kódban, kijavítottam és minden verziót újrafordítottam. Egy kivétellel. Az építési folyamat során elterelődtem és elfelejtettem egyet. A bináris fájlokat kiadták, a gépet megépítették, és egy nappal később telefonhívást kaptam, miszerint a gép nem válaszolt. Megnézem, és felfedeztem, hogy egy eszköz lezárta a buszt. “De kijavítottam azt a hibát!”.
Lehet, hogy kijavítottam, de soha nem talált utat arra az egy táblára. Miért? Mivel nem volt olyan automatizált gyártási folyamatom, amely minden egyes verziót 1 kattintással épített volna fel.
Megjegyzések
- És mehet kávézni, miközben a build szkript fut!
Válasz
Ha valaha csak annyit szeretnél tenni, hogy <compiler> **/*.<extension>, a build szkriptek kevés célt szolgálnak (bár lehet azt állítani, hogy ha egy Makefile -t lát a projektben, akkor tudja, hogy a “>
). A helyzet az, hogy a nem triviális projektek általában ennél többet igényelnek – legalábbis könyvtárakat kell hozzáadnia, és (a projekt lejártával) konfigurálnia kell az összeállítási paramétereket.
Az IDE-k általában legalább ilyen konfigurálhatók – de most a felépítési folyamat az IDE-specifikus opciókra támaszkodik.Ha az Eclipse alkalmazást használja, Alice a NetBeans szolgáltatást részesíti előnyben, Bob pedig a IntelliJ IDEA , akkor nem oszthatja meg a konfigurációt, és amikor egyikőtök módosítást hajt át a forrásvezérlőn, akkor vagy manuálisan kell szerkeszteniük az IDE által létrehozott konfigurációs fájlokat. a többi fejlesztőt, vagy értesítse a többi fejlesztőt, hogy “ők maguk is megcsinálják (ami azt jelenti, hogy lesznek olyan elkövetések, ahol az IDE konfigurációja hibás egyes IDE-k esetében …).
Ezenkívül meg kell kitalálni, hogyan hajtsa végre ezt a változást a csapat által használt minden egyes IDE-ben, és ha egyikük nem támogatja az adott beállítást …
Ez a probléma most kultúrafüggő – a fejlesztői elfogadhatónak találhatják, hogy nincs lehetőségük választani az IDE-ket. De azok a fejlesztők, akik rendelkeznek tapasztalattal az IDE használatával, általában boldogabbak és hatékonyabbak is a használatuk során, és a szövegszerkesztő felhasználók vallási buzgalommal töltik el kedvenceiket ols, tehát ez az egyik hely, ahol szabadságot akar adni a fejlesztőknek – és a rendszerek felépítése lehetővé teszi, hogy ezt tegye. Lehet, hogy egyeseknek van egy build rendszerpreferenciájuk, de ez korántsem olyan fanatikus, mint az IDE / editor szerkesztései. szerver a használatához …
Ez az egyszerű összeállítási folyamat testreszabásához az IDE általában jó GUI-t nyújt. Ha összetettebb dolgokra vágyik – például a forrásfájlok előzetes feldolgozására / automatikus létrehozására a fordítás előtt -, akkor általában egy előre összeállított szkriptet kell írnia az IDE konfigurációjának néhány alapvető szövegterületére. Melyik build rendszereket kell még kódolnia az adott részhez, de megteheti azt a tényleges szerkesztőben, amelybe a kódot írja, és ami még fontosabb: maga a build rendszer keretrendszere általában nyújt némi támogatást ezeknek a parancsfájloknak a rendezéséhez.
Végül – a build rendszerek nem csupán a projekt felépítésére alkalmasak – programozhatja őket más feladatok elvégzésére is, amelyeket a csapatban mindenkinek el kell végeznie. A rubinban Rails például tartalmaznak build rendszerfeladatokat az adatbázis-áttelepítések futtatásához, az ideiglenes fájlok tisztításához stb. Ha ezeket a feladatokat a build rendszerbe helyezi, akkor a csapatból mindenki következetesen meg tudja csinálni őket.
Megjegyzések
- Ez ‘ nemcsak különböző IDE-kről van szó. Egyes fejlesztők utálják és utálják az összes típusú IDE-t.
- @DavidHammen Én ‘ e fejlesztők egyike vagyok (bár én ‘ annyira konfiguráltam a Vim-et ‘ lehetséges, hogy esetleg IDE-vé változtattam …), és a bekezdés írása közben automatikusan írtam ” szerkesztőket ” és javítanom kellett az IDE-n, mert úgy gondolom, hogy az IDE-k rögzítése fontos része a válaszomnak. A kérdező egyértelműen az IDE-k világából származik, és a kérdés az IDE nélküli fejlesztésről beszél, mint olyasmiről, amelyet kénytelen megtenni, amikor nincs megfelelő IDE. Ennek a válasznak az a célja, hogy megmutassa, mennyire előnyösek a build rendszerek még a kizárólag IDE-felhasználókból álló csapatok számára is.
- Én is egyike vagyok ezeknek a fejlesztőknek. Nem szeretném, ha ‘ nem szeretném, ha az ujjaimnak el kellene hagyniuk a billentyűzetet. Ez megszakítja gondolkodási folyamataimat.
- Nem értek egyet. Jobban szeretem az IDE-ket. Lehetővé teszik számomra, hogy ne törődjek a nevekkel, a könnyű kereséssel, a visszafogással, a szép kezelőfelülettel. Úgy értem, ha egy IDE tehet értem valamit, amit egyébként tennék a sed ack-val stb., Akkor ezt használom.
- A lényeg az, hogy build szkriptekkel a csapat minden fejlesztője használhatja, amit csak szeret, míg az IDE ‘ build funkcióval mindenkit arra kényszerít, hogy ne csak egy IDE-t használjon, hanem hogy használja azt a nagyon specifikus IDE-t, amelyhez a projekt konfigurálva van (hacsak nem többre van beállítva) IDE-k, és sok sikert a szinkronizáláshoz …)
Válasz
Sok IDE egyszerűen bepakolja a használt parancsokat valamit létrehozni, majd létrehozni egy szkriptet és hívni!
Például a Visual Studio-ban a C ++ fordítás parancssori paraméterei láthatók a “parancssor” mezőben. Ha alaposan megnézi a build kimenetet, akkor látni fogja az ideiglenes fájlt, amely tartalmazza a fordítás futtatásához használt build szkriptet.
Manapság mindez MSBuild , de ezt továbbra is közvetlenül az IDE futtatja.
Tehát a parancssor használatának oka az, hogy egyenesen a forráshoz megy, és kihagyja a középső embert, egy közvetítő, akit esetleg frissítettek, vagy egy halom olyan függőségre van szüksége, amelyekre éppen nem szüksége vagy szüksége van egy fej nélküli kiszolgálón, amely a folyamatos integrációként működik (CI) szerver.
Ezenkívül a szkriptek többet tesznek, mint a szokásos fejlesztőorientált lépések, amelyekre tervezték őket.Például egy build után megkövetelheti, hogy a bináris fájlokat csomagolja és másolja egy speciális helyre, vagy hozzon létre egy telepítő csomagot, vagy futtassa rajtuk a dokumentációs eszközt. Számos különféle feladatot hajt végre egy CI-kiszolgáló, amelyek értelmetlenek egy fejlesztői gépen, így bár létrehozhat egy IDE-projektet, amely mindezeket a lépéseket elvégezte, akkor kettőt kell fenntartania – egy projektet a fejlesztőknek, egy másikat pedig a buildeknek. Egyes építési feladatok (például statikus elemzés) hosszú időt vehet igénybe, amelyet nem kívánna a fejlesztői projekteknél.
Röviden összefoglalva azonban egyszerűen egyszerűbb – hozzon létre egy szkriptet az összes szükséges dolog elvégzéséhez akar, és ezt gyorsan és egyszerűen elindíthatja a parancssorban vagy a build szerver konfigurációjában.
Válasz
make sokkal könnyebben megjegyezhető és beírható, mint
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 És a projektek nagyon összetett fordítási parancsokkal rendelkezhetnek. A build szkript arra is képes, hogy csak a megváltozott dolgokat fordítsa újra. Ha tiszta összeállítást szeretne készíteni,
make clean a megfelelő beállítás után könnyebb és megbízhatóbb, mint megpróbálni megjegyezni azokat a helyeket, amelyek egy köztes fájlban lehetnek
Természetesen, ha IDE-t használ, akkor a build vagy a clean gombra is kattintania kell. Sokkal nehezebb automatizálni a kurzor mozgatását a képernyőn egy adott helyre, különösen akkor, ha ez a hely elmozdulhat, ha az ablak mozog, mint egy egyszerű szöveges parancs automatizálása.
Válasz
Hogyan csinálnád másképp? Az egyetlen másik lehetőség egy hosszú parancssori parancs megadása.
A másik ok az, hogy A makefile-k lehetővé teszik az inkrementális fordítást, ami nagyban meggyorsítja a fordítási időt.
A Makefiles emellett platformok közötti cross-platformot is készíthet. A CMake a platform alapján különböző build-szkripteket generál.
Szerkesztés:
Az IDE használatával egy adott cselekvési módhoz kötődik. Sokan használják a vim vagy az emacs programokat, annak ellenére, hogy nincs sok IDE-szerű funkciójuk. Megteszik, mert ezt akarják a szerkesztők biztosítják. A build szkriptek szükségesek azok számára, akik nem használnak IDE-t.
Még azoknak is, akik IDE-t használnak, érdemes tudni, hogy mi folyik itt, ezért a build szkript a legalsó részleteket kínálja a megvalósításról, amelyet a GUI megközelítésnek nincs.
Az IDE-k maguk is gyakran építenek szkripteket belsőleg; a run gomb csak egy újabb módja a make parancs futtatásának.
Válasz
A fenti válaszok sok jó terepet fednek le, de az egyik valós példa, amelyet nem szeretnék hozzáadni (amit nem tudok kommentként hozzáadni karma hiánya miatt), az Android programozásból származik.
Profi Android / iOS / Windows Telefonos fejlesztő, és én a Google szolgáltatások API-kat (többnyire a Google Maps) használom egy tétel .
Android-ban , ezekhez a szolgáltatásokhoz meg kell adnom egy kulcstárat , vagy egy olyan fejlesztői azonosító fájl, amely a Google-nak azt mondja, hogy én vagyok az, akinek mondom magam, egy fejlesztői konzolhoz. Ha az alkalmazásomat más kulcstárral fordítják össze, az alkalmazás Google Maps szakasza nem fog működni.
Ahelyett, hogy tucatnyi kulcstárat adnék hozzá és kezelnék a fejlesztői konzolhoz, amiből amúgy is csak az egyik használható az alkalmazás frissítésére, ezt a kulcstárat felveszem a biztonságos repóba és a Gradle segítségével mondd meg az Android Studio-nak, hogy pontosan milyen kulcstárat kell használni a “debug” vagy a “release” felépítésekor. Most csak két kulcstárat kell hozzáadnom a Google fejlesztői konzolomhoz, egyet a “hibakereséshez” és egyet a “kiadáshoz”, és az összes csapattagom klónozhatja a repót, és jobbá teheti a fejlesztést anélkül, hogy be kellene mennem a fejlesztőhöz konzolt, és adja hozzá az adott kulcstáruk SHA-kivonatát, vagy ami még rosszabb, késztetve arra, hogy kezeljem őket . Ennek további előnye, hogy minden csapattagnak megkapja az aláíró kulcstár egy példányát, ami azt jelenti, hogy ha kívül vagyok az irodában, és ütemezett frissítést tervezek, akkor a csapattagnak csak nagyon rövid utasításlistát kell követnie ahhoz, hogy egy frissítés.
Az ilyen összeállítású automatizálás következetes építkezést biztosít és csökkenti a technikai adósságot azáltal, hogy csökkenti a beállítási időt, amikor új fejlesztőt, új gépet kapunk, vagy amikor újra kell készítenünk egy gép.
Válasz
A szkript létrehozásának előnyei:
-
a változtatások kódként néznek ki ( például egy git diff parancsban), nem tetszik a párbeszédpanel különböző bejelölt opcióinak
-
több kimenet létrehozása, mint egy egyszerű felépítés
Néhány korábbi projektemben a build szkripteket használtam:
- a projekt dokumentációjának létrehozásához (doxigen alapú)
- build
- egység tesztek futtatása
- egység teszt lefedettségi jelentések generálása
- bináris fájlok csomagolása kiadási archívumba
- belső kiadási megjegyzések létrehozása (“git log” üzenetek alapján )
- automatizált tesztelés
Válasz
Gyakran felhívhatja a “build” gombot automatizált módon (a Visual Studio például elfogadja a parancssori argumentumokat). Az emberek építési szkripteket írnak, amint szükségük van valamire, amit a build gomb nem tud biztosítani.
Például a legtöbb IDE csak építkezni enged. egy-egy platform. Vagy csak egy nyelv egyszerre. Aztán itt van, amit a beépített kimenetekkel csinálsz: az IDE mindegyiket telepítési csomagba tudja tekerni?
important to understand as a developer, bár biztosan nem mindig. Még olyan környezetekben is, ahol a build szkriptek gyakorlati követelmények, sok ” fejlesztő ” nyert ‘ t a legkevésbé is törődik velük. De a szkriptek akkor fontosak a ‘ építők számára ‘, mint a fejlesztők számára. Az utolsó helyeken, ahol dolgoztam, a legtöbb fejlesztőnek gyakorlatilag nulla volt a kapcsolata a szkriptek készítéséhez.