Dans ce guide, vous allez découvrir tout ce qui concerne l’intégration continue, sa liaison au déploiement continu et à la livraison continue, et comment débuter avec ces pratiques. Puis, nous allons voir plus de détails sur les meilleures pratiques et les flux de travail (workflows).
Qu’est-ce que l’intégration continue ?
L’intégration continue (CI) est une pratique de développement où les développeurs intègrent fréquemment du code dans un référentiel partagé, de préférence plusieurs fois par jour.
Chaque intégration peut ensuite être vérifiée par un build automatisé et des tests automatisés. Bien que les tests automatisés ne fassent pas strictement partie de CI, ils sont généralement implicites.
L’un des principaux avantages d’intégrer régulièrement est que vous pouvez détecter rapidement les erreurs et les localiser plus facilement. Puisqu’il y a moins de modification introduite, il est possible d’identifier rapidement la modification spécifique qui est à la source d’un problème.
Ces dernières années, CI est devenue une meilleure pratique pour le développement de logiciels. Elle est guidée par un ensemble de principes fondamentaux. Parmi eux, il y a le contrôle des révisions, le build automatisé et les tests automatisés.
En plus, le déploiement continu et la livraison continue ont été développés comme meilleures pratiques pour garder votre application déployable à tout moment.
Ils peuvent même pousser votre base de code principale en production de manière automatique chaque fois que de nouvelles modifications y sont apportées. En effet, cela permet à votre équipe d’avancer rapidement tout en respectant des normes de qualité élevées qui peuvent être vérifiées automatiquement.
Quelle est la différence entre l’intégration continue, le déploiement continu et la livraison continue ?
Intégration continue
C’est la pratique d’intégrer les modifications de différents développeurs de l’équipe dans une ligne principale. Cela se fait dès que possible, dans le meilleur des cas plusieurs fois par jour.
Cela garantit que le code sur lequel travaillent les développeurs n’est pas vraiment perturbé. Lorsque vous combinez le processus avec des tests automatisés, l’intégration continue peut permettre à votre code d’être fiable.
Déploiement continu
Il est étroitement lié à l’intégration continue. Le déploiement continu permet de maintenir votre application déployable à tout moment. Il permet même de la publier automatiquement dans un environnement de test ou de production si la dernière version réussit tous les tests automatisés.
Livraison continue
C’est la pratique de garder votre base de code déployable à tout moment.
Elle vous assure que votre application passe des tests automatisés. Pour cela, elle doit avoir toute la configuration nécessaire pour la pousser en production.
De nombreuses équipes effectuent ensuite des modifications qui réussissent immédiatement les tests automatisés dans un environnement de test ou de production. Cela garantit une boucle de développement rapide.
Partie 1 : Guide du débutant pour l’intégration continue
Vous devez vous concentrer sur la mise en place d’un simple processus d’intégration continue le plus tôt possible. Mais, il ne faut pas vous arrêter là.
Même si l’intégration continue (CI) est importante, ce n’est que la première étape du processus. Vous devez également configurer le déploiement continu (CD), le flux de travail qui automatise votre déploiement de logiciels. Cela vous permet en effet de vous concentrer sur la création de votre produit.
Intégration continue (CI) vs déploiement continu (CD)
Comme nous l’avons souligné précédemment, le déploiement continu est étroitement lié à l’intégration continue. Il se réfère surtout au maintien de votre application déployable à tout moment voire à sa mise en production automatique si la dernière version réussit tous les tests automatisés.
Si vous voulez lancer votre produit très rapidement, vous devez automatiser l’ensemble de votre flux de travail, pas seulement les tests.
Avoir une solution de déploiement continu (CD) bien conçue et fonctionnant correctement sera le lien entre les outils que vous utilisez.
C’est particulièrement le cas entre le fournisseur/serveur SCM (Source Control Management) et l’environnement d’hébergement que vous utilisez. Cela vous permettra également d’intégrer de nouvelles personnes et de développer votre équipe. En effet, elles peuvent compter sur un processus entièrement automatisé dès le premier jour.
Quel est le meilleur outil ou service d’intégration et de déploiement continus ? Comment choisir entre ces outils ?
Il existe de nombreuses solutions. Si vous voulez juste obtenir une liste d’outils, vous pouvez consulter Codeship, TravisCI, SemaphoreCI, CircleCI, Jenkins, Bamboo, Teamcity ou bien d’autres.
Vous pouvez aussi trouver de nombreux articles et forums sur le sujet avec des informations précieuses comme celle-ci sur Quora. Il y a plusieurs possibilités. Mais, la question se pose : « Comment choisir entre ces outils ? »
Votre choix dépendra fortement :
- de vos besoins,
- de la stack technique que vous avez et ;
- de la façon dont vous gérez votre flux de travail quotidien.
Comme le souligne Moritz Plassnig, PDG de Codeship, sur Quora : « En général, il est important de soulever d’abord quelques questions simples et d’y répondre avant de choisir une solution. Cela vous aidera à trouver la solution qui vous conviendra le mieux. »
- https://stackshare.io/codeship
- https://www.g2crowd.com/products/codeship/reviews
- https://www.quora.com/Reviews-of-Codeship-Software/
Solutions hébergées vs solutions non hébergées
L’une des premières décisions que vous devez prendre est de savoir si vous avez besoin d’une solution SaaS (Software-as-a-Service) hébergée ou une solution auto-hébergée.
Si vous préférez une solution auto-hébergée, vous devez administrer votre propre serveur. La solution SaaS n’a pas besoin de ça. Mais, elle pourrait être plus limitative si vous avez besoin de certaines fonctionnalités edge cases.
Si vous utilisez GitHub, Bitbucket, Heroku ou d’autres services cloud, vous devriez sans doute avoir une solution SaaS, car elle s’adaptera à votre flux de travail déjà existant.
Si la sécurité des données est très importante, un serveur auto-hébergé pourrait être le meilleur choix pour vous. En général, les solutions SaaS vous permettent de vous concentrer davantage sur votre produit principal.
En d’autres termes, vous n’avez pas à consacrer du temps à la maintenance de votre infrastructure et à la mise à jour de toutes les dépendances à un prix raisonnable.
Test des logiciels open source et propriétaires
Si vous avez des projets open source, vous pouvez les tester avec les deux solutions : hébergée et non hébergée.
Elles ont chacune leurs avantages et leurs inconvénients. Comme mentionnée ci-dessus, une solution hébergée (SaaS) n’a pas besoin de maintenance des serveurs de votre côté, ce qui vous laisse plus de temps pour travailler/coder sur votre produit.
La plupart des solutions SaaS suivent le modèle GitHub et vous pouvez tester vos projets open source gratuitement. Quoi qu’il en soit, certains projets open source ont besoin de beaucoup de contrôles sur l’infrastructure build. Cela est à cause qu’ils peuvent tester des parties d’un système d’exploitation non accessibles dans une solution hébergée.
Dans ce cas, tous les serveurs CI open source existants devraient faire du bon travail, bien qu’avec du frais supplémentaire pour la maintenance nécessaire.
Les avantages de l’intégration et du déploiement continus
L’intégration continue présente de nombreux avantages.
Tout d’abord, une bonne configuration CI accélère votre flux de travail. Elle encourage aussi l’équipe à apporter des modifications sans avoir peur de casser quoi que ce soit. Il y a plus d’avantages que de travailler simplement avec un meilleur processus de release de logiciel.
L’intégration continue apporte également de grands avantages commerciaux.
Réduit les risques
Si vous testez et déployez du code plus fréquemment, CI réduira éventuellement le niveau de risque du projet sur lequel vous travaillez.
En effet, vous pourrez détecter plus tôt les bogues et les codes défauts. Cela signifie qu’ils sont plus faciles à corriger. Puis, vous pouvez le faire le plus tôt possible, ce qui les rend moins coûteux.
Cela va accélérer ainsi le mécanisme de retour d’utilisateurs et rendra votre communication beaucoup plus fluide, comme mentionné dans cet article par Darragh Curran d’Intercom : le lancement est le cœur de votre entreprise.
Meilleure communication
Lorsque vous avez mis en place un processus CI qui est connecté à un flux de travail de livraison continue, il est facile de partager votre code régulièrement.
Ce partage de code permet en effet de gagner en visibilité et en collaboration entre les membres de l’équipe. Puis, cela améliore la vitesse de communication et augmente l’efficacité au sein de votre entreprise étant donné que tout le monde est toujours sur la même longueur d’onde.
Itérations plus rapides
Comme vous publiez souvent du code, il y aura moins d’écart entre l’application en production et celle sur laquelle le développeur travaille.
En effet, votre façon de penser à développer des fonctionnalités va sans doute changer. Toutes petites modifications seront testées automatiquement. Votre équipe sera au courant de ces changements. C’est pourquoi vous devez travailler sur de petites modifications incrémentielles lors du développement de nouvelles fonctionnalités.
Cela se traduit par moins d’hypothèses car vous pouvez créer des fonctionnalités plus rapidement et les tester. Puis, vous pouvez les déployer automatiquement pour que vos utilisateurs les voient le plus tôt possible. Vous obtenez ainsi et plus rapidement des commentaires précieux de leur part.
Retour d’information plus rapide sur les décisions commerciales
Avoir un processus CI est non seulement bénéfique pour les développeurs de logiciels, mais aussi pour leurs gestionnaires.
Les deux parties peuvent recueillir des commentaires précieux et obtenir des informations beaucoup plus rapidement. En poussant le code plus souvent, vous avez plus de données que vous pouvez analyser pour vérifier si le produit avance dans la bonne direction.
Ce flux de données continu et la timeline des métriques (comme la dépendance, les tests unitaires, la complexité et le code smell) peuvent également aider à réfléchir plus fréquemment à l’avancement du projet. Ce qui permet de trouver des décisions technologiques et commerciales plus rapides.
Quelques autres avantages de l’utilisation de CI et CD
- Réduit les frais dans le processus de développement et de déploiement
- Réduit le temps et les efforts pour intégrer les différentes modifications de code
- Permet un mécanisme de retour d’utilisateurs rapide sur chaque modification
- Permet une détection et une prévention des défauts le plus tôt que possible
- Aide à la collaboration entre les membres de l’équipe afin que le code récent soit toujours partagé
- Réduit l’effort de test manuel
- Construire des fonctionnalités de manière plus incrémentale permet de gagner du temps du côté du débogage. Vous pouvez ainsi vous concentrer sur l’ajout de fonctionnalités
- Première étape de l’automatisation complète de l’ensemble du processus de release
- Empêche la divergence dans les différentes branches car elles sont intégrées régulièrement
- Si vous travaillez sur une fonctionnalité de longue durée, vous pouvez continuer à intégrer mais retenir la release avec des indicateurs de fonctionnalité.
Partie 2 : Mieux comprendre l’intégration continue et la livraison continue
Si vous êtes intéressé par les tutoriels d’intégration continue et les meilleures pratiques, nous vous conseillons de consulter certains des blogs très intéressants mentionnés ci-dessous. Vous pouvez sans doute y trouver du contenu très utile.
Les concepts CI et CD ont changé et rapidement évolué depuis 2006. Néanmoins, cela vaut la peine de jeter un coup d’œil aux principes originaux de l’intégration continue de Martin Fowler. Martin explique les meilleures pratiques en matière de workflow :
- Gérez un référentiel de code
- Automatisez votre build
- Faites le test automatisé de votre build
- Engagez tous les membres de l’équipe chaque jour à l’objectif
- Chaque engagement (à l’objectif) doit être construit
- Gardez vos builds rapides
- Clonez l’environnement de production et testez-y
- Facilitez l’obtention des derniers livrables
- Tout le monde dans l’équipe peut voir les résultats de votre dernier build
- Automatisez le déploiement de build
La CI a bien fait de permettre tout ceci et les équipes logicielles sont largement capables de travailler avec ces principes à l’esprit. Avec l’émergence des conteneurs, il est désormais beaucoup plus facile de cloner votre environnement local et de production, puis d’y tester. La nouvelle plateforme Docker de Codeship vous aidera à le faire et bien plus encore.
Checklist de livraison continue
Les principes de Martin Fowler sont un excellent point de départ pour réfléchir à la meilleure configuration de votre processus de développement logiciel. Jez Humble et David Farley soulignent également dans leur livre « Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation » que la liste suivante est un aperçu et une checklist générale lorsque vous voulez soumettre du code.
- Avant de soumettre des modifications, vérifiez si l’état d’un build est actuellement « Réussi ». Sinon, vous devez corriger un build avant de soumettre un nouveau code.
- Si l’état est actuellement « Réussi », vous devez re-baser votre espace de travail personnel à cette configuration.
- Construisez et testez localement pour vous assurer que la mise à jour ne casse pas les fonctionnalités.
- En cas de succès, enregistrez le nouveau code.
- Autorisez CI à terminer de nouvelles modifications.
- Si le build échoue, alors arrêtez et réparez votre machine. Revenez à l’étape 3.
- Si le build réussit, continuez à travailler sur l’élément suivant.
Vous devez noter qu’il ne s’agit que d’un aperçu général. Vous pouvez trouver de nombreux services et solutions qui ne suivent pas ces étapes exactes (comme l’étape 2). Quoi qu’il en soit, il est bon de connaître ces étapes. Pourquoi ?
Vérifier la maturité de la livraison continue
Parce que de nombreux développeurs (selon les recherches de DZone en 2014, jusqu’à 41 %) croient qu’ils ont fait la livraison continue, alors qu’en fait moins de 10 % d’entre eux le font réellement.
L’enquête a été menée auprès de plus de 500 professionnels de l’informatique. La plupart des répondants étaient des développeurs (68 %) ou des chefs d’équipe (14 %), avec quelques équipes opérationnelles, AQ et représentants de la direction exécutive. La majorité des répondants étaient basées aux États-Unis (36 %) ou en Europe (43 %).)
Moins de 10 % de ces personnes travaillent réellement avec la livraison continue. Il faut bien le comprendre. C’est l’une des raisons pour lesquelles il est bon de nous rappeler que nous devons nous rapprocher de la vraie livraison continue.
Une bonne checklist aide sans doute à mettre en place le bon processus et à l’expliquer à votre équipe et, éventuellement, à la direction.
C’est l’une des raisons pour lesquelles DZone, la société responsable des recherches, a élaboré une liste de contrôle. Dans la checklist pour la vérification de la maturité de la livraison continue, vous pouvez réellement vérifier les pratiques que vous effectuez actuellement pour voir à quel point vous êtes mature dans chaque domaine de la livraison continue.
Plus vous avez un score élevé au test, plus vous vous rapprochez de la maturité de la CD. La checklist est bonne à suivre lorsque vous codez. Puis, elle peut également vous aider à identifier les points faibles et les domaines à améliorer dans le processus CD de votre entreprise. Les principaux domaines du processus CD comprennent :
- Contrôle de source
- Processus de build
- Tests et questions/réponses
- Déploiement
- Visibilité
Une version antérieure de ce processus que vous devrez peut-être consulter a été introduite par Chris Shayan. Ce dernier a écrit sur la matrice de maturité de la livraison continue, cliquez ici pour plus de détails.
Comment débuter avec la livraison continue ?
Si vous vous demandez comment débuter avec la livraison continue, cet article de notre directeur technique Florian Motlik sur le blog Amazon Web Services vous sera très utile : cinq conseils pour commencer avec la livraison continue.
Si vous êtes prêt à essayer l’intégration et la livraison continues dans vos projets, n’hésitez pas à vous inscrire à un compte Codeship gratuit dès aujourd’hui ! Connectez-vous simplement via votre GitHub, BitBucket ou GitLab.