Marcher avant de courir : Comprendre l’intégration continue dans le développement continu

Avec le buzz autour Livraison continu (CD) De nos jours, parler de cela, et encore moins écrire à ce sujet, peut sembler une notion désuète. Intégration continue (CI). Cependant, lors de nos nombreux échanges avec des organisations souhaitant mettre en œuvre l'intégration continue (CI) ou en pleine mise en œuvre (et rencontrant des difficultés), il est apparu clairement qu'un fossé important subsiste quant aux fondements qui sous-tendent la volonté d'une organisation d'adopter la CI. L'intégration continue est un élément clé dont les principes ne sont toujours pas compris ni mis en œuvre avec suffisamment de clarté, et mérite donc d'être réexaminé.

Continu…

Intégration : est le processus permettant d'obtenir un retour d'information rapide et automatisé sur le exactitude de votre application à chaque modification du code.

Livraison s'appuie sur le concept précédent en fournissant un retour d'information rapide et automatisé sur le exactitude et préparation à la production de votre application à chaque modification apportée à code, infrastructure ou configuration.

Le principe du déploiement continu (CD) repose sur l'idée que les logiciels sont toujours déployables. Tiens, ça ne vous rappelle rien ? Quelqu'un a-t-il jeté un œil aux principes du Manifeste Agile récemment ? Le tout premier principe stipule :

« Notre priorité absolue est de satisfaire le client – ​​grâce à une prise en charge rapide et efficace. » livraison continue – de logiciels précieux.

Il semble que le CD soit moins une idée novatrice que la concrétisation d'une promesse de longue date. Et les conditions préalables essentielles à la réalisation de cet idéal sont les suivantes :

• Intégration continue
• Gestion complète de la configuration
• Tests automatisés multiniveaux

Le reste de l'article approfondit un peu plus l'aspect CI du CD.

Intégration continue

L'intégration continue (CI) est le processus d'exécution de la compilation logicielle.Deploy- Cycle de test (BDT) fréquent avec une intervention manuelle minimale, reposant sur une communication et un retour d'information constants entre les membres de l'équipe. Martin Fowler, auteur et conférencier reconnu dans le domaine du développement logiciel, le décrit ainsi :

« …une pratique de développement logiciel où les membres d’une équipe intègrent fréquemment leur travail, généralement au moins une fois par jour, ce qui conduit à plusieurs intégrations quotidiennes. Chaque intégration est vérifiée par une compilation automatisée (incluant des tests) afin de détecter les erreurs d’intégration le plus rapidement possible. De nombreuses équipes constatent que cette approche réduit considérablement les problèmes d’intégration et permet de développer plus rapidement un logiciel cohérent. »

Si ça fait mal, exprimez la douleur.

L'intégration continue (CI) offre un cadre pour détecter rapidement les erreurs d'intégration logicielle, permettant aux équipes de développer plus rapidement des logiciels unifiés tout en atténuant les redoutables intégrations « big bang » et les difficultés de fusion de code qui en découlent et qui affectent de nombreuses équipes de développement. La CI vise à éliminer l'incertitude liée à l'intégration en encourageant les développeurs à intégrer fréquemment leur travail dans leurs activités quotidiennes. Elle ne supprime pas la complexité de la fusion de code et de la résolution des conflits, mais elle réduit considérablement les difficultés associées aux fusions peu fréquentes en exigeant des fusions incrémentales quotidiennes. Elle permet de gagner du temps et d'éviter des difficultés ultérieures.

En quoi cela change-t-il le travail quotidien du développeur ?

L'intégration continue (CI) est avant tout un état d'esprit. Bien que le processus puisse être mis en œuvre manuellement, la plupart des équipes utilisent un outil pour garantir le respect de cette discipline. La figure ci-dessous illustre le cycle d'intégration typique dans le contexte de l'utilisation d'un tel outil – un serveur CI – pour faciliter la mise en œuvre de cette pratique.

