Qu’est-ce que l’intégration continue ?

L’intégration continue, l’offre en continu (CD, Continuous Delivery) et le déploiement continu sont tous des éléments essentiels du cycle de production d’un logiciel, processus DevOps y compris.

En règle générale, l’intégration continue est associée au développement logiciel agile, qui compile les tâches sur une liste et une feuille de route produit. Une fois définies, ces tâches sont affectées aux différents membres de l’équipe pour être effectuées. Les différents codes sont ensuite fusionnés dans un référentiel de code principal.

L’offre en continu est la deuxième phase du processus. Elle implique la création d’un package regroupant tout le code, prêt à être livré aux utilisateurs finaux. Cette étape du processus exploite généralement des outils automatisés qui génèrent un artefact, prêt à être déployé auprès des utilisateurs finaux à tout moment.

La dernière phase du processus, le déploiement continu, lance automatiquement le produit logiciel auprès des utilisateurs finaux. Cela implique que le produit a passé les étapes d’intégration et d’offre avec succès. L’automatisation utilise des scripts ou outils qui transfèrent le produit logiciel à des serveurs publics ou d’autres moyens de distribution publics. Dans un environnement hautement automatisé et bien géré, ces déploiements sont effectués automatiquement, dès la livraison du produit (d’où le terme « continu »). Certaines équipes ou certains produits peuvent être déployés à des heures spécifiques ou après la réalisation de divers processus et vérifications.

La minimisation de la « bureaucratie du code » peut aider les workflows DevOps et agiles à fonctionner correctement et efficacement, du développement du nouveau code à la toute fin du cycle. L’intégration continue peut aider une entreprise à évoluer lorsqu’elle supprime les dépendances qui entravent le développement de fonctionnalités individuelles. Même si un développeur travaille dans un silo, il sait que son travail sera intégré au reste du référentiel de code.

Des commentaires plus rapides sur les décisions commerciales aident les équipes produit à tester leurs idées et à mieux travailler avec une conception itérative de produit. Elles peuvent ainsi mettre en place des changements rapides, mesurés et réussis, et corriger plus efficacement les bogues.

Les équipes d’ingénierie échangent plus facilement et peuvent rendre des comptes, améliorant ainsi la communication au sein d’une équipe DevOps. Les équipes ont la possibilité de consulter et de commenter le code écrit par d’autres membres de l’équipe, ainsi que de collaborer avec d’autres développeurs sur du code écrit ultérieurement.

Le code est exécuté via un logiciel de contrôle de version, tel que Apache Subversion ou Git, et l’historique de validation du code logiciel est validé afin d’être changé si nécessaire.

Les développeurs élaborent leur code, puis celui-ci est transmis au système d’historique des versions. Il est ensuite renvoyé à la phase de création pour être compilé.

Le logiciel est soumis à des tests, notamment le test unitaire qui teste les unités de logiciel. La phase de simulation est lancée après un test réussi, qui signifie que le logiciel peut être déployé dans le processus de simulation. Le code y est affiché et finalisé avant la phase de test finale.

Une fois le logiciel passé dans l’environnement de simulation, il subit des tests automatisés préparés spécifiquement à cette fin. Après quoi, il est envoyé en phase de déploiement.

Une fois les tests automatisés effectués, le logiciel est déployé en production. En cas d’erreur pendant la phase de test ou de déploiement, le logiciel revient à la procédure de contrôle de version et est inspecté pour détecter d’éventuelles erreurs. Si des erreurs sont identifiées, elles sont corrigées.

Chaque artefact nécessaire à la création d’un projet doit être placé dans un référentiel de code central. Cette méthode permet d’utiliser des changements intégrés plutôt que des versions individuelles simultanées.

Idéalement, une commande unique doit pouvoir créer un système, y compris l’automatisation de l’intégration, qui se déploie dans un environnement similaire au produit. Dans de nombreux cas, le script compile les fichiers binaires tout en générant des pages Web, des supports de distribution, des statistiques et des pages de sites Web.

Chaque test doit être exécuté afin de confirmer que le logiciel se comporte comme prévu.

Le risque de changements conflictuels peut être considérablement réduit par des validations régulières. Des interactions quotidiennes aident les développeurs à identifier les problèmes ou les changements nécessaires dans le code, et à communiquer ces changements, le cas échéant. En accumulant une semaine entière de travail, ils peuvent passer à côté des erreurs ou celles-ci peuvent devenir extrêmement complexes. Des validations quotidiennes sont donc indispensables.

