Mitkä ovat rakennusskriptien edut?

Automaatio.

Kun kehität, vain yksinkertaisimmissa projekteissa oletus ”build” -painike tekee kaiken mitä tarvitset; sinun on ehkä luotava WS API: sta, luotava dokumentit, linkitettävä ulkoisiin resursseihin, otettava muutokset käyttöön palvelimelle jne. Jotkut IDE: t sallivat sinun mukauttaa rakennusprosessia lisäämällä ylimääräisiä vaiheita tai rakentajia, mutta se tarkoittaa vain, että olet build-komentosarjan luominen IDE-hyödykkeillä.

Mutta järjestelmän kehittäminen ei ole vain koodin kirjoittamista. Asiaan liittyy useita vaiheita. IDE-ohjelmasta riippumaton komentosarja voidaan suorittaa automaattisesti, mikä tarkoittaa, että:

• Kun teet muutoksen versionhallintaan, palvelin voi käynnistää uuden koontiversio. Se varmistaa, ettet ole unohtanut tehdä mitään tarvittavaa koontiversiota varten.

• Vastaavasti koontitoiminnon jälkeen testit voidaan suorittaa automaattisesti sen varalta, että rikkoitko jotain.

• Nyt muulla organisaatiolla (QA, sysadmins) on rakennettu tuote, joka

  a) on täysin toistettavissa vain ohjausversiosta.

  b) on yhteinen kaikille heille.

Vaikka olisin työskennellyt yhden miehen tiiminä, olen käyttänyt komentosarjoja tähän tarkoitukseen; Kun olin kehittänyt korjauksen, sitoutun SVN: ään, viennin SVN: n takaisin toiseen hakemistoon ja luomaan ratkaisun build-komentosarjan avulla, joka siirtyisi sitten Ennakkojärjestelmiin ja myöhemmin Tuotantoon. Jos joku muutama viikko myöhemmin (kun paikallinen kooditietokantani on jo muuttunut) valitti virheestä, tiesin tarkalleen, minkä SVN-version minun on maksettava voidakseni virheenkorjata järjestelmän oikein.

Kommentit

• Tämä on paras vastaus IMHO. Jokainen on oikeassa ajatuksessaan, mutta tämä osoittaa todella, miksi haluat luoda komentosarjoja. Koska ne tukevat automaatiota, joka jatkuu projektisi laajentuessa, säästät aikaa.
• @Alexus Ei vain aikaa, vaan myös mykkäjä virheitä. 😉 ” Toisto johtaa ikävystymiseen. Ikävystyminen johtaa kauhistuttaviin virheisiin. Kauhistuttavat virheet johtavat ’ toivoakseni, että olisin vielä tylsistynyt.’ ” (Voit mitata mykkävirheitä myös ajoissa, mutta se ’ s on tärkeää ymmärtää, että se ’ säästää aikaa useista syistä.)
• Jopa yhden miehen projektiin paikallisen Jenkins-palvelimen käyttäminen ” erilliseen hakemistoon rakentaminen ” voi auttaa. Olen ’ työskennellyt Windows-käyttöjärjestelmässä, joka minun on vahvistettava myös ristikäännöksillä, joten Jenkinsin rakentaminen ja suorittaminen sekä sitten ristikäännetyn version rakentaminen saa minut paljon varmemmaksi ( tietysti tehokkaita!), kun minun on julkaistava virhekorjauksia.
• En ole ’ samaa mieltä uusittavien koontiversioiden kanssa. Nykypäivän järjestelmissä on niin paljon hallitsemattomia muuttujia, että sen toistaminen on melko vaikeaa. Väitteesi kuulostaa siltä, että saat tuon paketin, mikä ei ole totta.
• @JonasGr ö ger Automation poistaa yhden suurimmat muuttujat: ihmiset.

Kuten koodi, myös tietokone suorittaa koontikoodin. Tietokoneet ovat poikkeuksellisen hyviä noudattamaan ohjeita. Itse asiassa (itse muuttuvan koodin ulkopuolella) tietokoneet suorittavat saman komentosarjan täsmälleen samalla tavalla samalla syötteellä. Tämä tarjoaa yhdenmukaisuuden tason, jota vain tietokone pystyy vastaamaan.

