Miten pääset alkuun siirtyessäsi Jenkinsistä GitLab CI:hin?

Wikipedian mukaan:

Kun ymmärrät, mikä pipeline on, näet, miten CI/CD-työkalun valinta vaikuttaa työnkulkusi tehokkuuteen ja luotettavuuteen. Koska GitLab CI on uusi valitsemasi työkalu, tämä merkitsee uutta vaihetta ohjelmistosi elinkaaressa ja muuttaa myös tiimisi työskentelytapoja.

Ennen kuin yrität 1:1-migraatiota (joka ei todennäköisesti ole mahdollinen), suosittelen pysähtymään hetkeksi ja keskustelemaan tiimisi kanssa siitä, oletko tyytyväinen siihen, miten pipelinesi on toiminut tähän asti. Voit hyödyntää keskustelun tukena erilaisia työkaluja, kuten pipeline gameamme!

Migraation aloittaminen

Nyt kun olet määritellyt ja tehnyt suunnitelmasi, mikä on pipelinen tavoite ja miten se tuottaa arvoa sinulle ja pipelinea käyttävälle kehitystiimille (paras lopputulos olisi, jos kuulut itse suoraan kehitystiimiin)? Katsotaan, mitä tarvitsemme

Jenkinsistä GitLab CI:hin tehtävän migraation aloittamiseen suosittelen seuraavia taitoja:

• YAML

• YAML

• YAML

• Ymmärrys siitä, mitä tiimisi tekee

Miksi siis keskittyä niin paljon YAMLiin? Vastaus on yksinkertainen: GitLab CI:ssä kaikki käyttää YAML-syntaksia. Kurssin seuraavassa osassa selvitetään, mitä Jenkinsistä tarvitaan GitLab CI:ssä.

CI:n terminologia

Koska GitLab CI on täysin erilainen työkalu kuin Jenkins (teknisesti molemmat ovat vain hienostuneita cronjob-ajureita), on tärkeää sopia terminologiasta.

Jenkins

GitLab

Ero

Agentti/solmu

GitLab runner

Jenkinsissä ”agentti” tai ”solmu” on kone, jolla työt suoritetaan. GitLabissa vastaava on ”runner”, joka suorittaa .gitlab-ci.yml-tiedostossa määritetyt työt. GitLab tarjoaa jaettuja runnereita (GitLabin ylläpitämiä) sekä itse hallinnoituja runnereita.

Jenkinsfile

.gitlab-ci.yml

Jenkinsfile määrittää pipelinen Jenkinsissä yleensä Groovy-pohjaisella syntaksilla. GitLab CI:ssä pipeline määritetään YAML-syntaksia käyttävällä .gitlab-ci.yml-tiedostolla.

Vaiheet ja askeleet

Vaiheet ja työt

Pipeline on jaettu vaiheisiin sekä Jenkinsissä että GitLab CI:ssä. Jenkinsissä kukin vaihe sisältää useita askelia, kun taas GitLab CI:ssä vaihe sisältää jobeja (jotka voivat suorittua peräkkäin tai rinnakkain).

Käynnistin / build-käynnistin

Pipeline-käynnistimet

Jenkins käynnistää jobeja SCM-kyselyllä, webhookeilla tai manuaalisilla käynnistimillä. GitLab tarjoaa vastaavia vaihtoehtoja, kuten webhookit, aikataulut ja pipelinejen manuaalisen suorittamisen, mutta GitLab integroituu myös GitLab-kohtaisiin tapahtumiin (esimerkiksi push-tapahtumiin).

Työtila

CI/CD Runnerin hakemisto

Jenkinsissä työtila on agenttikoneella sijaitseva hakemisto, jossa jobit suoritetaan. Runnerin työhakemisto toimii GitLabissa vastaavasti, mutta GitLab Runner hallinnoi sitä, ja artifactit tallennetaan eri tavalla (GitLabin artifact-tallennusta käyttäen).

Jenkins-plugin

GitLab CI -mallit / komponentit

GitLab CI vähentää riippuvuutta ulkoisista laajennuksista, mikä helpottaa hallintaa. Komponentit tuovat modulaarisuutta, ja mallit mahdollistavat uudelleenkäytön. Tutustu tarkemmin GitLab CI Catalogiin.

Artifactit

Artifactit

