Didacticiel de livraison continue - Création d'un pipeline de livraison continue à l'aide de Jenkins

Livraison continue:

La livraison continue est un processus dans lequel les modifications de code sont automatiquement créées, testées et préparées pour une mise en production.J'espère que vous avez apprécié mon Ici, je vais parler des sujets suivants:

• Qu'est-ce que la livraison continue?
• Types de tests logiciels
• Différence entre l'intégration, la livraison et le déploiement continus
• Quel est le besoin d'une livraison continue?
• Utilisation pratique de Jenkins et Tomcat

Voyons rapidement comment fonctionne la livraison continue.

Qu'est-ce que la livraison continue?

Il s'agit d'un processus dans lequel vous créez un logiciel de manière à ce qu'il puisse être mis en production à tout moment.Considérez le diagramme ci-dessous:

Laissez-moi vous expliquer le diagramme ci-dessus:

• Les scripts de construction automatisés détecteront les changements dans la gestion du code source (SCM) comme Git.
• Une fois le changement détecté, le code source serait déployé sur un serveur de build dédié pour s'assurer que la build n'échoue pas et que toutes les classes de test et les tests d'intégration fonctionnent correctement.
• Ensuite, l'application de build est déployée sur les serveurs de test (serveurs de pré-production) pour le test d'acceptation utilisateur (UAT).
• Enfin, l'application est déployée manuellement sur les serveurs de production pour la publication.

Avant de continuer, il sera juste que je vous explique les différents types de tests.

Types de tests logiciels:

En gros, il existe deux types de tests:

• Test de la boîte noire: Il s'agit d'une technique de test qui ignore le mécanisme interne du système et se concentre sur la sortie générée par rapport à toute entrée et exécution du système. Il est également appelé test fonctionnel. Il est essentiellement utilisé pour valider le logiciel.
• Test de la boîte blanche: est une technique de test qui prend en compte le mécanisme interne d'un système. Il est également appelé test structurel et test de boîte en verre. Il est essentiellement utilisé pour vérifier le logiciel.

Test de la boîte blanche:

Il existe deux types de tests qui entrent dans cette catégorie.

• Test unitaire: C'est le test d'une unité individuelle ou d'un groupe d'unités liées. Il est souvent fait par le programmeur pour tester que l'unité qu'il / elle a implémentée produit une sortie attendue par rapport à une entrée donnée.
• Test d'intégration: C'est un type de test dans lequel un groupe de composants sontcombiné pour produire la sortie. En outre, l'interaction entre le logiciel et le matériel est testée si les composants logiciels et matériels ont une relation. Il peut relever à la fois du test de la boîte blanche et du test de la boîte noire.

Test de la boîte noire:

Il existe plusieurs tests qui entrent dans cette catégorie. Je vais me concentrer surquelques, qu'il est important que vous sachiez, afin de comprendre ce blog:

• Test fonctionnel / d'acceptation: Il garantit que la fonctionnalité spécifiée requise dans la configuration système requise fonctionne. Il est fait pour s'assurer que le produit livré répond aux exigences et fonctionne comme prévu par le client
• Test du système: Cela garantit qu'en plaçant le logiciel dans différents environnements (par exemple, les systèmes d'exploitation), il fonctionne toujours.
• Test de stress: Il évalue le comportement du système dans des conditions défavorables.
• Tests bêta: Cela est fait par les utilisateurs finaux, une équipe en dehors du développement ou publiant publiquement une pré-version complète du produit, connue sous le nom debêtaversion. Le but des tests bêta est de couvrir les erreurs inattendues.

Le moment est venu pour moi d'expliquer la différence entre l'intégration continue, la livraison et le déploiement.

Différences entre l'intégration, la livraison et le déploiement continus:

Le contenu visuel atteint le cerveau d'un individu de manière plus rapide et plus compréhensible que les informations textuelles. Je vais donc commencer par un schéma qui explique clairement la différence:

Dans l'intégration continue, chaque validation de code est compilée et testée, mais n'est pas en état d'être publiée. Je veux dire que l'application de construction n'est pas automatiquement déployée sur les serveurs de test afin de la valider à l'aide de différents types de tests Blackbox tels que - Test d'acceptation utilisateur (UAT).

Dans la livraison continue, l'application est déployée en continu sur les serveurs de test pour UAT. Vous pouvez également dire que l'application est prête à être mise en production à tout moment. Donc, évidemment, l'intégration continue est nécessaire pour la livraison continue.

