Text vyšel původně na autorově blogu.

Jenkins používám řadu let a také ho školím ve firmách, které chtějí toto řešení nasadit. Před 2 lety jsem si říkal, že Jenkins není moc dobrá cesta. Žádné použitelné novinky se dlouho neobjevovaly a vůbec se nezlepšovalo použití pro větší nasazení Jenkinsů ve firmách.

Já mám na každé Continues Integration tyto požadavky (a hned ten nejzásadnější Jenkins je dlouho nesplňoval):

• job definitions in repository
• autoscaling on traffic with lowest possible price
• pipelines / workflow
• solution for caching for installations
• docker support
• matrix builds
• distributed job across multiple nodes

Od verze 2.0 je mezi základními rozšířeními podpora pro Continuous Delivery Pipelines (dále jen pipelines), které jdou psát do souboru jako Jenkinsfile. Ten můžete mít s projektem v repozitáři a Jenkins umí spolupracovat s SCM například s Github, kde mu stačí dát jméno organizace nebo uživatele, on proskenuje vaše repositáře a tam, kde najde Jenkinsfile, pro ty repositáře vytvoří úlohy ke zpracování.

Ukázka jak takový soubor s pipelines vypadá pro malý projekt.

node {
   stage('Preparation') {
      git 'https://github.com/abtris/bee.git'
   }
   stage('Deps') {
       env.PACKAGE="github.com/abtris/bee"
       env.GOPATH="~/go"
       env.GOROOT="/usr/local/opt/go/libexec"
       sh 'glide --no-color install'
       sh 'mkdir -p release'
   }
   stage('Test') {
       sh 'make xunit'
   }
   stage('Build') {
         parallel (
            linux64: { sh "goos=linux goarch=amd64 make build" },
            linux32: { sh "goos=linux goarch=386 make build" },
            mac64: { sh "goos=darwin goarch=amd64 make build" },
            win64: { sh "goos=windows goarch=amd64 make build" }
          )
   }
   stage('Results') {
      archive 'release/*'
      junit 'tests.xml'
   }
}

Jenkinsfile je DSL v programovacím jazyku Groovy obsahuje blok s názvem node, kde si definujete, kde a co se má co spouštět. Ukázka neobsahuje žádnou podmínku, a tak Jenkins rozhodně sám, kde to spustí. Pokud byste to chtěli upřesnit, dá se specifikovat, zda to má být master nebo naopak, že to nemá být master (doporučeno) a také jde přímo označit agenta (slave), kterého máte připojeného k Jenkins masteru. Může to být instance na Amazon Web Services (AWS) nebo v jiném cloudu, případně jakýkoliv jiný počítač, který si k tomu určíte a pustíte na něm potřebného klienta.

Dalším klíčovým slovem je stage, kde si názvem rozdělíme pipeline do logických celků. Tyto části, pokud to má smysl, můžeme zpracovávat paralelně jako je to v ukázce v části Build. Využití paralelního zpracování je tam, kde chcete zkrátit čas celého buildu, a pokud na to máte volné prostředky (agenty).

Vše spouštíme pomocí linuxového shellu pomocí klíčového slova sh. Mohli bychom testovat pomocí isUnix(), zda jsme na stroji, který toho je vůbec schopen. To vám pomůže, když používáte různé stroje, některé s Windows a jiné s Linuxem.

V poslední části Results archivujeme artefakty (tady binárné soubory) vytvořené při buildu a výsledky testů z kroku Test.

To je vše. V Jenkinsu to pak vypadá takto:

Zobrazení pipelines v novém UI BlueOcean.

Pipelines mají před sebou velkou budoucnost, připravují se vylepšení v podobě online editoru a více deklarativního zápisu než dnes.

V Jenkinsu je podpora pro distribuované agenty, dnes můžete mít jednotlivé stroje v AWS (pomocí ec2, ec2-fleet pluginů), OpenStack, Docker, Kubernetes apod.

Abyste byli schopni dosáhnout kvalitního autoscalingu za dobrou cenu, dají se velmi dobře využít spot instance od AWS. Můžete ušetřit až 90 % nákladů oproti normálním instancím.

Pokud provozujete vlastní Jenkins, je potřeba vyřešit cache, ideální řešení je JFrog Artifactory, které podporuje caching pro velké množství vývojových nástrojů. Bohužel je toto řešení poměrně drahé. Ale existuje Nexus repository, které má komunitní verzi. Bohužel v Nexus OSS chybí například podpora pro PHP Composer.

Matrix buildy jsou potřeba, v Jenkinsu se jim říká Multi-configuration project. Můžete tu vytvořit vlatní matice, podle čeho chcete, a Jenkins vygeneruje potřebné projekty s parametry, které potřebujete, podobně jako kdybyste použili Job DSL plugin. To se hodí pro testování různých verzí operačního systému, verzí programovacího jazyka apod.

Poslední věcí je podpora Dockeru. V Jenkinsu je několik pluginů pro Docker. Využití může být také různé. Buď to použijete na vytvoření agentů nebo přímo můžete pouštět projekt v docker containeru. Bohužel toto funguje spolehlivě jen na linuxu.

Takto se docker popíše v Jenkins pipelines.

node('docker') {
 // My project sources include both build.xml and a Dockerfile to run it in.
 git 'https://git.mycorp.com/myproject.git'
 // Ready?
 docker.build('mycorp/ant-qwerty:latest').inside {
   sh 'ant dist-package'
 }
 archive 'app.zip'
}

Hostované řešení jako je TravisCI nebo CircleCI mají výhodu, pokud potřebujete začít. Ale postupem, když máte více lidí nebo potřebujete větší flexibilitu, tak se můžete dostat do potíží. Jenkins je náročnější na údržbu, ale umožňuje velkou flexibilitu.

Shrnutí

Jenkins 2 přinesl deklarativní popis, lepší bezpečnost a stále zachoval zpětnou kompatibilitu. Vylepšené UI a tady se stále pracuje na dalších vylepšeních (Blue Ocean). S Blue Ocean potom přijde deklarativní popis continuous delivery pipelines a také by měl tam být online visual editor pro pipelines. Na další rok mají plány také na přidání Configuration API a myslím, že by mohl Blue Ocean v budoucnu uplně nahradit dnešní UI a zároveň otevřít cestu pro to například kompletně používat Jenkins bez UI. Uvidíme, jak to bude dlouho trvat, každopádně se už teď těším na další novinky.