Från Jenkins till GitLab CI: Hur kommer du igång?

Enligt Wikipedia: 

När du förstår vad en pipeline är ser du hur valet av CI/CD-verktyg påverkar arbetsflödets effektivitet och tillförlitlighet. Eftersom GitLab CI är ditt nya förstahandsval av verktyg markerar detta ett nytt kapitel i mjukvarans livscykel och förändrar även teamets arbetssätt.

Innan du försöker göra en 1:1-migrering (vilket sannolikt inte kommer att vara möjligt) rekommenderar jag att du stannar upp och diskuterar med teamet om ni är nöjda med hur pipelinen har fungerat hittills. Du kan använda olika verktyg för att underlätta samtalet, till exempel vårt pipeline-spel!

Kom igång med migreringen

Nu när du har definierat och lagt upp dina planer – vad är pipelineens mål, och hur skapar den värde för dig och utvecklingsteamet som använder den? (Det bästa utfallet är om du själv ingår i utvecklingsteamet.) Låt oss se vad vi behöver.

För att komma igång med en migrering från Jenkins till GitLab CI rekommenderar jag att du har följande kunskaper:

• YAML

• YAML

• YAML

• Förståelse för vad ditt team gör

Varför fokusera så mycket på YAML? Svaret är enkelt: Allt i GitLab CI använder YAML-syntax. Nästa del av kursen handlar om att förstå vad som behövs från Jenkins i GitLab CI.

CI-terminologi

Eftersom GitLab CI är ett helt annat verktyg än Jenkins (tekniskt sett är båda glorifierade cronjob-körare) är det viktigt att vara överens om terminologin.

Jenkins

GitLab

Skillnad

Agent/nod

GitLab runner

I Jenkins är en ”agent” eller ”nod” en maskin där jobb körs. I GitLab är motsvarigheten en ”runner”, som kör jobb definierade i .gitlab-ci.yml. GitLab erbjuder delade runners (som driftas av GitLab) eller självhanterade runners.

Jenkinsfile

.gitlab-ci.yml

Jenkinsfile definierar pipelinen i Jenkins, vanligtvis med Groovy-baserad syntax. I GitLab CI definieras pipelinen med filen .gitlab-ci.yml, som använder YAML-syntax.

Stages och steg

Stages och jobb

En pipeline delas in i steg i både Jenkins och GitLab CI. I Jenkins innehåller varje steg flera delsteg, medan ett steg i GitLab CI innehåller jobb (som kan köras sekventiellt eller parallellt).

Utlösare / byggutlösare

Pipeline-utlösare

Jenkins utlöser jobb via SCM-pollning, webhook eller manuella utlösare. GitLab har liknande alternativ, såsom webhooks, scheman och manuella pipeline-körningar, men GitLab integreras även med GitLab-specifika händelser (t.ex. push-händelser).

Arbetsyta

CI/CD Runner-katalog

I Jenkins är arbetsytan en katalog på agentdatorn där jobb körs. Runnerns arbetskatalog fungerar på liknande sätt i GitLab, men hanteras av GitLab Runner och artifacts lagras på ett annat sätt (med GitLabs artifact-lagring).

Jenkins-plugin

GitLab CI-mallar /komponenter

GitLab CI minimerar beroendet av externa tillägg, vilket förenklar hanteringen. Komponenter ger modularitet, medan mallar möjliggör återanvändning. Läs mer i GitLab CI Catalog.

Artifacts

Artifacts

Både Jenkins och GitLab CI gör det möjligt att lagra build-artifacts (t.ex. loggar och rapporter). GitLab CI har en inbyggd funktion för att hantera och ladda ner artifacts som lagras under en viss tidsperiod eller för ett specifikt pipeline-jobb.

Jobb

Jobb

I Jenkins representerar ett jobb en enskild arbetsenhet (t.ex. en build). I GitLab är ett jobb en enskild uppgift inom ett pipeline-steg. Den viktigaste skillnaden är hur jobb definieras och körs i .gitlab-ci.yml jämfört med i Jenkins jobbkonfiguration.

Nödvändiga miljöer

Som vi ser i terminologin har GitLab CI inte ”built-in”, ”nodes” eller ”agents” som Jenkins har. I stället används runners. Här kommer din domänexpertis in i bilden, eftersom du behöver ta hänsyn till teamets specifika behov.

Vilka miljöer behöver du? Du måste konfigurera egna runners om du kör GitLab on-premises. De kan köras direkt på Linux, Windows eller macOS. Du kan också köra dem via Docker på dessa operativsystem eller använda Kubernetes för att orkestrera Docker-runners på begäran i bakgrunden. Om du har valt GitLab.com (SaaS-alternativet) kan du använda publika runners, beroende på företagets policyer.

Nu när du har definierat dina krav är det dags att utvärdera dina befintliga Jenkins-noder/-agenter. Kontrollera om de kan återanvändas genom att installera GitLab Runner, eller om det är dags att avveckla dem och skicka dem till det stora server-Valhalla, där all pensionerad hårdvara får vila i frid.

Tips när du konverterar från Jenkinsfile till GitLab CI yaml-fil

Innan du börjar med .gitlab-ci.yaml-filen bör du titta på dina befintliga Jenkinsfiles eller konfigurationer för freestyle-jobb.

Förstår du verkligen vad de gör? Om svaret är nej rekommenderar jag starkt att du först hanterar den tekniska skulden och använder tasker-verktyget.

sh '''

if ! command -v node &> /dev/null; then

curl -fsSL https://deb.nodesource.com/setup_${LTS}.x -o nodesource_setup.sh

            bash nodesource_setup.sh

            rm nodesource_setup.sh

            apt-get install -y nodejs

else

node -v

fi

npm install -g grunt-cli

rm -rf node_modules && ||

npm cache clean --force && npm install -g npm@latest

npm -v

npm outdated --long

npm install

npm audit fix

npm ls --depth=0

npm cache verify

node -v

npm install --no-save eslint prettier jest

which node

which npm

npm ls -g --depth=0

'''