Sitä vastoin meitä vedellä täytetyt lihapussit ovat vain halveksittavia seuraavien vaiheiden suhteen. Tällä ärsyttävällä analyyttisellä aivolla on taipumus kyseenalaistaa kaikki mitä se törmää. ”Voi … minun ei tarvitse sitä” tai ”Käytänkö todella tätä lippua? Eh … minä vain jätän sen huomiotta. Lisäksi meillä on taipumus itsetyytyväisyyteen. Kun olemme tehneet jotain muutaman kerran, alamme uskoa, että tiedämme ohjeet, ja meidän ei tarvitse katsoa ohjesivua.

Lähettäjä ”Pragmaattinen ohjelmoija”:

Lisäksi haluamme varmistaa johdonmukaisuuden ja toistettavuuden projektissa. Manuaaliset menettelytavat antavat johdonmukaisuuden muuttua; toistettavuutta ei taata, varsinkin jos menettelyn näkökohtia voivat tulkita eri ihmiset.

Lisäksi olemme hitaasti hitaita suorittamaan ohjeita ( verrattuna tietokoneeseen). Suuressa projektissa, jossa on satoja tiedostoja ja kokoonpanoja, rakennusprosessin kaikkien vaiheiden suorittaminen manuaalisesti kestää vuosia.

Annan sinulle tosielämän esimerkin. Työskentelin joitain sulautettuja ohjelmistoja, joissa suurin osa koodista jaettiin muutamalle eri laitteistoalustalle. Jokaisella alustalla oli erilainen laitteisto, mutta suurin osa ohjelmisto oli sama. Mutta oli pieniä kappaleita, jotka olivat ominaisia jokaiselle laitteistolle. Ihannetapauksessa yhteiset kappaleet sijoitettaisiin kirjastoon ja linkitettäisiin jokaiseen versioon. Yleisiä kappaleita ei kuitenkaan voitu kääntää jaettuun kirjastoon. Se oli koottava jokaisella eri kokoonpanolla.

Aluksi kootin kukin kokoonpano manuaalisesti. Vaihtaminen kesti vain muutaman sekunnin kokoonpanoissa, eikä ollut niin suuri tuska. Projektin loppupuolella löydettiin kriittinen virhe koodin jaetusta osasta, jossa laite ottaisi olennaisesti tiedonsiirtoväylän haltuunsa. Tämä oli huono! Todella paha. Löysin virheen koodista, korjasin sen ja käänsin kaikki versiot uudelleen. Paitsi yksi. Rakennusprosessin aikana olen hajamielinen ja unohdin yhden. Binaarit vapautettiin, kone rakennettiin, ja päivää myöhemmin saan puhelun, jossa kerrottiin, että kone lakkasi vastaamasta. Tarkistin sen ja huomasin, että laite oli lukinnut väylän. ”Mutta korjasin virheen!”.

Olen ehkä korjannut sen, mutta se ei koskaan löytänyt tiensä yhdelle levylle. Miksi? Koska minulla ei ollut automaattista rakennusprosessia, joka rakensi jokaisen version yhdellä napsautuksella.

Kommentit

• Ja voit mennä kahviin, kun koontikomentosarja on käynnissä!

