GitLab CI:n Fab 5

Hei! Olen työskennellyt GitLabin (tällä hetkellä 11.6.10-ee) kanssa enterprise-ympäristössä noin 6 kuukautta. Tässä muutama vinkki ennen GitLab CI:n käytön aloittamista.

1. Valitse sen sijaan Jenkins

GitLab on saanut viime aikoina paljon huomiota, ja halusin todella käyttää sitä. Nyt kuitenkin kadun sitä ja toivon, että olisin valinnut sen sijaan Jenkinsin.

CI-moottorista puuttuu (tai puuttui) monia ominaisuuksia, joita pidin jo itsestäänselvinä, kuten: include-toiminto (otettu käyttöön versiossa 11.4), pipelinen ajoaikaiset parametrit (versiossa 10.8) sekä saman haaran samanaikaisten pipelinejen rajoittaminen yhteen (edelleen keskustelun alla).

GitLabin eduksi on sanottava, että se on todella vakaa ja siinä on joitakin hyviä ominaisuuksia. Esimerkiksi docker:dind-palvelu (docker Dockerin sisällä) on todella vakaa ja helppo käyttää pipelineissa. GitLab CI:n dokumentaatio kertoo myös selkeästi, mitä sillä voi ja ei voi tehdä. Kunpa olisin lukenut osan siitä dokumentaatiosta ennen kuin jatkoin.

2. Hanki todella lyhyt hiustyyli

YAMLin ja GitLab-tulkin yhdistelmä on äärimmäisen turhauttava. Saatat ajatella pärjääväsi hyvin, jos ymmärrät täydellisesti YAMLin tavalliset monirivioperaattorit |, ,|-, >, >-.

Valitettavasti näin ei ole.

Syntaksi on GitLabin oma YAML-murre, joka saa sinut joskus repimään hiuksiasi.

Siksi toivon, että olisin panostanut todella lyhyeen hiustyyliin ennen GitLab CI:n käytön aloittamista.

Älkää kokeilko tätä kotona, lapset

• Yksi echo-komento, joka tulostaa usealle riville

• Bashin for-silmukka usealla rivillä ilman puolipisteiden viljelyä

• Aseta Bashissa +/- u/e YAML-templatessa (.hidden_job: &gonnaignoremodes)

3. Unohda pääsynhallinta

Jos käytät GitLab CI:tä, olet selvästi yksi tämän alan onnekkaista yksisarvisista.

Pääsynhallinta on dinosauruksille.

Jos koskaan ajattelet pääsynhallintaa, lopeta pääsynhallinnan ajatteleminen ja ajattele sen sijaan mahtavia asioita.

Kun dinosaurus sitten pyytää sinua myöntämään enterprise-tason Site Reliability Engineering (tai ops) -tiimille roolipohjaisen pääsyn sovellusten käyttöönottoon staging- tai tuotantoympäristössä, tee heistä globaaleja ylläpitäjiä. He ovat siihen tyytyväisiä.

GitLabissa muuttujilla on tasan kaksi tilaa. Ne ovat joko suojattuja ja käytettävissä suojatuissa haaroissa, tai sitten niitä ei ole suojattu lainkaan. Tämä on helppo ratkaista nostamalla kaikki ops-ihmiset ylläpitäjärooleihin ja pitämällä kehittäjäyksisarviset kurissa developer-tason käyttöoikeuksilla. Miksi kehittäjä koskaan tarvitsisi pääsyn master-haaraan?

4. Vältä yhteisiä käyttöönottoprosesseja

GitLab CI mahdollistaa tällä hetkellä etä-YAML-tiedoston sisällyttämisen pipeline-määritelmäksi. Voit kuitenkin sisällyttää vain yhden tiedoston, jossa ei ole sisäkkäisiä include-toimintoja (ennen versiota 11.7).

Etätiedoston include-toiminto ei tue todentamista. Voit määrittää YAML-templateja (.) ja ankkureita (&). Voit kuitenkin viitata templateihin ja ankkureihin vain samassa tiedostossa. Toisin sanoen et voi sisällyttää templateja tai ankkureita. Sen sijaan sinun on ratkaistava ne etätiedostossa ennen sen sisällyttämistä. Ilman, että include-toiminnolle välitetään parametreja.

Lopputuloksena et voi esimerkiksi määrittää kahta vaihtoehtoista build-työtä, joista loppukäyttäjä voisi valita, vaan vain yhden.

Lisäksi GitLab CI toimii vaiheissa. Pipelinen on määritettävä vaiheet (build, test, deploy) sekä niissä ajettavat työt. Jos määrität vaiheen ilman työtä, pipeline kaatuu. Jos määrität työn, joka ei kuulu mihinkään vaiheeseen, pipeline kaatuu.

Näin voi käydä esimerkiksi silloin, kun pipeline-templaatti määrittelee koodianalyysityön, mutta loppukäyttäjät eivät sisällytä vaihetta, koska heidän editorinsa hoitaa saman työn jo paremmin.

Dinosaurus voisi toki väittää, että he ansaitsevat palaa helvetissä vääräoppisina harhaoppisina. Epäilen kuitenkin, ettemme kaikki ole siitä samaa mieltä.

Unohda jaetut pipelinet ja työt

Jos et usko yhteen, kaikille sopivaan kokoon, unohda jaetut pipelinet ja työt. Toisaalta olemme mikropalveluyksisarvisia, eikä lumihiutalesovellustemme pipelineissa ole yhteisiä vaiheita, joten ketä kiinnostaa.

(Psst. Jaetut julkaisuprosessit ovat dinosauruksille.)

Kiertotapaus (jos olet dinosaurus ja vaadit jakamista)

Kirjoita koodia, joka luo eri YAML-tiedoston jokaiselle keskeisten työtemplaatien mahdolliselle yhdistelmälle, ja lataa ne artifact-tallennustilaan. Loppukäyttäjät voivat sitten sisällyttää sieltä suosikkipipelinensa.

Tai käytä sediä. Sed on aina mahtava.

Ei sillä, että sed eroaisi koodista. Sed on koodia. Sed on kaikkea.

5. Katso Inception

Sen lisäksi, että Inception on hyvä elokuva, se antaa sinulle olennaisen ajattelutavan muiden työkalujen käärimiseen GitLab-pipelinesi alle.

Esimerkiksi includejen puutteilla ei ole väliä, jos kutsut vain Ansiblea, joka puolestaan sisällyttää kaikki suosikkirolesi organisaatiosi yksityisestä galaksista.

Vaihtoehtoisesti sinulla voi olla kokoelma Perl- tai Bash-skriptejä, jotka kloonaat artifact-tallennustilasta. Siis jos olet dinosaurus etkä luota yksisarvistyökaluihin, kuten Ansibleen, Octopukseen, Chefiin, Puppetiin tai mihinkään, mikä on tehty Golangilla tai Rubylla.