Så detta kan till exempel omvandlas till sh 'npm run install-global-dependencies'

Nu till de faktiska tipsen och tricken. Det kan finnas giltiga skäl att ha flerradiga shell-/bash-skript som helt enkelt inte motiverar att ligga i en tasker- eller separat skriptfil.

Exempel på flera rader från Jenkins

 sh '''

# Create a Python virtual environment

python3 -m venv venv

# Activate the virtual environment

source venv/bin/activate

# Install dependencies from requirements.txt

pip install -r requirements.txt

# Run the Python script

python my_script.py

# Inaktivera den virtuella miljön

deactivate

'''

Så använder du artefakter från olika steg

I Jenkinsfile finns stegen stash och unstash för att lagra build-binärer och andra artefakter under pipeline-körningen. GitLab har inget motsvarande, men använder konceptet ”artifacts”.

Exempel på Jenkinsfile:

stage('Build Python Project') {

steps {

script {

// Build the Python project using pdm

sh '''

pdm build

'''

// Stash the build artifacts (e.g., .whl or .tar.gz files)

stash name: 'build-artifacts', includes: 'dist/*'

}

}

}

stage('Deploy Python Project') {

steps {

script {

// Unstash the build artifacts from the previous stage

unstash 'build-artifacts'

// Install the built package from the dist folder

sh '''

pip install dist/*.whl

python -m my_module

'''

}

}

}

Exempel på GitLab CI-yaml:

build_python_project:

  stage: build

  script:

- pdm build  # Bygg Python-projektet

  artifacts:

sökvägar:

- dist/*  # Store the built artifacts (e.g., .whl, .tar.gz)

expire_in: 1 timme  # Ange utgångstid för artifacts

deploy_python_project:

  stage: deploy

  dependencies:

- build_python_project  # Detta säger åt GitLab CI att använda artifacts från byggsteget

  script:

- pip install dist/*.whl  # Installera det byggda wheel-paketet

- python -m my_module  # Kör Python-modulen

Åtgärder efter build

I Jenkins är åtgärder efter build kraftfulla. Du kan definiera dem med ytterligare steg, till exempel always, failure och cleanup. I GitLab har du bara after_script, som naturligtvis kan innehålla villkor. En av de viktigaste sakerna jag lade märke till i GitLab CI är att du inte kan få pipelinen att misslyckas med blocket after_script. Om du alltså vill att din pipeline ska misslyckas, till exempel om dina enhetstester inte uppnådde en tillräckligt hög godkänd andel, behöver du göra det i ett script-block i stället för i after_script.

Exempel på Jenkinsfile:

stage('Run JUnit Tests') {

  steps {

script {

sh 'mvn test'

}

  }

  post {

always {

junit '**/target/test-classes/*.xml'

}

  }

}

Exempel på GitLab CI YAML:

test:

  stage: test

  script:

- mvn test

  after_script:

- |

if [ -f "target/test-classes/*.xml" ]; then

echo "JUnit test results found. Archiving..."

# Use GitLab's artifact feature to store the test results

mv target/test-classes/*.xml /tmp/junit-test-results/

else

echo "No JUnit test results found."

            exit 1 # doesn’t affect the pipeline status

fi

  artifacts:

paths:

- /tmp/junit-test-results/*.xml

expire_in: 1 hour

Här är några konkreta exempel på vad du kan stöta på när du gör en direkt 1:1-migrering från Jenkinsfiles till GitLab CI YAML. Jag rekommenderar starkt att du kör YAMLLint lokalt mot filen .gitlab-ci.yml innan du pushar den till fjärrrepo:t. AI-verktyg som GitHub Copilot kan också vara användbara för att göra grovjobbet när du väl har fått en grundläggande förståelse.

Jenkins-pluginer

”Men hur är det med Jenkins-pluginer?” kanske du frågar. De tidigare exemplen nämnde eller använde dem inte eftersom GitLab CI inte är beroende av pluginer. Ingen mer pluginhantering eller problem med Maven/Gradle-versioner eller Java-beroenden!

I stället för pluginer och delade bibliotek använder GitLab CI mallar! GitLab erbjuder många fördefinierade mallar som du kan skapa och dela inom hela organisationen.

Ett annat alternativ till pluginer är att leta efter CLI-verktyg för olika användningsfall. JFrog erbjuder till exempel både en Artifactory Jenkins-plugin och ett CLI-verktyg.

I stället för att skapa ett eget anpassat verktyg rekommenderar jag därför att du först undersöker om det redan finns ett lämpligt verktyg som fungerar direkt.

Sammanfattning

Innan du påbörjar det faktiska arbetet rekommenderar jag att du tar dig tid att planera. Ställ följande frågor till dig själv och teamet som använder pipelinen:

• Producerar den nuvarande pipelinen det resultat vi behöver?

• Skapar den nuvarande pipelinen värde för oss?

• Vad är det mest irriterande med den nuvarande pipelinen?

Att byta verktyg är som att börja med en tom duk, och det är en situation som bör hanteras varsamt.

När pipeline-målen och gatekeepers har definierats bör du jämföra dem med vad som behövs från det gamla systemet. Därefter kan det faktiska arbetet börja. Ta dig också tid att bekanta dig med GitLab CI/CD – förstå vad som finns och var du hittar det. Webbgränssnittet skiljer sig en hel del från Jenkins, så jag rekommenderar att du går en utbildning eller åtminstone tittar på några exempelvideor.

Och om du behöver hjälp med uppgiften är du alltid välkommen att kontakta oss!