Qu'est-ce que Jenkins? Le serveur CI expliqué

Jenkins offre un moyen simple de configurer un environnement d'intégration continue ou de livraison continue (CI / CD) pour presque toutes les combinaisons de langages et de référentiels de code source à l'aide de pipelines, ainsi que d'automatiser d'autres tâches de développement de routine. Bien que Jenkins n'élimine pas la nécessité de créer des scripts pour des étapes individuelles, il vous offre un moyen plus rapide et plus robuste d'intégrer toute votre chaîne d'outils de construction, de test et de déploiement que vous ne pouvez facilement créer vous-même.

«Ne cassez pas la construction nocturne!» est une règle cardinale dans les ateliers de développement de logiciels qui publient chaque matin une version de produit fraîchement construite pour leurs testeurs. Avant Jenkins, le mieux qu'un développeur pouvait faire pour éviter de casser la compilation nocturne était de construire et de tester soigneusement et avec succès sur une machine locale avant de valider le code. Mais cela signifiait tester ses changements de manière isolée, sans les engagements quotidiens de tous les autres. Il n'y avait aucune garantie ferme que la construction nocturne survivrait à son engagement.

Jenkins - à l'origine Hudson - était une réponse directe à cette limitation.

Hudson et Jenkins

En 2004, Kohsuke Kawaguchi était développeur Java chez Sun. Kawaguchi était fatigué de casser des builds dans son travail de développement et voulait trouver un moyen de savoir, avant de valider le code dans le référentiel, si le code allait fonctionner. Kawaguchi a donc construit un serveur d'automatisation dans et pour Java pour rendre cela possible, appelé Hudson. Hudson est devenu populaire chez Sun et s'est propagé à d'autres entreprises en tant qu'open source.

Avance rapide jusqu'en 2011, et un différend entre Oracle (qui avait acquis Sun) et la communauté open source indépendante d'Hudson a conduit à une fourchette avec un changement de nom, Jenkins. En 2014, Kawaguchi est devenu CTO de CloudBees, qui propose des produits de livraison continue basés sur Jenkins.

Les deux fourchettes ont continué à exister, bien que Jenkins soit beaucoup plus actif. Aujourd'hui, le projet Jenkins est toujours actif. Le site Web Hudson a été fermé le 31 janvier 2020.

En mars 2019, la Linux Foundation, avec CloudBees, Google et un certain nombre d'autres entreprises, ont lancé une nouvelle fondation de logiciels open source appelée Continuous Delivery Foundation (CDF). Les contributeurs de Jenkins ont décidé que leur projet devait rejoindre cette nouvelle fondation. Kawaguchi a écrit à l'époque que rien d'important ne changerait pour les utilisateurs.

En janvier 2020, Kawaguchi a annoncé qu'il déménageait dans sa nouvelle startup, Launchable. Il a également déclaré qu'il se retirerait officiellement de Jenkins, tout en restant au comité de supervision technique de la Continuous Delivery Foundation, et en transférant son rôle chez CloudBees à un conseiller.

Vidéo connexe: Comment fournir du code plus rapidement avec CI / CD

Automatisation Jenkins

Aujourd'hui, Jenkins est le principal serveur d'automatisation open source avec quelque 1 600 plug-ins pour prendre en charge l'automatisation de toutes sortes de tâches de développement. Le problème que Kawaguchi essayait à l'origine de résoudre, l'intégration continue et la livraison continue du code Java (c'est-à-dire la construction de projets, l'exécution de tests, l'analyse de code statique et le déploiement) n'est qu'un des nombreux processus que les gens automatisent avec Jenkins. Ces 1600 plug-ins couvrent cinq domaines: plates-formes, interface utilisateur, administration, gestion du code source et, le plus souvent, gestion des builds.

Comment fonctionne Jenkins

Jenkins est distribué en tant qu'archive WAR et en tant que packages d'installation pour les principaux systèmes d'exploitation, en tant que package Homebrew, en tant qu'image Docker et en tant que code source. Le code source est principalement Java, avec quelques fichiers Groovy, Ruby et Antlr.

Vous pouvez exécuter Jenkins WAR de manière autonome ou en tant que servlet dans un serveur d'applications Java tel que Tomcat. Dans les deux cas, il produit une interface utilisateur Web et accepte les appels à son API REST.

Lorsque vous exécutez Jenkins pour la première fois, il crée un utilisateur administratif avec un long mot de passe aléatoire, que vous pouvez coller dans sa page Web initiale pour déverrouiller l'installation.

Plug-ins Jenkins

Une fois installé, Jenkins vous permet d'accepter la liste de plugins par défaut ou de choisir vos propres plugins.

Une fois que vous avez choisi votre ensemble initial de plug-ins, cliquez sur le bouton Installer et Jenkins les ajoutera.