Sekä Jenkins että GitLab CI mahdollistavat build-artifactien, kuten lokien ja raporttien, tallentamisen. GitLab CI:ssä on sisäänrakennettu toiminto, jolla voit hallita ja ladata tietyn ajan tai pipeline-jobin ajan tallennettuja artifacteja.

Jobit

Jobit

Jenkinsissä jobi edustaa yhtä työyksikköä, kuten buildia. GitLabissa jobi on yksittäinen tehtävä pipeline-vaiheen sisällä. Keskeinen ero on siinä, miten jobit määritellään ja suoritetaan .gitlab-ci.yml-tiedostossa verrattuna Jenkinsin job-konfiguraatioon.

Tarvittavat ympäristöt

Kuten termistöstä näkyy, GitLab CI:ssä ei ole Jenkinsin tapaan "built-in"-toimintoa, "nodeja" tai "agentteja". Sen sijaan se käyttää runnereita. Tässä tarvitaan toimialasi asiantuntemusta, sillä sinun on huomioitava tiimisi erityisvaatimukset.

Mitä ympäristöjä tarvitset? Jos käytät GitLabia on-premises-ympäristössä, sinun on määritettävä omat runnerisi. Ne voivat toimia suoraan Linuxissa, Windowsissa tai macOS:ssä. Voit ajaa niitä myös Dockerin kautta näissä käyttöjärjestelmissä tai hyödyntää Kubernetesia taustalla toimivien, tarpeen mukaan käynnistyvien Docker-runnerien orkestrointiin. Jos olet valinnut GitLab.comin (SaaS-mallin), voit käyttää julkisia runnereita yrityksesi käytäntöjen mukaisesti.

Nyt kun olet määritellyt vaatimuksesi, on aika arvioida nykyiset Jenkins-nodesi/agenttisi. Tarkista, voiko niitä hyödyntää uudelleen asentamalla GitLab Runnerin, vai onko aika poistaa ne käytöstä ja lähettää ne suureen Server Valhallaan, jossa kaikki eläkkeelle jääneet laitteistot saavat levätä rauhassa.

Vinkkejä Jenkinsfilestä GitLab CI yaml -tiedostoon siirtymiseen

Ennen kuin alat tehdä .gitlab-ci.yaml-tiedostoa, tutustu nykyisiin Jenkinsfileihisi tai freestyle-jobien konfiguraatioihin.

Ymmärrätkö todella, mitä ne tekevät? Jos et, suosittelen vahvasti hoitamaan teknisen velan ensin ja käyttämään tasker-työkalua.

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

'''

Tämä voidaan siis muuntaa esimerkiksi muotoon sh 'npm run install-global-dependencies'

Seuraavaksi varsinaisiin vinkkeihin ja nikseihin. Monirivisille shell-/bash-skripteille voi olla päteviä syitä, jotka eivät kuitenkaan oikeuta sijoittamaan niitä tehtäväajuriin tai erilliseen skriptitiedostoon.

Monirivinen esimerkki Jenkinsistä

 sh '''

# Luo Python-virtuaaliympäristö

python3 -m venv venv

# Aktivoi virtuaaliympäristö

source venv/bin/activate

# Asenna riippuvuudet requirements.txt-tiedostosta

pip install -r requirements.txt

# Suorita Python-skripti

python my_script.py

# Poista virtuaaliympäristö käytöstä

deactivate

'''

Eri vaiheiden artifactien käyttö

Jenkinsfilessä on pipeline-ajon build-binäärien ja muiden artifactien tallentamiseen stash- ja unstash-vaiheet. GitLabissa ei ole vastaavaa toimintoa, mutta siellä on artifacts-käsite.

Jenkinsfile-esimerkki:

stage('Build Python Project') {

steps {

script {

// Rakenna Python-projekti pdm:llä

sh '''

pdm build

'''

// Tallenna build-artifactit (esim. .whl- tai .tar.gz-tiedostot)

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

}

}

}

stage('Deploy Python Project') {

steps {

script {

// Palauta build-artifactit edellisestä vaiheesta

unstash 'build-artifacts'

// Install the built package from the dist folder

sh '''

