Jenkinsin multibranch pipeline ja pretested integration

Multibranch pipelinejen myötä Jenkins on tullut mukaan seuraavan sukupolven CI/CD-palvelinten kilpailuun. Kun mukana on Concourse- ja CircleCI-kaltaisia kilpailijoita, selvää voittajaa ei kuitenkaan ole.

Praqma on käyttänyt Jenkinsiä (aiemmin Hudson) de facto -standardina jatkuvan integraation palvelimena jo lähes vuosikymmenen ajan. Jenkinsin johtoasemaa ei pitkään aikaan haastettu. Viime aikoina markkinoille on kuitenkin tullut lukuisia kilpailijoita, jotka ovat tarjonneet vanhalle kunnon Jenkinsille todellisen haasteen. Vastauksena tähän Jenkins esitteli pipelinet: Groovy DSL:n, jolla CI-työnkulkua hallitaan koodilla. Kun CloudBees panostaa voimakkaasti pipelineihin, niistä on tullut Jenkinsin tulevaisuus. Jos et ole vielä tutustunut niihin, käy katsomassa Jenkinsin pipeline-sivu

Kannattaako siis vain muuntaa kaikki jobit pipelineiksi ja elää sen jälkeen onnellisena elämän loppuun asti? Vastaus on, kuten lähes kaikessa muussakin elämässä: se riippuu.

Tässä artikkelissa on esimerkkejä Phlow’sta ja Praqman Pretested Integration Pluginista. Jos se ei ole sinulle tuttu, kannattaa tutustua siihen.

Tarina

Halusimme eräällä asiakkaallamme luoda pipelinen, joka buildaa useilla käyttöjärjestelmillä rinnakkain. Ratkaisun piti estää integraatiojobin suoritus, kunnes kaikki käännökset ja yksikkötestit olivat valmistuneet. Alkuperäinen pipeline tehtiin Jenkinsin käyttöliittymässä, joten se piti toteuttaa tavalla tai toisella koodina. Ei enää osoittelua ja klikkailua!

Voisimme joko muuntaa nykyisen ratkaisun JobDSL:ksi tai yrittää tehdä vastaavan build-työnkulun Jenkins pipeline -versiona. Valitsimme Jenkins pipelinet saadaksemme käyttöömme joitakin tulevaisuuden pipelineja käsittelevässä esityksessämme luetelluista hyödyistä.

Multibranch vai ei – siinäpä kysymys!

Pipeline-jobit ovat saatavilla kahdessa muodossa: tavallisina ja multibranch-versiona. Niille yhteistä on kieli: Groovy-pohjainen DSL.

Valitsimme multibranch pipelinen, sillä siinä pipeline voidaan sisällyttää koodina samaan repositorioon (yllä olevan esityksen käyttötapaus nro 1). Tavallisessa pipelinessa ei myöskään voi tietää, mikä haara käynnisti buildin, koska Jenkins checkouttaa SHAn eikä haaraa.

Tiivistetty esimerkki tuotannossa käytössä olevasta pipelinesta löytyy täältä.

Phlow’n toteuttaminen Pipelinessa

Koska Praqman nykyinen Pretested Integration Plugin -versio ei ole yhteensopiva Pipelinen kanssa, meidän piti skriptata vastaava toiminnallisuus itse. En käy pipeline-skriptiä läpi, vaan kerron ongelmista, joita kohtasimme sitä kehittäessämme.

Git publisher, ehkä?

Koska pipelinet ovat uusi tapa käyttää Jenkinsiä, kaikkia tavallisen freestyle-jobin tarjoamia plugineja ja toimintoja ei voi hyödyntää.

Esimerkiksi Gitin checkout-rutiinia voi käyttää pretested integrationin kloonausvaiheessa, mutta kun koodi pitää pushata takaisin haaraan, apua ei ole saatavilla.

Tästä on avattu issue, mutta ennen kuin se ratkaistaan, sinun on käytettävä paljaita Git-komentoja, jotka on kääritty sshagent-pluginiin.

Yleiskuva on kuollut, eläköön yleiskuva

Kuten alla havainnollistetaan, vanhoista freestyle-jobeista saa helposti yleiskuvan, kun ne määritetään käynnistämään toisensa.

Yleiskuvasta näkee nopeasti, mikä haara on parhaillaan buildattavana. Suoritusten luetteloa selaamalla voi myös tunnistaa pipelinen jatkuvat virheet.

Jenkins Pipelinen myötä menetämme PIP:n ja freestyle-jobien avulla toteutettavan master-kohtaisen näkymän. Yleiskuva on repositoriokeskeinen, eli kaikkia haaroja käsitellään tasavertaisesti, jolloin kaikki haarat näkyvät samassa näkymässä. Esimerkiksi sekä master että /version_2.x/master ovat nyt samassa näkymässä.