L'écran principal de Jenkins affiche la file d'attente de construction actuelle et l'état de l'exécuteur, et propose des liens pour créer de nouveaux éléments (travaux), gérer les utilisateurs, afficher les historiques de construction, gérer Jenkins, consulter vos vues personnalisées et gérer vos informations d'identification.

Un nouvel élément Jenkins peut être l'un des six types de travail, plus un dossier pour organiser les éléments.

Il y a 18 choses que vous pouvez faire depuis la page Gérer Jenkins, y compris la possibilité d'ouvrir une interface de ligne de commande. À ce stade, cependant, nous devrions examiner les pipelines, qui sont des flux de travail améliorés généralement définis par des scripts.

Pipelines Jenkins

Une fois que vous avez configuré Jenkins, il est temps de créer des projets que Jenkins peut créer pour vous. Bien que vous puissiez utiliser l'interface utilisateur Web pour créer des scripts, la meilleure pratique actuelle consiste à créer un script de pipeline, nommé Jenkinsfile , et à l'archiver dans votre référentiel. La capture d'écran ci-dessous montre le formulaire Web de configuration pour un pipeline multibranch.

Comme vous pouvez le voir, les sources de branche pour ce type de pipeline dans mon installation de base de Jenkins peuvent être des référentiels Git ou Subversion, y compris GitHub. Si vous avez besoin d'autres types de référentiels ou de différents services de référentiel en ligne, il suffit d'ajouter les plug-ins appropriés et de redémarrer Jenkins. J'ai essayé, mais je ne pouvais pas penser à un système de gestion de code source (SCM) qui n'a pas déjà un plug-in Jenkins répertorié.

Les pipelines Jenkins peuvent être déclaratifs ou scriptés. Un pipeline déclaratif , le plus simple des deux, utilise une syntaxe compatible Groovy - et si vous le souhaitez, vous pouvez démarrer le fichier avec #!groovypour pointer votre éditeur de code dans la bonne direction. Un pipeline déclaratif commence par un pipelinebloc, définit un agentet définit stagesqui inclut un exécutable steps, comme dans l'exemple en trois étapes ci-dessous.

pipeline {

    agent quelconque

    étapes {

        stage ('Build') {

            pas {

                echo 'Bâtiment ..'

            }

        }

        stage ('Test') {

            pas {

                echo 'Test ..'

            }

        }

        stage ('Deploy') {

            pas {

                echo 'Déploiement ...'

            }

        }

    }

}

pipelineest le bloc externe obligatoire pour appeler le plugin de pipeline Jenkins. agentdéfinit où vous souhaitez exécuter le pipeline. anydit d'utiliser n'importe quel agent disponible pour exécuter le pipeline ou l'étape. Un agent plus spécifique peut déclarer un conteneur à utiliser, par exemple:

agent {

    docker {

        image 'maven: 3-alpin'

        étiquette 'mon-étiquette-définie'

        args '-v / tmp: / tmp'

    }

}

stagescontiennent une séquence d'une ou plusieurs directives d'étape. Dans l'exemple ci-dessus, les trois étapes sont Build, Test et Deploy.

stepsfaire le travail réel. Dans l'exemple ci-dessus, les étapes ont simplement imprimé des messages. Une étape de construction plus utile pourrait ressembler à ce qui suit:

pipeline {

    agent quelconque

    étapes {

        stage ('Build') {

            pas {

                sh 'faire'

                artefacts archiveArtifacts: '** / target / *. jar', empreinte digitale: true

            }

        }

    }

}

Ici, nous appelons à makepartir d'un shell, puis archivons tous les fichiers JAR produits dans l'archive Jenkins.

La postsection définit les actions qui seront exécutées à la fin de l'exécution ou de l'étape du pipeline. Vous pouvez utiliser un certain nombre de blocs post-état dans la section après: always, changed, failure, success, unstableet aborted.

Par exemple, le Jenkinsfile ci-dessous exécute toujours JUnit après l'étape de test, mais n'envoie un e-mail que si le pipeline échoue.

pipeline {

    agent quelconque

    étapes {

        stage ('Test') {

            pas {

                sh 'faire chèque'

            }

        }

    }

    Publier {

        toujours {

            junit '** / target / *. xml'

        }

        échec {

            mail à: [email protected], objet: 'Le pipeline a échoué :('

        }

    }

}

Le pipeline déclaratif peut exprimer la plupart de ce dont vous avez besoin pour définir des pipelines et est beaucoup plus facile à apprendre que la syntaxe de pipeline scriptée, qui est un DSL basé sur Groovy. Le pipeline scripté est en fait un environnement de programmation à part entière.

À titre de comparaison, les deux fichiers Jenkins suivants sont complètement équivalents.

Pipeline déclaratif

