Directives clés de l'intégration continue et du serveur CI Jenkins

Points clés

• L'intégration continue (CI) et le serveur Jenkins CI sont des outils indispensables dans le développement de logiciels modernes, qui aident les équipes à publier des logiciels de meilleure qualité et à gagner du temps en automatisant des processus répétitifs.
• CI met l'accent sur l'automatisation des tests, permettant aux ingénieurs de test de se concentrer sur les tests exploratoires et les cas de bord tout en garantissant la qualité de chaque engagement sur une branche spécifique dans les minutes suivant la soumission du développeur.
• Jenkins CI Server est un outil CI open source qui peut être personnalisé avec les plug-ins existants ou en créant de nouveaux plug-ins. Il prend en charge la construction parallèle en attribuant des tâches sur plusieurs machines et en gérant l'intégration continue de projets dans divers langages, y compris Python.
• Alors que Jenkins nécessite plus de configuration et de maintenance, sa flexibilité et sa contrôlabilité, ainsi que ses fonctionnalités open source gratuites en font un choix puissant par rapport aux autres serveurs CI. Il s'intègre également bien à une variété de systèmes de contrôle de version, ce qui en fait un outil universel pour différents projets.

Cet article a été initialement publié sur TestProject - Test Automation Blog

Les éléments suivants introduiront en détail l'intégration continue (CI), une pratique essentielle dans le développement de logiciels, et Jenkins, l'outil d'intégration continue open source standard de l'industrie. En mettant en œuvre l'intégration continue et les serveurs CI Jenkins, vous apprendrez comment les déploiements Jenkins peuvent aider votre équipe de développement à publier un logiciel de meilleure qualité et à gagner un temps précieux.

---

Vous voulez en savoir plus sur Jenkins et l'intégration continue? Veuillez vérifier le lien suivant:

• Enregistrement d'écran: quels outils d'intégration continue prennent en charge Bitbucket?
• Préparer et construire des projets PHP dans Jenkins
• Intégration continue avec Jenkins
• Réintroduction Jenkins: tests automatisés à l'aide de pipelines
• Installation et protection Jenkins

---

Les pratiques de développement de logiciels modernes nécessitent le déploiement de logiciels entièrement fonctionnels dès que possible ou fréquemment dans les environnements de production. Par exemple, une approche agile applique ce comportement directement en faisant travailler l'équipe dans de petites incréments et en le déploiement dans un environnement de production après chaque sprint (Lire: Test Automation Strategies for Agile Projects).

L'équipe de développement a passé des mois à développer le logiciel, puis à le transmettre à QA, UAT et toutes les lignes de production n'existent plus. Aujourd'hui, l'accent est mis sur le fait d'avoir un logiciel entièrement fonctionnel et de ne jamais autoriser des situations qui mettent en danger la qualité des logiciels, comme l'introduction de changements de logiciels importants à la fin du cycle de version. C'est là que l'intégration continue entre en jeu.

Qu'est-ce que CI?

CI est une pratique qui applique des stratégies pour intégrer fréquemment le code testé dans des branches stables de projets. Je voudrais souligner le «code testé» en particulier, car cela signifie que la fonctionnalité développée sur des branches séparées est également testée et donc intégrée dans des branches stables.

Qui fait CI?

Habituellement, les ingénieurs DevOps sont généralement responsables de la configuration des pipelines CI. Aujourd'hui, le rôle des ingénieurs DevOps est très similaire à celui des ingénieurs de test, car les deux garantissent la qualité du processus et du logiciel. Je dis généralement que l'AQ et la production sont les intersections les plus proches des clients. En ce sens, CI fournit aux ingénieurs de test un outil très puissant pour améliorer la qualité globale des processus et des logiciels en participant activement dans les domaines suivants:

