Bonnes pratiques CI/CD

S'assurer que tout votre code source, vos fichiers de configuration, vos scripts, vos bibliothèques et vos exécutables sont dans le contrôle de code source est une première étape essentielle vers l'implémentation d'une intégration continue, vous permettant de garder une trace de chaque modification.

Cependant, l'outil seul ne suffit pas - c'est la façon dont vous l'utilisez qui compte. L'intégration continue vise à faciliter le processus d'intégration des modifications provenant de plusieurs contributeurs en partageant plus fréquemment de petites mises à jour.

Chaque commit déclenche une série de tests automatisés pour fournir un retour d'information rapide sur la modification. Les commits réguliers garantissent que votre équipe travaille sur les mêmes bases, facilitant ainsi la collaboration, et réduisent la probabilité d'importants conflits de fusion lors de l'intégration de modifications vastes et complexes.

Afin de profiter des avantages de l'intégration continue, il est essentiel pour chacun de partager ses modifications avec le reste de votre équipe en effectuant un push sur la branche principale (master) et d'actualiser la version sur laquelle il travaille afin de recevoir les modifications des autres. En règle générale, il faut faire un commit vers la branche principale (master) au moins une fois par jour.

Pousser aussi souvent des modifications sur la branche principale peut paraître inconfortable pour des équipes habituées à travailler dans des branches très longues. Cela peut être dû à la crainte du regard des autres ou peut-être parce que l'ampleur d'une tâche est trop importante pour qu'elle puisse être accomplie en une journée.

Il est essentiel de créer une culture d'équipe fondée sur la collaboration plutôt que sur le jugement et, comme pour toute modification des méthodes de travail, il est utile de discuter de la manière dont vous travaillez en équipe. Travailler en équipe afin de fractionner les tâches en petits blocs distincts peut aider les individus à adopter cette pratique.

Lorsque des branches en activité depuis longtemps sont utilisées pour héberger de nouvelles fonctionnalités qui ne sont pas prêtes à être lancées, une autre option consiste à utiliser des feature flags. Ceux-ci vous permettent de contrôler la visibilité d'une fonctionnalité donnée dans différents paramètres, de sorte que les modifications du code peuvent être fusionnées et incluses dans le build pour l'assurance qualité sans être disponibles pour les utilisateurs finaux.

En compilant la solution et en exécutant un ensemble de tests automatisés à chaque fois qu'une modification est engagée, un pipeline de CI/CD fournit un retour d'information rapide aux développeurs sur leurs modifications.

L'objectif est d'éviter de bâtir sur de mauvaises fondations et de maintenir le code dans un état constamment publiable. Non seulement il est beaucoup plus efficace de traiter les problèmes dès qu'ils surviennent, mais cela permet également de déployer rapidement un correctif si quelque chose ne va pas en production.

Si un build échoue pour une raison quelconque, la priorité de l'équipe doit être de le faire refonctionner. Il peut être tentant de blâmer celui qui a effectué la dernière modification et de lui laisser la tâche de régler le problème. Cependant, chercher à blâmer les membres de votre équipe produit rarement une culture d'équipe constructive et a moins de chances de révéler la cause sous-jacente d'un problème. En confiant à toute l'équipe la responsabilité de réparer un build défaillant et en essayant de comprendre ce qui a conduit à l'échec, vous pouvez améliorer l'ensemble du workflow de CI/CD. Bien sûr, cela peut être plus facile à dire qu'à faire quand la pression monte et que les tensions sont fortes. Faire évoluer une culture DevOps est aussi un exercice d'amélioration continue !

Bien sûr, il peut être frustrant de devoir tout laisser tomber pour réparer un build défaillant, pour finalement découvrir qu'il a été causé par quelque chose de trivial, comme une erreur de syntaxe ou une dépendance manquée. Pour éviter cela, il est bon que les membres de l'équipe procèdent à une compilation et à une première série de tests localement avant de partager leurs modifications. Idéalement, tout le monde devrait pouvoir utiliser les mêmes scripts que le système de CI/CD afin d'éviter la duplication des efforts. D'autre part, envisagez d'implémenter un outil de CI/CD dans votre organisation.

Une erreur courante consiste à créer un nouveau build pour chaque étape.