Le déploiement continu est la prochaine étape après la livraison continue, où vous ne créez pas simplement un package déployable, mais vous le déployez en fait de manière automatisée.

Permettez-moi de résumer les différences à l'aide d'un tableau:

En termes simples, l'intégration continue fait partie à la fois de la livraison continue et du déploiement continu. Et le déploiement continu est comme la livraison continue, sauf que les versions se produisent automatiquement.

Apprenez à créer des pipelines CI / CD à l'aide de Jenkins sur le cloud

Mais la question est de savoir si l'intégration continue est suffisante.

Pourquoi avons-nous besoin d'une livraison continue?

Comprenons cela avec un exemple.

Imaginez que 80 développeurs travaillent sur un grand projet. Ils utilisent des pipelines d'intégration continue afin de faciliter les constructions automatisées. Nous savons que la version comprend également les tests unitaires. Un jour, ils ont décidé de déployer la dernière version qui avait réussi les tests unitaires dans un environnement de test.

Il doit s'agir d'une approche de déploiement longue mais contrôlée que leurs spécialistes de l'environnement ont réalisée. Cependant, le système ne semblait pas fonctionner.

Quelle pourrait être la cause évidente de l'échec?

Eh bien, la première raison à laquelle la plupart des gens penseront est qu'il y a un problème avec la configuration. Comme la plupart des gens, même ils le pensaient.Ils ont passé beaucoup de temps à essayer de trouver ce qui n'allait pas dans la configuration de l'environnement, mais ils n'ont pas pu trouver le problème.

Un développeur perspicace a adopté une approche intelligente:

Puis l'un des développeurs senior a essayé l'application sur sa machine de développement. Cela n’a pas marché non plus.

Il est revenu sur les versions antérieures et antérieures jusqu'à ce qu'il découvre que le système avait cessé de fonctionner trois semaines plus tôt. Un bug minuscule et obscur avait empêché le système de démarrer correctement. Cependant, le projet avait une bonne couverture des tests unitaires.Malgré cela, 80 développeurs, qui n'ont généralement exécuté que les tests plutôt que l'application elle-même, n'ont pas vu le problème pendant trois semaines.

Énoncé du problème:

Sans exécuter des tests d'acceptation dans un environnement de production, ils ne savent pas si l'application répond aux spécifications du client, ni si elle peut être déployée et survivre dans le monde réel. S'ils veulent des commentaires en temps opportun sur ces sujets, ils doivent étendre la portée de leur processus d'intégration continue.

Permettez-moi de résumer les leçons apprises en examinant les problèmes ci-dessus:

• Les tests unitaires testent uniquement le point de vue d'un développeur sur la solution d'un problème. Ils n'ont qu'une capacité limitée à prouver que l'application fait ce qu'elle est censée faire du point de vue des utilisateurs. Ils ne suffisent pas àidentifier les vrais problèmes fonctionnels.
• Le déploiement de l'application sur l'environnement de test est un processus complexe, intensif manuellement, assez sujet aux erreurs.Cela signifiait que chaque tentative de déploiement était une nouvelle expérience - un processus manuel, sujet aux erreurs.