• Automatisation des tests: il y a quelques années, les gens ont discuté des tests manuels et des tests automatisés. Avec CI, l'automatisation des tests devient indispensable, ce qui économisera finalement beaucoup de temps précieux en se concentrant sur d'autres tâches de test. Il convient également de mentionner que les tests manuels et les tests automatisés ne peuvent pas être mutuellement exclusifs.
• Rapport de test: Pour les rapports de test dans CI, nous pouvons utiliser des solutions de rapport existantes ou créer nos propres modules de rapport. Dans les deux cas, cela montre clairement à quel point notre code d'application est dans chaque exécution de build. Il est important que tous les membres de l'équipe de développement aient accès à ces informations et continueront de travailler pour améliorer la qualité du code.
• Processus de déploiement: les ingénieurs de test sont davantage impliqués dans le processus de déploiement de l'application, qui fournit des informations supplémentaires sur l'architecture interne de l'outil d'automatisation des tests ou du cadre utilisé. Ces connaissances sont très importantes, en particulier lors de l'identification des problèmes d'application «cachés».

Avantages de CI

• CI met l'accent sur l'automatisation des tests, permettant aux ingénieurs de test de se concentrer sur les tests exploratoires, les tests de cas de bord et même la recherche de nouvelles méthodes de test.
• La qualité d'un engagement spécifique sur une branche spécifique apparaîtra dans les minutes suivant la soumission du développeur.
• Une fois le code testé sur la branche, il est très prudent de s'intégrer dans la branche stable (le processus CI devrait exécuter cette opération). Le déploiement de l'application sera automatiquement exécuté une fois correctement configuré, sans commandes répétées.
• Tous ces avantages augmentent de façon exponentielle du point de vue de l'équipe.

scénario CI typique

L'équipe de développement a son propre référentiel de contrôle de version de code source qui contient des projets (généralement GitHub aujourd'hui). Une branche stable (branche principale) est souvent considérée comme une branche de travail et développe rarement de nouvelles fonctionnalités directement sur la branche principale. Au lieu de cela, les développeurs créent leurs propres branches pour développer de nouvelles fonctionnalités (branche A de la fonctionnalité A). Lorsque des modifications sont poussées vers le référentiel sur cette branche particulière et que le développeur fait une demande de traction, un ensemble de tests de base (test de fumée) doit être effectué contre cette branche. Du point de vue CI, cela signifie généralement ce qui suit:

Lorsque le processus CI est terminé, il y a certaines exigences du point de vue des ingénieurs de test et des développeurs:

• testeur: retestez la fonction sur la branche A à nouveau
• Développeur: Un autre développeur effectue des avis de code par les pairs pour s'assurer que le code est d'une qualité suffisamment de bonne qualité
• Développeur: fusionnez manuellement le code à la branche principale et résolvez tous les conflits de fusion (si cela se produit).

Les tests de fumée gagnent beaucoup de temps pour les développeurs qui subiront des avis de code et des ingénieurs de test qui ont besoin de retester la fonctionnalité A sur la branche de la demande de traction. Si le test de fumée sur la demande de traction échoue, le développeur responsable de la fonction A est désormais responsable de la fixation de la fonction de test de fumée et de la publication d'une nouvelle demande de traction (jusqu'à ce que le problème soit résolu, le code problématique ne sera pas fusionné dans la branche principale ).

Si cela est fait et que le nouveau code de fonction A est fusionné dans la branche principale du point de vue de CI, ce qui suit se produira:

Cela indique que la fusion a réussi, la fonction de test de fumée est toujours valide, et maintenant il est de la responsabilité de l'ingénieur de test de retester la fonctionnalité sur la branche principale (pour s'assurer que la fusion n'a pas d'effets secondaires sur la fonction a). Bien sûr, c'est une bonne habitude d'améliorer la suite d'automatisation des tests au fil du temps pour couvrir la plupart des fonctionnalités.