Reconstruire le code pour différents environnements risque d'introduire des incohérences et signifie que vous ne pouvez pas être sûr que tous les tests précédents ont réussi. Au lieu de cela, le même artefact de build doit être promu à travers chaque étape du pipeline de build et publié en production.

Pour mettre cela en pratique, il faut que le build ne dépende pas du système. Les variables, les paramètres d'authentification, les fichiers de configuration ou les scripts doivent être appelés par le script de déploiement plutôt que d'être incorporés dans le build lui-même. Cela permet de déployer le même build dans chaque paramètre pour le tester, chaque étape augmentant la confiance de l'équipe dans cet artefact de build spécifique.

Bien qu'il soit bon de tout conserver, y compris le script de build, les fichiers de configuration et les scripts de déploiement, dans le même système de contrôle de code source que le code de l'application, cela ne s'applique pas à l'artefact de build lui-même. Étant le produit de ces entrées, le build n'a pas sa place dans le contrôle de code source. Il devrait plutôt être versionné et stocké dans un référentiel central d'artefacts, tel que Nexus, d'où il peut être extrait et déployé dans chaque instance.

Bien que le CI/CD s'appuie fortement sur les tests automatisés pour assurer la confiance en la qualité de votre logiciel, cela ne signifie pas que vous devez viser à tester chaque éventualité.

Après tout, l'objectif de l'intégration continue est de fournir un retour d'information rapide et de fournir des produits de qualité aux utilisateurs à un rythme plus rapide que les méthodes traditionnelles. Cela signifie qu'il faut trouver un équilibre entre la couverture des tests et les performances. Si cela prend trop de temps pour obtenir les résultats des tests, les gens chercheront des raisons et des moyens de contourner le processus.

Faites d'abord les tests qui se terminent le plus rapidement afin d'obtenir un retour d'information le plus tôt possible, et n'investissez dans des tests plus longs que lorsque vous avez un certain degré de confiance dans le build. Compte tenu du temps nécessaire à l'assurance qualité manuelle et du fait que votre équipe doit être disponible pour effectuer ces tests, il est préférable de limiter cette phase jusqu'à ce que toutes les vérifications automatisées produisent les résultats voulus.

La première couche de tests automatisés est normalement constituée de tests unitaires, que vous pouvez utiliser pour assurer une large couverture et vous alerter de tout problème évident introduit par la dernière modification. Après les tests unitaires, vous pouvez avoir une couche de tests d'intégration ou de composants automatisés, qui testent les interactions entre les différentes parties de votre code.

Au-delà de ces tests, vous pouvez investir dans des tests automatisés plus complexes, tels que des tests d'interface graphique, des tests de performance et de charge ou des tests de sécurité, avant de prendre le temps de procéder à des tests exploratoires et/ou d'acceptation manuels. Pour rendre plus efficaces ces tests de longue durée, qu'ils soient automatiques ou manuels, concentrez-vous sur les domaines qui présentent le plus grand risque pour votre produit et vos utilisateurs.

Pour tirer le meilleur parti de votre suite d'assurance qualité, il vaut la peine de prendre le temps de nettoyer vos environnements de pré-production entre chaque déploiement.

Lorsque les environnements sont maintenus en fonctionnement pendant une longue période, il devient plus difficile de garder une trace de tous les changements de configuration et des mises à jour qui ont été appliqués sur chacun d'entre eux.

Avec le temps, les paramètres divergent de la configuration initiale et les uns des autres, ce qui signifie que les tests qui réussissent ou échouent dans l'un peuvent ne pas donner le même résultat dans un autre. Le maintien d'environnements statiques s'accompagne également d'un coût de maintenance, qui peut ralentir le processus d'assurance qualité et retarder le processus de publication.

L'utilisation de conteneurs pour héberger des environnements et effectuer des tests permet de recréer et de démonter facilement des environnements pour chaque nouveau déploiement, en utilisant une approche infrastructure-as-code pour scripter ces étapes. L'instanciation d'un nouveau conteneur à chaque fois assure la consistance et vous permet de faire évoluer les environnements plus facilement, de sorte que vous pouvez tester plusieurs builds en parallèle si nécessaire.