pipeline {

    agent {nœud docker ': 6.3'}

    étapes {

        stage ('build') {

            pas {

                sh 'npm —version'

            }

        }

    }

Pipeline scripté

node ('docker') {

    caisse scm

    stage ('Build') {

        docker.image ('node: 6.3'). inside {

            sh 'npm —version'

        }

    }

}

Blue Ocean, l'interface graphique de Jenkins

Si vous souhaitez la dernière et la meilleure interface utilisateur Jenkins, vous pouvez utiliser le plug-in Blue Ocean, qui offre une expérience utilisateur graphique. Vous pouvez ajouter le plug-in Blue Ocean à votre installation Jenkins existante ou exécuter un conteneur Jenkins / Blue Ocean Docker. Avec Blue Ocean installé, votre menu principal Jenkins aura une icône supplémentaire:

Vous pouvez ouvrir Blue Ocean directement si vous le souhaitez. Il se trouve dans le dossier / blue sur le serveur Jenkins. La création de pipeline dans Blue Ocean est un peu plus graphique que dans Jenkins ordinaire:

Jenkins Docker

Comme je l'ai mentionné précédemment, Jenkins est également distribué sous forme d'image Docker. Il n'y a pas beaucoup plus à faire: une fois que vous avez choisi le type de SCM, vous fournissez une URL et des informations d'identification, puis créez un pipeline à partir d'un référentiel unique ou analysez tous les référentiels de l'organisation. Chaque branche avec un Jenkinsfile recevra un pipeline.

Ici, j'exécute une image Blue Ocean Docker, fournie avec quelques plug-ins de service Git de plus installés que la liste par défaut des fournisseurs SCM:

Une fois que vous avez exécuté certains pipelines, le plug-in Blue Ocean affichera leur état, comme indiqué ci-dessus. Vous pouvez zoomer sur un pipeline individuel pour voir les étapes et les étapes:

Vous pouvez également zoomer sur les branches (en haut) et les activités (en bas):  

-

Pourquoi utiliser Jenkins?

Le plug-in Jenkins Pipeline que nous utilisons prend en charge un cas d'utilisation général d'intégration continue / livraison continue (CICD), qui est probablement l'utilisation la plus courante pour Jenkins. Il existe des considérations spécialisées pour certains autres cas d'utilisation.

Les projets Java étaient la raison d'être originale de Jenkins. Nous avons déjà vu que Jenkins prend en charge la construction avec Maven; il fonctionne également avec Ant, Gradle, JUnit, Nexus et Artifactory.

Android exécute une sorte de Java, mais introduit la question de savoir comment tester sur la large gamme d'appareils Android. Le plug-in d'émulateur Android vous permet de créer et de tester sur autant d'appareils émulés que vous souhaitez définir. Le plug-in Google Play Publisher vous permet d'envoyer des builds à un canal alpha de Google Play pour publication ou tests supplémentaires sur des appareils réels.

J'ai montré des exemples où nous avons spécifié un conteneur Docker comme agent pour un pipeline et où nous avons exécuté Jenkins et Blue Ocean dans un conteneur Docker. Les conteneurs Docker sont très utiles dans un environnement Jenkins pour améliorer la vitesse, l'évolutivité et la cohérence.

Il existe deux cas d'utilisation majeurs pour Jenkins et GitHub. L'un est l'intégration de build, qui peut inclure un hook de service pour déclencher Jenkins à chaque validation dans votre référentiel GitHub. Le second est l'utilisation de l'authentification GitHub pour contrôler l'accès à Jenkins via OAuth.

Jenkins prend en charge de nombreux autres langages en plus de Java. Pour C / C ++, il existe des plug-ins pour capturer les erreurs et les avertissements de la console, générer des scripts de construction avec CMake, exécuter des tests unitaires et effectuer une analyse de code statique. Jenkins a un certain nombre d'intégrations avec des outils PHP.

Bien que le code Python n'ait pas besoin d'être construit (sauf si vous utilisez Cython, par exemple, ou que vous créez une roue Python pour l'installation), il est utile que Jenkins s'intègre aux outils de test et de rapport Python, tels que Nose2 et Pytest, et la qualité du code des outils tels que Pylint. De même, Jenkins s'intègre aux outils Ruby tels que Rake, Cucumber, Brakeman et CI :: Reporter.

Jenkins pour CI / CD

Dans l'ensemble, Jenkins offre un moyen simple de configurer un environnement CI / CD pour à peu près n'importe quelle combinaison de langages et de référentiels de code source à l'aide de pipelines, ainsi que d'automatiser un certain nombre d'autres tâches de développement de routine. Bien que Jenkins n'élimine pas la nécessité de créer des scripts pour des étapes individuelles, il vous offre un moyen plus rapide et plus robuste d'intégrer toute votre chaîne d'outils de construction, de test et de déploiement que vous ne pourriez facilement créer vous-même.