Cela devient de plus en plus important dans les itérations tardives du projet, car l'ingénieur de test a plus de tâches (tester les fonctionnalités actuelles et toutes les fonctionnalités précédentes). C'est là que les tests de régression sont utiles: du point de vue du CI, l'exécution des tests de régression se produit généralement lorsque l'ingénieur de test exécute explicitement le test de régression ou lors de l'utilisation d'un planificateur (par exemple: effectuer des tests de régression tous les soirs). C'est une bonne habitude de personnaliser ce travail afin que nous puissions spécifier à quelle branche ce travail sera effectué (ici, vous pouvez en savoir plus sur les raisons pour lesquelles et quand effectuer l'automatisation des tests de régression). Le processus est le suivant:

Introduction aux outils Jenkins

Jenkins CI Server Terminology

Les devoirs: La plus importante "unité" de la terminologie de Jenkins est les devoirs. Un travail est une seule unité d'exécution dans un serveur Jenkins CI et doit avoir certains résultats (passer / échec). Par exemple: le travail peut être un travail de déploiement, un travail de test de fumée, un travail de test de régression, etc. Les emplois se composent de plusieurs zones exécutées en séquence, qui seront expliquées dans le paragraphe suivant: la structure des emplois de Jenkins.

Plugins: L'une des principales fonctionnalités de Jenkins Test Automation est la possibilité de le personnaliser en utilisant des plugins existants ou en créant vos propres plugins. Tout dans l'outil Jenkins, de la section de configuration du travail à la section de configuration Jenkins, est en fait un plug-in. En raison de la grande taille de la communauté de Jenkins, divers plugins Jenkins existent déjà pour répondre aux besoins des tâches de workflow CI les plus exigeantes. Cela signifie que vous rencontrerez probablement un plugin utile au lieu de créer une solution personnalisée.

NODE: Dans la configuration la plus simple, l'instance Jenkins s'exécutera sur une machine, où tous les travaux seront exécutés. Pour les petits tests et les petites quantités de missions, cela a du sens. Cependant, dans la pratique, il y a souvent des cas où plusieurs équipes utilisent la même instance Jenkins. Puisqu'ils ont un grand nombre d'emplois, il est considéré comme mauvais d'exécuter sur un cas pour les raisons suivantes: sécurité, reprise après sinistre, performance, évolutivité, etc.

Entrez Master / Slave dans Jenkins: le nœud maître Jenkins est uniquement utilisé pour planifier des travaux à exécuter sur l'esclave Jenkins. De cette façon, l'hôte Jenkins n'est pas fortement utilisé, et l'équipe a ses propres machines d'esclaves qui sont la meilleure taille pour leurs projets d'automatisation de test. De plus, le nœud esclave est ensuite configuré pour traiter plusieurs travaux parallèles à exécuter (nombre d'exécuteurs par nœud). Vous pouvez également configurer les nœuds à la demande d'AWS. Cela signifie que le nœud n'existe que lorsqu'un travail doit être exécuté dessus. Ceci est très utile car nous voulons des machines plus grandes qui ne seront entièrement utilisées que lors de l'exécution de tests de régression. Pour ce cas, une instance EC2 plus grande sera lancée sur AWS sur laquelle le travail sera exécuté et à la fin (en fonction du temps d'inactivité de la configuration), l'instance restera active pendant une période de temps. Après cela, il déterminera quelle approche est plus avantageuse lors de l'utilisation d'un service payant horaire, comme un service AWS.

Structure de Jenkins Job

Dans un serveur Jenkins CI, chaque travail Jenkins contient plusieurs parties:

• Général: Ici, nous spécifions le projet / nom de travail / description, ajoutez les paramètres du travail au besoin, définissons la stratégie de rotation du journal du travail, etc. L'écran suivant montre comment configurer la rotation du journal (vous pouvez spécifier le nombre de jours pour maintenir le journal de build ou le nombre de derniers journaux de construction à conserver), comment paramétrer le travail (en ajoutant la chaîne build_id avec la valeur par défaut de 0.0.1, cependant, ces valeurs peuvent être spécifiées lors du démarrage d'un travail) et comment configurer où ce travail sera exécuté (nom du nœud esclave):

  

  