Les validations doivent être intégrées à la version fonctionnelle actuelle afin de vérifier qu’elles fonctionnent correctement. L’intégration continue automatisée (ACI, Automated Continuous Integration) est généralement utilisée, mais une intégration manuelle est également possible. L’ACI utilise un démon pour détecter des changements dans le système de contrôle de révision, puis exécute automatiquement le processus de création.

Chaque version doit être terminée aussi rapidement que possible pour éviter les soucis d’intégration ou pour identifier rapidement les problèmes.

Un environnement de test peut créer des échecs dans un système testé en cas de déploiement dans un environnement de production. La configuration d’un clone de l’environnement de production peut prévenir les échecs, car celui-ci peut être différent de l’environnement de test. Un environnement de simulation distinct est une version évolutive qui utilise des compositions de piles technologiques tout en réduisant les coûts.

Les parties prenantes et les testeurs peuvent avoir besoin de consulter le travail effectué. Il est donc préférable d’avoir les versions à disposition afin de réduire le nombre de révisions nécessaires si une fonctionnalité a besoin d’être retravaillée. Les tests précoces peuvent également éliminer le risque d’erreurs à un stade avancé du processus.

L’échec d’une version est généralement facile à trouver. L’intégration continue aide une équipe à identifier les changements apportés et le collaborateur qui en est l’auteur pour plus de transparence et une meilleure productivité.

Une fois qu’une version est terminée, la plupart des systèmes CI exécutent des scripts. Il est possible d’écrire un script afin de déployer l’application sur un serveur de test actif auquel tout le monde a accès. L’intégration continue sert à déployer les logiciels en production avec une automatisation supplémentaire pour éviter tout défaut ou régression.

Il est conseillé de développer et d’améliorer en permanence la portée des tests une fois qu’un projet est établi dans le pipeline CI. Des tests doivent accompagner chaque nouvelle fonctionnalité intégrée au pipeline CI pour vérifier que le nouveau code fonctionne comme prévu.

Les demandes de type « pull requests » sont un élément essentiel de l’intégration continue : la plupart des développeurs suivent un processus de pull request et de revue de code. Une demande de ce type est un excellent point de départ pour le pipeline CI. Elle permet de suivre les étapes d’approbation automatisée. Une approbation manuelle est également ajoutée lors d’une pull request, quand un collaborateur qui n’est pas une partie prenante peut effectuer une revue du code. Il peut ainsi identifier les modifications, ou approuver ou refuser la demande.

L’optimisation de la vitesse d’exécution du pipeline CI est cruciale, car il s’agit d’un processus souvent utilisé. Un retard dans le workflow peut aggraver les problèmes lors de l’augmentation des versions de fonctionnalités, de la taille du codebase et de la taille des équipes. Mesurez en permanence le pipeline CI pour contrôler son optimisation.

Un pipeline CI plus rapide entraîne une boucle de commentaires CI plus rapide. Les développeurs ont alors la possibilité d’apporter des changements et de faire des essais d’expérience utilisateur, de corriger rapidement les bogues et d’augmenter la vitesse d’exécution pour bénéficier d’avantages concurrentiels et d’une meilleure qualité.

Vous pouvez utiliser l’approche CI/CD en créant des applications sur la plateforme ServiceNow. Vous pouvez également connecter vos outils CI/CD au produit DevOps de ServiceNow pour associer le travail qui passe par le pipeline CI/CD au travail géré dans ServiceNow. Le produit ServiceNow DevOps apporte de nombreux avantages au processus CI/CD, que vous travailliez sur la plateforme ServiceNow ou sur des outils tels qu’Azure DevOps, GitLab ou Jenkins.

Gérez efficacement les changements de code pour plusieurs développeurs si vous utilisez l’intégration de référentiel Git, et associez des éléments de travail tels que les stories d’utilisateurs et les validations dans le référentiel. En associant également les validations aux résultats des tests et aux changements dans ServiceNow, vous obtenez une vue de bout en bout du pipeline.

Automatisez la création, l’approbation et le déploiement des changements et passez plus efficacement du développement aux tests, puis à la production.

Livrez des applications plus rapidement pour aider vos équipes à produire des itérations en fonction des commentaires plus tôt et plus souvent.

Créez des rapports sur l’ensemble du pipeline ou du flux de valeur, de la conceptualisation à la production. Communiquez avec plusieurs équipes, comparez les performances de différents outils et identifiez et résolvez les goulots d’étranglement.