The Fab 5 för GitLab CI

Hej! Jag har arbetat med GitLab (just nu 11.6.10-ee) i en enterprise-miljö i ungefär sex månader. Här är några tips innan du börjar med GitLab CI.

1. Välj Jenkins i stället

GitLab har fått mycket uppmärksamhet på sistone och jag ville verkligen använda det. Men nu ångrar jag mig och önskar att jag hade valt Jenkins i stället.

CI-motorn saknar (eller brukade sakna) många funktioner som jag redan tog för givna, till exempel includes (introducerades i 11.4), parametrar för pipelinekörning (i 10.8) och möjligheten att begränsa samtidiga pipelines för samma branch till 1 (diskuteras fortfarande).

Till GitLabs fördel måste jag säga att det är mycket robust och har flera bra funktioner. Till exempel är tjänsten docker:dind (docker i docker) mycket robust och enkel att använda i pipelines. GitLab CI dokumenterar också tydligt vad det kan och inte kan göra. Jag önskar bara att jag hade läst en del av den dokumentationen innan jag fortsatte.

2. Klipp håret riktigt kort

Kombinationen av YAML och en GitLab-tolk är extremt frustrerande. Du kanske tror att du klarar dig bra om du förstår standardoperatorerna för YAML med flera rader, |, ,|-, >, >-, perfekt.

Tyvärr är det inte så.

Syntaxen är en GitLab-specifik variant av YAML, som ibland får dig att slita ditt hår.

Därför önskar jag att jag hade satsat på en riktigt kort frisyr innan jag började med GitLab CI.

Prova inte det här hemma, barn

• Ett enda echo-kommando som skriver ut på flera rader

• Bash for-loop på flera rader utan att spamma semikolon

• Ange +/- u/e i Bash YAML-mall (.hidden_job: &gonnaignoremodes)

3. Glöm åtkomstkontroll

Om du använder GitLab CI är du uppenbarligen en lycklig enhörning i den här branschen.

Åtkomstkontroll är för dinosaurier.

Om du någon gång tänker på åtkomstkontroll, sluta tänka på åtkomstkontroll och tänk fantastiskt i stället.

Dessutom, när en dinosaurie ber dig ge enterprise-teamet för site reliability engineering (eller ops) rollbaserad åtkomst för att driftsätta appar till staging eller produktion, gör dem till globala administratörer. Det blir de nöjda med.

I GitLab har variabler exakt två lägen. Antingen är de skyddade och tillgängliga i skyddade branches, eller så är de inte skyddade alls. Det här är enkelt att lösa genom att ge alla inom ops administratörsroller och hålla utvecklarenhörningarna på avstånd med åtkomst på utvecklarnivå. Jag menar, varför skulle en utvecklare någonsin behöva åtkomst till master-branchen?

4. Undvik delade driftsättningsprocesser

GitLab CI låter dig för närvarande inkludera en YAML-fil på annan plats som definition för din pipeline. Du kan dock bara inkludera en fil som inte har nästlade includes (före version 11.7).

En inkludering av en fjärrfil har inte stöd för autentisering. Du kan definiera YAML-mallar (.) och ankare (&). Du kan dock bara referera till mallar och ankare i samma fil. Med andra ord kan du inte inkludera mallar eller ankare. I stället måste du lösa upp dem i fjärrfilen innan du inkluderar den. Utan att skicka några parametrar till inkluderingen.

Resultatet är att du till exempel inte kan definiera två alternativa build-jobb som slutanvändaren kan välja mellan, utan bara ett.

Utöver det arbetar GitLab CI i steg. En pipeline måste definiera steg (build, test, deploy) och jobb som körs i dessa steg. Om du definierar ett steg utan ett jobb kraschar pipelinen. Om du definierar ett jobb som inte finns i något steg kraschar pipelinen.

Detta kan till exempel hända om pipeline-mallen definierar ett jobb för kodanalys, men slutanvändarna inte inkluderar steget eftersom deras editor redan gör samma jobb bättre.

En dinosaurie skulle förstås kunna hävda att de då förtjänar att brinna i helvetet som villoläriga kättare. Jag misstänker dock att vi inte alla håller med om det.

Glöm delade pipelines eller jobb

Om du inte tror på en enda exakt storlek som passar alla, så glöm delade pipelines eller jobb. Å andra sidan är vi ju mikrotjänste-enhörningar och våra snöflingeapplikationer har inga gemensamma steg i sina pipelines, så vem bryr sig.

(Psst. Delade releaseprocesser är för dinosaurier.)

Lösning (om du är en dinosaurie och insisterar på att dela)

Skriv kod som genererar en annan YAML-fil för varje möjlig kombination av centrala jobbmallar och laddar upp dem till en artifact storage. Slutanvändarna kan sedan inkludera sin favorit-pipeline därifrån.

Eller använd sed. Sed är alltid fantastiskt.

Det är inte som att sed skulle skilja sig från kod. Sed är kod. Sed är allt.

5. Se Inception

Förutom att vara en bra film ger Inception dig rätt tankesätt för att kapsla in andra verktyg i din GitLab-pipeline.

Det spelar till exempel ingen roll hur bristfälliga inkluderingarna är om du bara anropar Ansible, som i sin tur inkluderar alla dina favoritroller från organisationens privata galaxy.

Alternativt kan du ha en samling Perl- eller Bash-skript som du klonar från artifact storage. Om du nu är en dinosaurie och inte litar på enhörningsverktyg som Ansible, Octopus, Chef, Puppet eller något som är gjort med Golang eller Ruby.