• Jenkins Gestion du code source: Comme son nom l'indique, c'est là que nous définissons un référentiel de code source (tel que GitHub ou Subversion) dans un serveur Jenkins CI:

  

• Jenkins Build Trigger: Planifier le temps d'exécution du travail (périodiquement, après d'autres travaux, lorsque la demande de traction GitHub se produit, lorsque les modifications sont poussées vers GitHub, etc.).

  

• Jenkins Build Environment: Ici, nous définissons les options liées à l'environnement que la construction s'exécutera (supprimez l'espace de travail chaque fois que le travail est exécuté, interdit le travail s'il est suspendu pendant un certain temps ... etc.).

  

• Jenkins Build: Dans le serveur Jenkins CI, c'est l'étape la plus importante pour chaque travail. Le résultat de cette étape affecte l'état du travail à la fin de l'exécution. Selon les plug-ins installés, de nombreuses options sont disponibles, les plug-ins les plus couramment utilisés sont les suivants: exécuter le shell, exécuter des scripts Groovy, appeler des scripts Ant / Maven / Gradle, exécuter les commandes de lots Windows, etc.

  

  Il s'agit d'un exemple d'un plugin "Exécuter Shell" fréquemment utilisé qui est capable d'installer votre propre script de shell ou d'exécuter des scripts de shell existants.

• Jenkins Post-Build Operation: Cette partie du travail est utilisée pour signaler les résultats de l'emploi ou pour appeler d'autres emplois dans le pipeline Jenkins. D'une manière générale, nous pouvons envoyer des e-mails contenant le statut d'exécution du travail, publier des rapports HTML, Résultats Junit, publier des artefacts construits dans l'étape de construction vers S3, etc.

  

  Veuillez noter comment $ build_id est spécifié dans la ligne d'objet de l'e-mail. Étant donné que ce travail est paramétré, cette valeur est spécifiée lorsque le travail est démarré. Ce paramètre peut être utilisé dans la section des opérations de construction et post-construction Jenkins du travail.

Conclusion

Jusqu'à présent, vous avez appris les principaux avantages des serveurs Jenkins CI et comment CI lui-même est ajouté au processus de développement logiciel et aux ingénieurs de test. Comme toute autre technologie, il faut du temps pour maîtriser les bases et vivre les avantages. Je vous recommande fortement d'investir votre temps dans CI, ce qui en vaut vraiment la peine à long terme. En particulier, une fois Jenkins CI Server appliqué, de nombreux processus douloureux et répétitifs seront automatisés et vous aurez soudainement plus de temps pour vous concentrer sur l'amélioration des produits.

Votre équipe a-t-elle également implémenté l'intégration continue et les serveurs Jenkins CI? N'hésitez pas à partager l'expérience de votre équipe et à poser des questions dans les commentaires!

---

Cet article a été initialement publié sur TestProject - Test Automation Blog

FAQ sur l'intégration continue avec les serveurs Jenkins CI

Quelles sont les principales différences entre Jenkins et Travis CI?

Jenkins et Travis CI sont tous deux des outils d'intégration continue populaires, mais ils ont des différences clés. Jenkins est une solution auto-hébergée qui vous oblige à gérer et à maintenir vos propres serveurs. Il est hautement personnalisable et peut être configuré pour accueillir presque tous les flux de travail CI / CD. Travis CI, en revanche, est un service basé sur le cloud facile à configurer et à utiliser. Il s'intègre bien à GitHub et prend en charge de nombreuses langues hors de la boîte. Cependant, pour les flux de travail complexes, il peut ne pas être aussi flexible que Jenkins.

Comment Jenkins se compare-t-il à Gitlab CI / CD?