Yksittäisen buildin näkymässä rinnakkaisista buildeista saa huomattavasti paremman yleiskuvan ja olennaiseen tulosteeseen on helpompi siirtyä kuin vanhassa yleisnäkymässä. Jokaista kuvaketta voi klikata, jolloin näet komentoluettelon ja niitä vastaavat lokit.

Jos tämä ominaisuus on välttämätön, sinun on tehtävä jonkinlainen dashboard, joka tarjoaa osan vanhan toimintatavan tiedoista (katso dashing.io tai Pipeline Aggregator View).

Pipeline voidaan myös jakaa kahteen osaan:

• Toinen selvittää, onnistuiko vai epäonnistuiko pretested integration

• Yksi master-putken rakentamiseen (kaikki CoDe Storyline -mallissamme kuvatun tulliaseman jälkeinen)

Näin saat haluamasi master-kohtaisen jaon, mutta menetät täydellisen jäljitettävyyden kehittäjän committeihin asti.

Yksi deleteDir() päivässä pitää lääkärin loitolla

Ellei samalla nodelle ole käynnissä useita stageja yhtä aikaa, et saa uutta workspacea. Vanhaa käytetään automaattisesti uudelleen.

Tämän vuoksi putkessasi on paljon deleteDir()-kutsuja. Muuten saat omituisia virheitä stashauksen ja unstashauksen yhteydessä.

Voit kääriä nodesi funktion sisään, jotta workspace on aina puhdas.

Aloitetaan alusta

Putken uudelleenkäynnistäminen tietystä jobista on helppoa myös freestyle-jobien kanssa.

Kun kaikki jaetaan yksittäisiin jobeihin, voimme käynnistää tietyn putken uudelleen tietystä kohdasta.

Jenkins Pipelinea käytettäessä kaikki tai ei mitään -malli tekee PIP-uudelleenkäynnistyksen mahdottomaksi, koska integraatiovaihetta ei haluta käynnistää uudelleen.

CloudBees on kehittänyt proprietary-pluginin nimeltä checkpoints. Sen avulla voit käynnistää työn uudelleen kyseisestä tarkistuspisteestä. Valitettavasti sitä ei ole julkaistu avoimena lähdekoodina eikä tätä korostavia issueita ole suljettu.

Tämä on myös peruste jakaa putki kahteen osaan: toinen integraatiolle masteriin ja toinen itse build-putkelle.

Manuaalisia pieniä askelia ja sudenkuoppia

Jos sinun täytyy tehdä manuaalista validointia ennen kuin siirryt putken seuraavaan stageen, käytä Jenkinsfile-tiedostossasi input-tagia. Jos kyse on vain signaalista, sijoita se flyweight executorille, jotta se ei varaa executor-paikkaa nodelta.

stage 'Promotion' { input 'Deploy to Production?' }

Tässä työnkulussa on muutamia haittoja. Jenkinsin käyttöliittymässä putki näyttää edelleen olevan käynnissä, vaikka se odottaa manuaalista syötettä. Olisin halunnut nähdä sen pysäköitynä aktiivisen ajon sijaan. Mutta toistaiseksi tämä on se, mitä meillä on.

Yhteenveto

Jenkins Pipelines on ehdottomasti askel oikeaan suuntaan, ja minun on oltava kanssasi täysin rehellinen: pidän siitä, mutta näen myös ongelmia!

Jenkins poisti vasta alle kuukausi sitten BETA-tunnisteen Blue Oceanista, uudesta Pipelinesiin sopivasta käyttöliittymästä.

Osa tässä kuvatuista ongelmista voi ratketa vuoden sisällä, ja osan asioista opimme vain hoitamaan tyylikkäämmin.

Kokemuksen tiivistämiseksi tässä on TL;DR edellä käsitellyistä hyvistä ja huonoista puolista:

Hyödyt:

• Mahdollisuus määrittää putki SCM-repositoriossasi; pipeline as code!

• Uusi putki on vain uusi branch, ja olet valmis

• Putkeasi ei vain käsitellä koodina, se on koodia!

• Stashaus varmistaa, että rinnakkaiset buildit ajavat samaa koodia.

• Pipeline on Jenkinsin tulevaisuus. Sopeudu parhaiden tavoin tai kuole muiden mukana.

Haitat:

• Pretested Integration -lisäosaa ei ole saatavilla

• Git SCM -toiminnallisuus rajoittuu pelkkiin Git-komentoihin

• Esihenkilöllä ei ole kokonaiskuvaa, jos pipeline on täynnä

• Kehittäjällä ei ole kokonaiskuvaa, jos pipeline jakautuu kahtia.

• Pipeline-osien uudelleensuorittaminen ei ole mahdollista

• /ready-haarat poistetaan yleisnäkymästä niiden suorittamisen (ja yhdistämisen) jälkeen