Solution - Pipeline de livraison continue (test d'acceptation automatisé):

Ils ont fait passer l'intégration continue (livraison continue) à l'étape suivante et ont introduit quelques tests d'acceptation simples et automatisés qui ont prouvé que l'application fonctionnait et pouvait remplir sa fonction la plus fondamentale.La majorité des tests exécutés au cours de l'étape du test d'acceptation sont des tests d'acceptation fonctionnelle.

Fondamentalement, ils ont construit un pipeline de livraison continue, afin de s'assurer que l'application est déployée de manière transparente sur l'environnement de production, en s'assurant que l'application fonctionne correctement lorsqu'elle est déployée sur le serveur de test qui est une réplique du serveur de production.

Assez de théorie, je vais maintenant vous montrer comment créer un pipeline de livraison continue à l'aide de Jenkins.

Pipeline de livraison continue à l'aide de Jenkins:

Ici, j'utiliserai Jenkins pour créer un pipeline de livraison continue, qui comprendra les tâches suivantes:

Étapes impliquées dans la démo:

• Récupérer le code depuis GitHub
• Compiler le code source
• Test unitaire et génération des rapports de test JUnit
• Empaquetage de l'application dans un fichier WAR et déploiement sur le serveur Tomcat

Conditions préalables:

• Machine CentOS 7
• Jenkins 2.121.1
• Docker
• Tomcat 7

Étape - 1 Compilation du code source:

Commençons par créer un projet Freestyle dans Jenkins. Considérez la capture d'écran ci-dessous:

Donnez un nom à votre projet et sélectionnez Projet Freestyle:

Lorsque vous faites défiler vers le bas, vous trouverez une option pour ajouter un référentiel de code source, sélectionnez git et ajoutez l'URL du référentiel.Dans ce référentiel, il y a une amende pom.xml que nous utiliserons pour construire notre projet. Considérez la capture d'écran ci-dessous:

Nous allons maintenant ajouter un déclencheur de construction. Choisissez l'option poll SCM, en gros, nous allons configurer Jenkins pour interroger le référentiel GitHub toutes les 5 minutes pour les modifications du code. Considérez la capture d'écran ci-dessous:

Avant de continuer, laissez-moi vous donner une petite introduction au cycle de construction Maven.

Chacun des cycles de vie de build est défini par une liste différente de phases de build, dans laquelle une phase de build représente une étape du cycle de vie.

Voici la liste des phases de construction:

• valider - valider que le projet est correct et que toutes les informations nécessaires sont disponibles
• compile - compile le code source du projet
• test - testez le code source compilé à l'aide d'un cadre de test unitaire approprié. Ces tests ne devraient pas exiger que le code soit empaqueté ou déployé
• package - prenez le code compilé et empaquetez-le dans son format distribuable, tel qu'un JAR.
• vérifier - exécuter tous les contrôles des résultats des tests d'intégration pour s'assurer que les critères de qualité sont respectés
• install - installe le package dans le référentiel local, pour une utilisation en tant que dépendance dans d'autres projets localement
• deploy - fait dans l'environnement de construction, copie le package final dans le référentiel distant pour le partager avec d'autres développeurs et projets.

Je peux exécuter la commande ci-dessous, pour compiler le code source, les tests unitaires et même empaqueter l'application dans un fichier war:

paquet propre mvn

Vous pouvez également décomposer votre tâche de construction en plusieurs étapes de construction. Cela facilite l'organisation des builds en étapes propres et séparées.

qu'est-ce que les données en science

Nous allons donc commencer par compiler le code source. Dans l'onglet build, cliquez sur invoquer les cibles maven de niveau supérieur et tapez la commande ci-dessous:

compiler

Considérez la capture d'écran ci-dessous:

Cela extraira le code source du référentiel GitHub et le compilera également (phase de compilation Maven).

Cliquez sur Enregistrer et exécutez le projet.

Maintenant, cliquez sur la sortie de la console pour voir le résultat.

Étape - 2 tests unitaires:

Nous allons maintenant créer un autre projet Freestyle pour les tests unitaires.

Ajoutez la même URL de référentiel dans l'onglet de gestion du code source, comme nous l'avons fait dans le travail précédent.

Maintenant, dans l'onglet «Buid Trigger», cliquez sur «construire après la construction d'autres projets». Tapez le nom du projet précédent dans lequel nous compilons le code source et vous pouvez sélectionner l'une des options ci-dessous:

• Déclencher uniquement si la construction est stable
• Déclenchement même si la construction est instable
• Déclencher même si la construction échoue

Je pense que les options ci-dessus sont assez explicites, alors sélectionnez-en une. Considérez la capture d'écran ci-dessous:

Dans l'onglet Build, cliquez sur invoquer les cibles maven de niveau supérieur et utilisez la commande ci-dessous:

tester

Jenkins fait également un excellent travail pour vous aider à afficher vos résultats de test et les tendances des résultats de test.

La norme de facto pour les rapports de test dans le monde Java est un format XML utilisé par JUnit. Ce format est également utilisé par de nombreux autres outils de test Java, tels que TestNG, Spock et Easyb. Jenkins comprend ce format, donc si votre build produit des résultats de test XML JUnit, Jenkins peut générer de jolis rapports de test graphiques et des statistiques sur les résultats de test au fil du temps, et vous permet également d'afficher les détails de tout échec de test. Jenkins garde également une trace de la durée d'exécution de vos tests, à la fois globalement et par test - cela peut être utile si vous avez besoin de dépister les problèmes de performances.

Donc, la prochaine chose que nous devons faire est d'amener Jenkins à garder un œil sur nos tests unitaires.

Accédez à la section Actions post-build et cochez la case «Publier le rapport de résultat du test JUnit». Lorsque Maven exécute des tests unitaires dans un projet, il génère automatiquement les rapports de test XML dans un répertoire appelé surefire-reports. Saisissez donc '** / target / surefire-reports / *. Xml' dans le champ 'Test report XMLs'. Les deux astérisques au début du chemin («**») sont une meilleure pratique pour rendre la configuration un peu plus robuste: ils permettent à Jenkins de trouver le répertoire cible quelle que soit la façon dont nous avons configuré Jenkins pour extraire le code source.

** / target / surefire-reports / *. xml

Enregistrez-le à nouveau et cliquez sur Construire maintenant.

Maintenant, le rapport JUnit est écrit dans / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Dans le tableau de bord Jenkinsvous pouvez également remarquer les résultats du test:

Étape - 3 Création d'un fichier WAR et déploiement sur le serveur Tomcat:

Maintenant, l'étape suivante consiste à empaqueter notre application dans un fichier WAR et à le déployer sur le serveur Tomcat pour le test d'acceptation de l'utilisateur.

Créez un autre projet freestyle et ajoutez l'URL du référentiel de code source.

Ensuite, dans l'onglet déclencheur de construction, sélectionnez construire lorsque d'autres projets sont construits, considérez la capture d'écran ci-dessous:

Fondamentalement, après le travail de test, la phase de déploiement démarre automatiquement.

Dans l'onglet de construction, sélectionnez le script shell. Tapez la commande ci-dessous pour empaqueter l'application dans un fichier WAR:

paquet mvn

L'étape suivante consiste à déployer ce fichier WAR sur le Tomcatserveur. Dans l'onglet «Actions post-construction», sélectionnez déployer war / ear dans un conteneur. Ici, donnez le chemin du fichier war et donnez le chemin du contexte. Considérez la capture d'écran ci-dessous:

Sélectionnez les informations d'identification Tomcat et notez la capture d'écran ci-dessus. Vous devez également fournir l'URL de votre serveur Tomcat.

Afin d'ajouter des informations d'identification dans Jenkins, cliquez sur l'option d'informations d'identification sur le tableau de bord Jenkins.

Cliquez sur Système et sélectionnez les informations d'identification globales.

Ensuite, vous trouverez une option pour ajouter les informations d'identification. Cliquez dessus et ajoutez des informations d'identification.

Ajoutez les informations d'identification Tomcat, considérez la capture d'écran ci-dessous.

Cliquez sur OK.

Maintenant, dans votre configuration de projet, ajoutez les informations d'identification Tomcat que vous avez insérées à l'étape précédente.

Cliquez sur Enregistrer, puis sélectionnez Construire maintenant.

Accédez à votre URL tomcat, avec le chemin du contexte, dans mon cas, c'est http: // localhost: 8081. Ajoutez maintenant le chemin de contexte à la fin, considérez la capture d'écran ci-dessous:

famille de colonnes cassandra vs table

Lien - http: // localhost: 8081 / gof

J'espère que vous avez compris la signification du chemin de contexte.

Maintenant, créez une vue de pipeline, considérez la capture d'écran ci-dessous:

Cliquez sur l'icône plus pour créer une nouvelle vue.

Configurez le pipeline comme vous le souhaitez, considérez la capture d'écran ci-dessous:

Je n'ai rien changé à part la sélection du poste initial. Mon pipeline démarrera donc à partir de la compilation. En fonction de la façon dont j'ai configuré d'autres travaux, après la compilation, les tests et le déploiement se produiront.

Enfin, vous pouvez tester le pipeline en cliquant sur RUN. Toutes les cinq minutes, s'il y a un changement dans le code source, tout le pipeline sera exécuté.

Nous sommes donc en mesure de déployer en continu notre application sur le serveur de test pour le test d'acceptation utilisateur (UAT).

J'espère que vous avez apprécié la lecture de cet article sur la livraison continue. Si vous avez des doutes, n'hésitez pas à les mettre dans la section commentaires ci-dessous et je vous répondrai au plus tôt.

Afin de construire des pipelines CI / CD, vous devez maîtriser une grande variété de compétences Maîtrisez les compétences DevOps requises maintenant