Une fois que vous avez investi dans la construction d'un pipeline de CI/CD fiable, rapide et sécurisé qui vous donne confiance en la qualité de vos builds. Vous ne voulez pas saper cet effort en permettant que le processus soit contourné pour une raison quelconque.

Généralement, la demande de contourner le processus de publication est faite parce que le changement est mineur ou urgent (ou les deux), mais céder à ces demandes est une fausse économie.

Sauter les étapes d'assurance qualité automatisées risque d'introduire des problèmes évitables, et la reproduction et le débogage des problèmes est beaucoup plus difficile car le build ne peut pas être immédiatement déployé dans une instance de test.

Il est probable qu'à un moment donné, on vous demandera de contourner le processus « juste cette fois-ci ». Vous serez probablement en plein rush à ce moment-là, mais cela vaut la peine d'utiliser une analyse rétrospective pour comprendre les motivations qui se cachent derrière. Est-ce que le processus semble trop lent ? Il y a peut-être des améliorations de performance ou des ajustements à apporter. Y a-t-il un malentendu quant au moment où il convient de l'utiliser ? Communiquer les avantages d'un pipeline de CI/CD peut aider à rallier les parties prenantes et à éviter ce genre de demandes la prochaine fois que l'on est pressé.

Dans le cadre de la mise en place de votre pipeline de CI/CD, vous avez probablement implémenté une surveillance de votre environnement de production pour vous alerter le plus tôt possible en cas de problème.

Tout comme le produit que vous publiez, votre processus de build bénéficiera également d'une boucle de feedback.

En analysant les mesures collectées par votre outil de CI/CD, vous pouvez identifier les problèmes potentiels et les domaines à améliorer.

• La comparaison du nombre de buids déclenchés par semaine, par jour ou par heure donne des indications utiles sur la façon dont votre infrastructure de pipeline est utilisée, sur la nécessité de la développer ou de la réduire et sur le moment où les pics de charge ont tendance à se produire.
• Le suivi de la vitesse des déploiements au fil du temps, et le fait de savoir s'ils ont tendance à prendre plus de temps, peut indiquer quand il est temps d'investir dans l'optimisation des performances.
• Les statistiques issues des tests automatisés peuvent aider à déterminer les domaines qui bénéficieraient d'une parallélisation.
• L'examen des résultats d'assurance qualité pour repérer ceux qui sont systématiquement ignorés peut permettre de rationaliser la couverture de votre assurance qualité.

La création d'un workflow efficace de CI/CD est autant une question de culture d'équipe et d'organisation qu'une question de processus et d'outils.

L'intégration, la prestation et le déploiement en continu sont toutes des pratiques du DevOps. Ils s'appuient sur la suppression du cloisonnement traditionnel entre les développeurs, les ingénieurs d'assurance qualité et les opérations, et encouragent la collaboration entre les disciplines.

Le décloisonnement donne aux équipes une plus grande visibilité du workflow de bout en bout et la possibilité de collaborer et de bénéficier de différents domaines d'expertise. L'entretien du pipeline ne devrait jamais être le travail d'une seule personne. L'implémentation d'une plateforme de CI/CD peut également vous permettre d'améliorer vos pratiques opérationnelles.

En créant un sentiment de responsabilité partagée pour la livraison de votre logiciel, vous pouvez permettre à tous les membres de l'équipe de contribuer, qu'il s'agisse d'intervenir pour réparer le build, de prendre le temps de conteneuriser les environnements ou d'automatiser une tâche manuelle qui n'est pas accomplie aussi souvent qu'elle le devrait.

La promotion d'une culture de confiance, où les membres de l'équipe sont capables d'expérimenter et de partager des idées, profite non seulement aux individus, mais aussi à l'organisation et au logiciel que vous livrez. Si quelque chose tourne mal, au lieu de se concentrer sur quel membre de votre équipe doit être tenu pour responsable, l'objectif devrait être de tirer des leçons de l'échec, de comprendre la cause sous-jacente et la manière de l'éviter à l'avenir.

Profitez de cette occasion pour améliorer votre pratique en matière de CI/CD et la rendre plus solide et efficace. En permettant aux membres de l'équipe d'expérimenter et d'innover sans crainte de reproches, vous créerez un cercle vertueux d'amélioration continue.