• La journée commence par la récupération, par le développeur, de la dernière version du code source depuis le dépôt de contrôle de version.
• Vient ensuite l'activité de développement classique (de préférence guidée par des tests unitaires automatisés).
• Le développeur est prêt à intégrer du code dans le dépôt et pourrait avoir besoin de communiquer son intention à l'équipe.
• Met à jour la copie de travail locale avec le code provenant du dépôt (car d'autres personnes ont pu mettre à jour le flux de code).
• Fusionne le code et résout les conflits localement.
• Génère et s'assure que les tests réussissent localement
• Insère du code dans le dépôt
• Le serveur d'intégration continue (CI) surveille les modifications apportées au dépôt de code. Chaque modification déclenche automatiquement le cycle de compilation et de test, et les résultats sont communiqués automatiquement aux membres de l'équipe. Une compilation défaillante (erreur de compilation ou de test) indique un problème d'intégration et doit être résolue immédiatement. Rendre l'environnement CI opérationnel doit devenir la priorité absolue des développeurs et de l'équipe.

Vous vous demandez par où commencer ?

Comme le montre la description du cycle d'intégration, l'adoption de l'intégration continue impose certaines pratiques nécessaires pour rendre l'intégration continue possible et efficace.

Référentiel à source unique

Tous les fichiers de code source, scripts de base de données, bibliothèques dépendantes et fichiers de propriétés nécessaires à la génération des artefacts logiciels déployables doivent être versionnés dans un système de contrôle de version, car le serveur d'intégration continue surveille les modifications apportées au dépôt de code pour déclencher le cycle BDT. Aussi élémentaire que puisse paraître cette contrainte, certaines organisations n'ont pas encore atteint le niveau de maturité où la gestion centralisée du contrôle de version est une évidence.

Construire l'automatisation

Même avec un système de contrôle de version centralisé, de nombreuses organisations s'appuient encore sur des processus manuels pour créer des artefacts logiciels déployables, ce qui implique une coordination entre les différents services et les membres des équipes. L'intégration continue (CI) étant de lancer une compilation sans intervention humaine, il est nécessaire de créer une fonctionnalité de compilation en un clic afin d'automatiser le cycle de développement logiciel (BDT). La règle d'or de l'automatisation des compilations est de pouvoir mettre en place un système fonctionnel à partir de zéro.

Test Automation

Bien que ce ne soit pas une condition préalable, automatisation des tests L'automatisation des tests joue un rôle essentiel en fournissant à l'équipe un retour d'information fiable, confirmant que les composants logiciels sont non seulement intégrés, mais aussi fonctionnels. Ne laissez pas l'automatisation des tests freiner votre transition vers l'intégration continue (CI), mais il est préférable de ne pas trop tarder à intégrer les tests automatisés afin d'en tirer pleinement parti.

Quelles sont quelques-unes des « meilleures pratiques » ?

•  Des commits fréquents sur un flux de code commun
• Interdire les commits dans une version « défectueuse »
• Une configuration défaillante sur l'intégration continue doit être prise en charge immédiatement et sa résolution doit être la priorité absolue.
• Gérez les processus de compilation longs. Une durée de 10 à 15 minutes est idéale ; au-delà de 20 à 30 minutes, il est déconseillé de procéder à une intégration fréquente et efficace. Plus le cycle est court, mieux c'est. La cause la plus probable est la présence de tests d'intégration confondus avec des tests unitaires. Mettez les compilations en scène si nécessaire.
• Reconstruire la base de données (reconstruire à partir de zéro)
• Créer, déployer et tester sur une plateforme de type production
• Fournir aux équipes d'assurance qualité la possibilité de déployer des versions ciblées dans des environnements de niveau supérieur.

Quelles sont certaines des idées fausses les plus répandues ?

L'intégration continue est identique à la version nocturne.

C'est faux. Une compilation nocturne produit des artefacts logiciels destinés à une utilisation externe, comme les tests fonctionnels d'assurance qualité, les revues de produit, etc. XP a poussé le concept de compilation nocturne à l'extrême en suggérant des points de contrôle fréquents de synchronisation du code au cours de la journée. Ces points de contrôle permettent aux développeurs d'interagir avec le système et de s'assurer d'avoir bien effectué leur travail, du moins provisoirement. Cela ne signifie pas pour autant que la compilation nocturne est inutile ; l'intégration continue (CI) pourrait d'ailleurs être utilisée pour la générer de manière progressive.

Nous ne sommes pas agiles, donc nous ne pratiquons pas l'intégration continue.

Bien que le terme « intégration continue » ait été introduit par la programmation extrême (XP), le concept sous-jacent d’une intégration plus fréquente est antérieur à XP. En réalité, l’intégration continue est l’une des pratiques les moins controversées de XP et ses principes directeurs restent pertinents, qu’une organisation ait adopté ou non les méthodes agiles.

Fréquent Deployment perturbateur

L'adoption de l'intégration continue (CI) n'implique pas nécessairement le déploiement automatique de chaque build validé dans les environnements de niveau supérieur, qu'il soit demandé ou non. Une bonne implémentation de CI doit permettre aux équipes d'assurance qualité et autres membres de l'équipe de déployer des builds ciblés sur le serveur de CI dans d'autres environnements, selon les besoins.

Dans l' L'automatisation au service du peuple Dans cette série, Paul Duvall recense certains écueils et idées reçues courants en matière d'intégration continue et explique comment les éviter.

Conclusion

Le principal avantage de l'intégration continue (CI) réside dans la réduction des risques. Trop souvent, les problèmes liés à une intégration tardive et peu fréquente se manifestent en fin de projet, lorsque les enjeux sont importants et la pression pour livrer est maximale. De plus, elle ouvre la voie à l'automatisation à de nombreux niveaux, à commencer par l'automatisation de la compilation, l'automatisation des tests et, plus récemment, la livraison et le déploiement continus, autant d'éléments qui visent à favoriser la création de logiciel de meilleure qualité, plus rapide.

Références

• http://martinfowler.com/articles/continuousIntegration.html
• http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html
• Intégration continue : améliorer la qualité des logiciels et réduire les risques – Duvall, P., Matyas, S. et Glover, A.
• Livraison continue : Logiciel fiable Releases à travers la construction, les tests et DeployAutomatisation des processus – Humble, J. et Farlay, D.