pip install dist/*.whl

python -m my_module

'''

}

}

}

GitLab CI yaml -esimerkki:

build_python_project:

  stage: build

  script:

- pdm build  # Rakenna Python-projekti

  artifacts:

polut:

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

expire_in: 1 tunti  # Aseta artefaktien vanhenemisaika

deploy_python_project:

  stage: deploy

  dependencies:

- build_python_project  # Tämä kertoo GitLab CI:lle, että se käyttää build-vaiheen artefakteja

  script:

- pip install dist/*.whl  # Asenna rakennettu wheel-paketti

- python -m my_module  # Suorita Python-moduuli

Buildin jälkeiset toimet

Jenkinsissä buildin jälkeiset toimet ovat tehokkaita. Voit määritellä niitä lisävaiheilla, kuten always, failure ja cleanup. GitLabissa käytössäsi on vain after_script, jossa voi toki käyttää ehtoja. Yksi merkittävimmistä GitLab CI:ssä huomaamistani asioista on, että after_script-lohkolla ei voi epäonnistuttaa pipelinea. Jos siis haluat, että pipeline epäonnistuu esimerkiksi silloin, kun yksikkötestien läpäisyaste ei ole riittävän korkea, tämä on tehtävä script-lohkossa after_scriptin sijaan.

Jenkinsfile-esimerkki:

stage('Run JUnit Tests')

  steps {

script {

sh 'mvn test'

}

  }

  post {

always {

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

}

  }

}

GitLab CI YAML -esimerkki:

test:

  stage: test

  script:

- mvn test

  after_script:

- |

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

echo "JUnit-testitulokset löytyivät. Arkistoidaan..."

# Tallenna testitulokset GitLabin artifact-ominaisuudella

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

else

echo "JUnit-testituloksia ei löytynyt."

            exit 1 # ei vaikuta pipelinen tilaan

fi

  artifacts:

paths:

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

expire_in: 1 hour

Edellä on ollut muutama konkreettinen esimerkki tilanteista, joita saatat kohdata tehdessäsi 1:1-migraatiota Jenkinsfileista GitLab CI YAMLiin. Suosittelen lämpimästi ajamaan YAMLLintin paikallisesti .gitlab-ci.yml-tiedostolle ennen kuin työnnät sen etärepositorioon. Lisäksi tekoälytyökalut, kuten GitHub Copilot, voivat helpottaa raskainta työtä, kun perusymmärrys on hallussa.

Jenkins-lisäosat

”Entä Jenkins-lisäosat?” saatat kysyä. Niitä ei mainittu tai käytetty aiemmissa esimerkeissä, koska GitLab CI ei perustu lisäosiin. Ei enää lisäosien hallintaa tai ongelmia Maven-/Gradle-versioiden tai Java-riippuvuuksien kanssa!

Lisäosien ja jaettujen kirjastojen sijaan GitLab CI käyttää malleja! GitLab tarjoaa monia valmiita malleja, joita voit luoda ja jakaa koko organisaatiossasi.

Toinen vaihtoehto lisäosille on etsiä eri käyttötarkoituksiin sopivia CLI-työkaluja. JFrog tarjoaa esimerkiksi sekä Artifactory Jenkins -lisäosan että CLI-työkalun.

Sen sijaan, että loisit oman räätälöidyn työkalun, suosittelen ensin tarkistamaan, löytyykö sopiva valmis työkalu jo valmiiksi.

Yhteenveto

Ennen varsinaisen työn aloittamista kannattaa käyttää aikaa suunnitteluun. Esitä itsellesi ja pipelinea käyttävälle tiimillesi seuraavat kysymykset:

• Tuottaako nykyinen pipeline tarvitsemamme lopputuloksen?

• Tuoko nykyinen pipeline meille arvoa?

• Mikä nykyisessä pipelinessa on ärsyttävintä?

Työkalujen vaihtaminen on kuin aloittaisi tyhjältä kankaalta, joten tilanteeseen kannattaa suhtautua harkiten.

Kun pipelinen tavoitteet ja hyväksyjät on määritelty, vertaa niitä vanhan järjestelmän vaatimuksiin. Aloita sitten varsinainen työ. Käytä myös aikaa GitLab CI/CD:hen tutustumiseen – selvitä, mitä ominaisuuksia on saatavilla ja mistä ne löytyvät. Verkkokäyttöliittymä on melko erilainen kuin Jenkinsissä, joten suosittelen osallistumaan koulutukseen tai ainakin katsomaan esimerkkivideoita.

Jos tarvitset apua tehtävässä, ota rohkeasti yhteyttä!