Jenkins et Gitlab CI / Cd offrent des solutions d'intégration continue puissantes. Jenkins est connu pour sa flexibilité et son grand écosystème de plugin, tandis que Gitlab CI / CD a reçu des éloges pour son intégration transparente avec l'écosystème de Gitlab. GitLab CI / CD fournit également un support Docker intégré, qui peut être un gros avantage pour les équipes utilisant Docker.

Quels sont les avantages de l'utilisation de Jenkins au lieu des autres serveurs CI?

Jenkins offre plusieurs avantages par rapport aux autres serveurs CI. Il est open source et possède une communauté importante et active, ce qui signifie qu'il s'améliore et la mise à jour constante. Il dispose également d'un énorme écosystème de plug-ins qui vous permet d'étendre ses capacités en fonction de vos besoins spécifiques. De plus, Jenkins prend en charge une variété de langues et d'outils, ce qui en fait un choix courant pour de nombreux projets différents.

Comment Jenkins gère-t-il l'intégration continue des projets Python?

Jenkins est un outil universel qui gère l'intégration continue des projets Python. Il automatise la construction, les tests et le déploiement d'applications Python et prend en charge de nombreux frameworks de test Python populaires. Jenkins intègre également bien les systèmes de contrôle de version comme GIT, ce qui facilite l'intégration dans votre flux de travail existant.

Quelles sont les principales considérations lors du choix entre Jenkins et Travis CI?

Lors du choix entre Jenkins et Travis CI, vous devez considérer des facteurs tels que l'expertise technique de l'équipe, la complexité de votre flux de travail CI / CD et le budget. Jenkins nécessite plus de configuration et de maintenance, mais offre une plus grande flexibilité et contrôle. Travis CI est plus facile à configurer et à utiliser, mais peut ne pas être suffisamment flexible pour les flux de travail complexes. Il s'agit également d'un service payant, et Jenkins est gratuit et open source.

Comment Jenkins prend-il en charge les pipelines CI / CD?

Jenkins prend en charge les pipelines CI / CD de l'intégration et des tests au déploiement en automatisant toutes les phases de la livraison de code. Il permet une rétroaction continue car les développeurs peuvent rapidement identifier et résoudre les problèmes dans leur code. Jenkins s'intègre également à une variété d'outils dans l'écosystème CI / CD, ce qui en fait un choix courant pour implémenter les pipelines CI / CD.

Jenkins peut-il être utilisé pour des projets qui ne sont pas hébergés sur GitHub?

Oui, Jenkins peut être utilisé pour des projets qui ne sont pas hébergés sur GitHub. Il prend en charge une variété de systèmes de contrôle de version, notamment la subversion, le mercuriel et les performances. Cela fait de Jenkins un choix universel pour les équipes utilisant différents systèmes de contrôle de version.

Comment Jenkins gère-t-il les constructions parallèles?

Jenkins gère les versions parallèles en allouant des tâches entre plusieurs machines ou exécuteurs. Cela permet des temps de construction plus rapides et une utilisation plus efficace des ressources. Vous pouvez configurer Jenkins pour gérer automatiquement votre infrastructure de construction ou spécifier manuellement les tâches devraient s'exécuter sur les machines.

Quels sont les défis courants que vous rencontrez lors de la configuration de Jenkins?

Certains défis courants lors de la configuration de Jenkins incluent la gestion des dépendances, la configuration des déclencheurs de construction et la configuration d'accès sécurisé. Cependant, Jenkins a une communauté importante et active, il existe donc beaucoup de ressources pour vous aider à surmonter ces défis.

Comment étendre la fonctionnalité de Jenkins?

Vous pouvez étendre les fonctionnalités de Jenkins en installant des plugins. Jenkins possède un énorme écosystème de plugins qui inclut des plugins pour une variété de fonctions, de l'intégration avec différents systèmes de contrôle de version aux interfaces utilisateur améliorées. Si vous avez besoin de fonctionnalités qui ne sont pas fournies par les plugins existants, vous pouvez également écrire vos propres plugins.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!