Jos kaikki mitä haluat tehdä, on <compiler> **/*.<extension>, koontikomentosarjoilla ei ole juurikaan tarkoitusta (tosin voidaan väittää, että jos projektissa näkyy Makefile, tiedät, että voit rakentaa sen iv id =” 4b5e4adc72: lla Asia on – ei-triviaalit projektit vaativat yleensä enemmän kuin mitä – ainakin sinun on yleensä lisättävä kirjastoja ja (projektin kypsyessä) määritettävä rakenneparametrit.

IDE: t ovat yleensä ainakin määritettävissä – mutta nyt rakennusprosessi perustuu IDE-kohtaisiin vaihtoehtoihin.Jos käytät Eclipse -ohjelmaa , Alice pitää parempana NetBeansia ja Bob haluaa käyttää IntelliJ IDEA , et voi jakaa kokoonpanoa, ja kun joku teistä työntää muutoksen lähdeohjaimeen, heidän on joko muokattava IDE: n luomia määritystiedostoja muille kehittäjille tai ilmoita muille kehittäjille, jotta he ”tekevät sen itse (mikä tarkoittaa, että tapahtuu sitoumuksia, joissa IDE-määritykset ovat väärät joillekin IDE: ille …).

Sinun on myös selvittää, miten tämä muutos tehdään jokaisessa tiimin käyttämässä IDE: ssä, ja jos joku heistä ei tue kyseistä asetusta …

Tämä ongelma on nyt kulttuuririippuvainen – kehittäjät saattavat pitää hyväksyttävänä, että heillä ei ole valintaa IDE: stä. Mutta kehittäjät, joilla on kokemusta IDE: stä, ovat yleensä sekä onnellisempia että tehokkaampia käyttäessään sitä, ja tekstieditorin käyttäjillä on taipumus kiihkeästi kiihkeästi suosikkiinsa ols, joten tämä on yksi niistä paikoista, joissa haluat antaa vapauden kehittäjille – ja rakentaa järjestelmiä voit tehdä juuri sen. Joillakin ihmisillä voi olla rakennusjärjestelmän mieltymys, mutta se ei ole läheskään yhtä fanaattinen kuin IDE / editori-asetukset …

Vaikka saisit kaikki kehittäjät käyttämään samaa IDE: tä – onnea rakennuksen vakuuttamiseksi palvelin käyttää sitä …

Nyt nämä ovat yksinkertaisten rakennusprosessien mukautusten kannalta, että IDE: t tarjoavat yleensä mukavan käyttöliittymän. Jos haluat monimutkaisempia asioita – kuten esikäsittely / lähdetiedostojen automaattinen luominen ennen kääntämistä – sinun on yleensä kirjoitettava ennalta koontikomentosarja jollekin perustekstialueelle IDE-kokoonpanon sisällä. Mitkä koontijärjestelmät joudut vielä koodaamaan kyseisen osan, mutta voit tehdä sen todellisessa editorissa, johon kirjoitat koodin, ja mikä tärkeintä: koontijärjestelmän kehys itsessään tarjoaa yleensä jonkin verran tukea näiden komentosarjojen järjestämiselle.

Lopuksi – koontijärjestelmät ovat hyviä muuhun kuin vain projektin rakentamiseen – voit ohjelmoida ne suorittamaan muita tehtäviä, jotka kaikki tiimin jäsenet saattavat tarvita. Ruby on Kiskot , esimerkiksi, on rakenteellisia järjestelmätehtäviä tietokantojen siirron suorittamiseen, väliaikaisten tiedostojen puhdistamiseen jne. Näiden tehtävien sijoittaminen rakennusjärjestelmään varmistaa, että kaikki tiimissä toimivat voivat tehdä ne johdonmukaisesti.

Kommentit

• Se ’ ei koske vain erilaisia IDE: itä. Jotkut kehittäjät vihaavat ja inhoavat kaikenlaisia IDE: itä.
• @DavidHammen Olen ’ m yksi näistä kehittäjistä (vaikka olen ’ määrittänyt Vimini niin kovaksi, että ’ on mahdollista, että olen ehkä muuttanut sen IDE: ksi …), ja kirjoittaessani sitä kappaletta kirjoitin automaattisesti ” toimittajia ” ja piti korjata se IDE: hen, koska mielestäni IDE-laitteiden kiinnitys on tärkeä osa vastaustani. Kysyjä tulee selvästi IDE-maailmasta, ja kysymyksessä puhutaan IDE-ilman kehityksestä sellaisena, joka sinun on pakko tehdä, kun oikeaa IDE: tä ei ole käytettävissä. Tämän vastauksen tarkoituksena on osoittaa, kuinka koontijärjestelmät ovat hyödyllisiä myös pelkästään IDE-käyttäjistä koostuville ryhmille.
• Minäkin olen yksi niistä kehittäjistä. En halua ’ halua, että sormeni täytyy jättää näppäimistö. Se keskeyttää ajatusprosessini.
• En ole samaa mieltä. Pidän mieluummin IDE: stä. He antavat minun olla välittämättä nimistä, helpoista hakutoiminnoista, uudelleenkäsittelystä, mukavasta käyttöliittymästä. Tarkoitan, että jos IDE voi tehdä minulle jotain, mitä tekisin muuten sed ack: lla jne., Käytän sitä.
• Asia on, että koontikomentosarjojen avulla jokainen tiimin kehittäjä voi käyttää mitä haluaa, IDE ’ -kokoonpanotoiminnolla pakotat kaikki paitsi käyttämään IDE: tä myös käyttämään tarkkaa IDE: tä, jolle projekti on määritetty (ellet ole määrittänyt sitä useille IDE: t ja onnea synkronoinnissa …)

Monet IDE: t yksinkertaisesti paketoivat käytetyt komennot rakentaa jotain ja luoda sitten komentosarja ja kutsua sitä!

Esimerkiksi Visual Studiossa näet komentoriviparametrit C ++ -käännöksen komentoriviparametrit. Jos tarkastelet tarkasti koontilähtöä, näet väliaikaisen tiedoston, joka sisältää koontikoodin, jota käytettiin käännöksen suorittamiseen.

Nykyään se on kaikki MSBuild , mutta IDE hoitaa sitä edelleen suoraan.

Siksi komentoriviä käytetään siksi, että olet menossa suoraan lähteeseen ja ohitat keskimmäisen miehen, välittäjä, joka on saatettu päivittää tai tarvita kasa riippuvuuksia, joita et vain halua tai tarvitset päättömässä palvelimessa, joka toimii jatkuvana integrointina (CI) palvelin.

Lisäksi skriptisi tekevät enemmän kuin tavalliset kehittäjälähtöiset vaiheet, joille ne on suunniteltu.Esimerkiksi koontiversion jälkeen saatat haluta pakata ja kopioida binääritiedostot erityiseen sijaintiin tai luoda asennuspaketin tai dokumentaatiotyökalun. CI-palvelin suorittaa monia erilaisia tehtäviä, jotka ovat turhia kehittäjäkoneessa, joten vaikka voit luoda IDE-projektin, joka suoritti kaikki nämä vaiheet, sinun on ylläpidettävä kahta niistä – projekti kehittäjille ja toinen rakennuksille. Jotkut rakennustehtävät (esimerkiksi staattinen analyysi) voivat viedä kauan, mitä et halua kehittäjäprojekteille.

Lyhyesti sanottuna se on kuitenkin helpompaa – luo komentosarja tekemään kaikki haluamasi asiat want ja se on nopea ja helppo aloittaa komentoriviltä tai koontipalvelimen kokoonpanosta.

make 

on paljon helpompi muistaa ja kirjoittaa kuin

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 

Ja projekteissa voi olla hyvin monimutkaisia kääntökomentoja. Koontikomentosarjalla on myös kyky kääntää vain muuttuneet asiat uudelleen. Jos haluat tehdä siistin rakennelman,

make clean 

on helpompaa ja luotettavampaa, kun se on määritetty oikein, kuin yrittää muistaa jokainen välitiedostossa mahdollisesti oleva paikka

Jos käytät IDE: tä, tietysti myös rakennus- tai puhdistuspainikkeen napsauttaminen on helppoa. On kuitenkin paljon vaikeampaa automatisoida kohdistimen siirtäminen tiettyyn paikkaan näytöllä, varsinkin kun kyseinen paikka voi liikkua, jos ikkuna liikkuu, kuin yksinkertaisen tekstikomennon automatisointi.

Kuinka muuten tekisit sen? Ainoa toinen tapa on määrittää yksi pitkä komentorivikomento.

Toinen syy on, että makefile-tiedostot sallivat inkrementaalisen kääntämisen, mikä nopeuttaa kääntämisaikaa paljon.

Makefiles voi myös tehdä rakennusprosessista monialustaisen. CMake luo alustan perusteella erilaisia koontikomentosarjoja.

Muokkaa:

IDE: n avulla olet sidottu tiettyyn toimintatapaan. Monet ihmiset käyttävät vim- tai emacs-tiedostoja, vaikka heillä ei olisikaan monia IDE-tyyppisiä ominaisuuksia. He tekevät sen, koska haluavat näiden voimaa toimittajat tarjoavat. Koontikomentosarjat ovat välttämättömiä niille, jotka eivät käytä IDE: tä.

Jopa IDE: tä käyttäville kannattaa ehkä tietää, mitä on tekeillä, joten koontikomentosarja tarjoaa sinulle alhaalla olevat yksityiskohdat toteutuksesta, jota GUI-lähestymistavalla ei ole.

IDE: t itse käyttävät usein komentosarjoja myös sisäisesti; juoksupainike on vain yksi tapa suorittaa komento make.

Yllä olevat vastaukset kattavat paljon hyvää maata, mutta yksi tosielämän esimerkki, jonka haluaisin lisätä (jota en voi lisätä kommenttina, koska ei ole karmaa), on peräisin Android-ohjelmoinnista.

Olen ammattimainen Android / iOS / Windows Puhelinkehittäjä, ja käytän Google-palvelujen sovellusliittymiä (enimmäkseen Google Mapsia) lot .

Androidissa , nämä palvelut edellyttävät, että lisätään avainvarasto , tai kehittäjätunnustiedostotyyppi, joka kertoo Googlelle, että olen se, jonka sanon olevani, kehittäjäkonsoliin. Jos sovellukseni on käännetty toisella avainvarastolla, sovelluksen Google Maps -osio ei toimi.

Sen sijaan, että kehittäjäkonsoliin lisätään ja hallitaan kymmenkunta avainvarastoa, joista vain yhtä voidaan tosiasiallisesti käyttää sovelluksen päivittämiseen, sisällytän tämän avainkeskuksen turvalliseen repoomme ja kerro Gradlen avulla Android Studiolle tarkalleen, mitä avainvarastoa tulee käyttää rakennettaessa ”virheenkorjausta” tai ”julkaisua” varten. Minun on lisättävä vain kaksi avainkeskusta Google-kehittäjäkonsoliin, yksi ”virheenkorjausta” ja toinen ”julkaisua” varten, ja kaikki tiimini jäsenet voivat kloonata repon ja saada oikeuden kehitykseen tarvitsematta mennä kehittäjälle. konsoli ja lisää heidän tietyn avainsäilönsä SHA-hash, tai mikä vielä pahempaa, saa minut hallitsemaan niitä . Tästä on lisäetuna, että jokaiselle tiimin jäsenelle annetaan kopio allekirjoituksen avainvarastosta, mikä tarkoittaa, että jos olen poissa toimistosta ja päivitys on ajoitettu, tiimin jäsenen on noudatettava vain hyvin lyhyttä luetteloa ohjeista työntääkseen päivitys.

Tämänkaltainen rakennusautomaatio pitää rakenteen yhtenäisenä ja vähentää teknistä velkaa vähentämällä asennusaikaa, kun saamme uuden kehittäjän, uuden koneen tai kun meidän on kuvattava uudelleen kone.

Komentosarjan muodostamisen edut:

• muutokset näyttävät koodilta ( git diff -komennossa), älä pidä valintaikkunan eri tarkistetuista vaihtoehdoista.

• Luo enemmän ulostuloa kuin yksinkertainen koontiversio

Joissakin aiemmissa projekteissani olen käyttänyt koontikomentosarjoja:

• projektidokumentaation luominen (doxygen-pohjainen)
• rakennus
• suorittaa yksikötestit
• luoda yksikötestien kattavuusraportit
• pakata binäärit julkaisuarkistoon
• luoda sisäiset julkaisutiedot (git log -viestien perusteella) )
• automaattinen testaus

Voit usein soittaa ”koota” -painikkeelle automatisoidulla tavalla (Visual Studio hyväksyy esimerkiksi komentoriviargumentit). Ihmiset kirjoittavat koontikomentosarjoja heti, kun tarvitsevat jotain, jota koontipainike ei pysty tarjoamaan.

Esimerkiksi useimmat IDE: t antavat sinun rakentaa vain yksi alusta kerrallaan. Tai vain yksi kieli kerrallaan. Sitten teet sisäisillä lähdöillä: voiko IDE kääriä ne kaikki asennuspakettiin?