Mis à jours 20 mars 2022 CI/CD automatise les étapes d’intégration et de livraison d’applications et normalise les configurations d’applications. Voici comment utiliser CI/CD dans votre entreprise.
Passez sur un chantier de construction et vous reconnaîtrez rapidement plusieurs types d’activités. Les travaux de construction du bâtiment, y compris la fondation, la charpente et l’intérieur. Il existe également des travaux qui permettent la construction, tels que le positionnement des grues, l’installation des ascenseurs pour les travailleurs et la mise en place des échafaudages et autres structures de sécurité.
C’est pareil pour le développement d’applications. Il faut beaucoup de travail pour développer les bases de données, les applications et les interfaces utilisateur. Mais, à l’instar de la construction, il y a l’investissement dans des outils et des pratiques permettant un développement et une livraison de logiciels productifs, de meilleure qualité et fiables.
Ces pratiques font partie des devops. L’intégration et la distribution continues (CI/CD) sont des pratiques fondamentales pour fournir des logiciels de qualité selon des calendriers plus fréquents.
Les approches et les pratiques CI/CD favorisent la productivité, la qualité et la rapidité
CI/CD automatise les étapes d’intégration et de livraison d’applications et normalise les configurations d’applications. Lorsque les développeurs archivent le nouveau code, les pipelines CI/CD exécutent une séquence de générations, de tests, de migrations de données, de déploiements d’applications, d’appels de service et autres procédures scriptées pour rendre les modifications de code disponibles dans les environnements ciblés. Avec cette automatisation en place, les équipes adaptent leurs pratiques et cherchent à archiver le code, à intégrer, à tester et à livrer des applications plus fréquemment.
Lorsqu’elles sont pleinement matures, certaines entreprises vont encore plus loin et mettent en œuvre des déploiements continus dans des environnements de production. Cependant, un tel déploiement continu peut ne pas être optimal pour toutes les entreprises et tous les types de produits.
Les avantages de l’approche Intégration continue (CI) et la distribution en continue (CD)
Une récente enquête menée auprès de 549 professionnels du logiciel fournit des informations sur les avantages que les entreprises matures développant avec les approches CI/CD ont obtenus :
60% des personnes interrogées ont déclaré qu’ils peuvent produire un nouveau code en moins de sept jours et près de 40% en moins de 24 heures. Près de 50% des personnes interrogées affirment que le délai moyen de rétablissement du service en cas de problème de production est inférieur à deux heures.
La pratique de CI/CD présente d’autres avantages tangibles en alignant les équipes sur les meilleures pratiques de développement, de test et d’exploitation :
- Elle corrige le désalignement entre les développeurs qui souhaitent apporter des modifications fréquemment et le personnel des opérations qui souhaite avoir des applications stables.
- Elle oblige les équipes de développement à mettre en œuvre des tests continus afin que les modifications de code puissent être validées avant d’être transmises aux utilisateurs.
- Elle encourage les développeurs à effectuer davantage de modifications mineures et incrémentielles du code, mieux intégrées et testées que des modifications plus importantes.
- Elle offre plus de flexibilité aux équipes qui sont invitées à apporter des solutions rapides parallèlement au développement d’efforts de développement plus importants sur les nouvelles capacités et fonctionnalités.
- Elle permet davantage de fonctionnalités, de performances et de tests basés sur les données, de sorte que des applications de meilleure qualité puissent être livrées et qu’elles aient le moindre défaut de production possible.
L’intégration continue (CI) permet la productivité et la qualité du développement
Disons que vous travaillez sur une mise à niveau d’une application existante. Votre équipe a été chargée de développer de nouvelles fonctionnalités, de résoudre certains problèmes signalés par les utilisateurs, de résoudre certains problèmes d’endettement technique en mettant à niveau certaines des bibliothèques de codes sous-jacentes et d’améliorer les performances de certains rapports couramment utilisés.
Votre équipe est composée de développeurs d’applications et de bases de données, de rédacteurs de rapports, de testeurs et d’un ingénieur système. Vous suivez un processus de développement Scrum et vous avez déjà le code de l’application dans un référentiel Git.
Mais certaines choses n’ont pas bien fonctionné dans la dernière version. Tout d’abord, il a fallu plusieurs jours pour que l’application soit testée, car la plupart des tests étaient effectués manuellement. Une fois les tests terminés, il en résultait une liste importante de défauts à traiter à la fin du cycle de développement.
Le cycle de correction des bogues suivi de longs tests manuels a obligé l’équipe à retarder la publication. Ensuite, une fois déployés, des problèmes de production se sont posés, car les modifications apportées à l’application et à la base de données n’étaient pas correctement synchronisées.
La mise en place d’une pratique d’intégration continue
Cette fois, votre équipe et vous-même êtes déterminés à ne pas répéter les mêmes erreurs. De plus, les responsables commerciaux et informatiques ont donné leur accord pour mettre en œuvre une pratique d’intégration continue. Cela change vos priorités et vos pratiques de développement liées au déploiement.
Vous ne pouvez pas avoir une pratique d’intégration continue sans tests de régression et autres pratiques de tests continus en place. Ainsi, au lieu de travailler directement dans le code pour apporter les modifications requises, l’ensemble de l’équipe s’associe aux testeurs et automatise les tests les plus importants qui valident la construction. Une fois terminé, vous disposez de plusieurs outils et scripts pouvant effectuer certains des tests unitaires et fonctionnels les plus critiques.
Les outils de construction d’application
La prochaine chose que vous allez voir sont les outils utilisés pour construire l’application. Pour l’application, vous reconnaissez que ces scripts fonctionnent, mais ils ne gèrent pas les conditions d’erreur lors d’une génération ayant échoué. De plus, vous n’avez pas de processus pour apporter et annuler les modifications de base de données, vous établissez donc un processus de base. Vous sélectionnez un outil d’intégration continue utilisé pour séquencer tous les scripts de construction et de test dans un processus automatisé, puis vous le connectez à Git afin que les générations soient déclenchées lors de la fusion du code.
Avec un outil d’intégration continue et une automatisation développée, vous consultez maintenant l’équipe sur les pratiques de développement. L’équipe ne peut plus développer en silos et attendre la fin d’un cycle de déploiement pour valider que tout fonctionne.
La première chose à faire est d’encourager les développeurs à valider leurs modifications de code quotidiennement. Cela semble effrayant au début, car cela signifie que le code doit être dans un état fonctionnel et que les processus d’intégration continue n’échouent pas à cause d’une construction ou d’un test défectueux. L’équipe réalise rapidement qu’elle doit travailler sur des modifications mineures du code au lieu de développer une fonctionnalité complète ou de tenter une refactorisation complexe.
L’équipe convient également qu’un développement est considéré comme « terminé » uniquement lorsque des tests valident la fonctionnalité modifiée et que les tests peuvent être incorporés dans le processus de test continu. Cela oblige l’équipe à reconsidérer la manière dont elle s’engage et gère son temps pendant le sprint afin que les testeurs aient suffisamment de temps pour développer des tests. L’équipe discute de la meilleure façon d’appliquer les méthodologies de développement pilotées par les tests lorsque des tests unitaires sont développés avant de coder de nouvelles fonctionnalités.
Introduction de méthodologies
Vous introduisez ensuite plusieurs méthodologies pour mieux contrôler les modifications et les fonctionnalités prêtes pour la production. Pour de très petites modifications, l’équipe peut s’enregistrer dans la branche principale du développement en exigeant que tous les tests soient réussis et que la modification puisse être déployée en production à tout moment.
Pour les exercices de développement légèrement plus importants, vous introduisez des indicateurs de fonctionnalité, un moyen de déployer un code fonctionnel qui n’est pas visible ou qui ne fonctionne pas de manière opérationnelle pour les utilisateurs. Ces indicateurs de fonctionnalité peuvent être activés lorsque le produit est déployé dans des environnements de développement et de test, et désactivés pour la production.
Pour les développements encore plus importants ou des correctifs de production, suivez Gitflow et informez l’équipe sur la manière de tirer parti des branches de fonctionnalités et de correctifs dans Git.
Vous utiliserez une combinaison de ces pratiques pour établir une stratégie de gestion des versions. Pour les priorités en jeu, l’équipe s’engage à régler la dette technique dès le départ et à la mettre en production au cours des premières publications hebdomadaires. L’équipe utilise ensuite une estimation agile et d’autres techniques pour choisir les fonctionnalités à intégrer dans la branche de développement, certaines vont utiliser des indicateurs de fonctionnalité et une amélioration plus complexe à développer dans une branche de fonctionnalité.
La distribution continue (CD) normalise et automatise les modifications à apporter
Avec une pratique d’intégration continue en place, certains membres de l’équipe deviennent anxieux et veulent se lancer dans le développement. Mais, l’ingénieur système n’est pas aussi impatient car, bien que les versions et les tests soient automatisés, les étapes pour transférer les modifications apportées à l’application et à la base de données à la production et aux autres environnements ne sont pas automatisées.
Un processus par étapes
Vous, comme étant l’ingénieur, disposez d’un processus à plusieurs étapes. Certaines sont partiellement manuel d’autres sont partiellement automatisés pour appliquer de nouvelles applications, et d’un processus encore plus compliqué pour les restaurer. De plus, chaque déploiement semble légèrement différent des précédents et nécessite une révision et une mise à jour de ces procédures en fonction du type de modifications apportées.
Vous en avez assez d’être accusé d’avoir gâché un déploiement, car les étapes du processus n’étaient pas parfaitement documentées.
Vous ne serez pas en mesure de prendre en charge les modifications hebdomadaires et de tester une combinaison de modifications intervenues dans le développement et les fonctionnalités, à moins que l’équipe n’investisse dans une distribution continue (CD).
Vous aurez de bonnes nouvelles a annoncées. Vous avez déjà investi dans l’infrastructure en tant que code, ce qui vous permet de configurer facilement de nouveaux environnements de manière cohérente. Cependant, il faudra comprendre comment appliquer les modifications d’application dans ces environnements de manière cohérente.
Application des modifications
Après avoir sélectionné un outil de distribution continue, l’équipe doit d’abord apporter certaines modifications au code afin que les informations spécifiques aux environnements soient extraites de l’application. Cela signifie que les variables d’environnement, les nœuds finaux, les noms d’utilisateur et les mots de passe, ainsi que d’autres variables d’exécution doivent utiliser des variables configurées par l’environnement et définies dans l’outil de distribution continue. Pour faciliter la gestion des configurations, ils se sont mis d’accord sur les conventions de nommage des variables d’environnement.
Cela signifie également que certaines des étapes manuelles pré et post-déploiement doivent être scriptées de manière à pouvoir être exécutées par l’outil de distribution continue. Les étapes pour transmettre les modifications de données, synchroniser la configuration du service ou exécuter les index de base de données sont désormais automatisées avec leurs propres validations. L’équipe automatise également les tests de performance et de sécurité de sorte que ces tests doivent réussir avant que la livraison ne soit confirmée à un environnement. Enfin, chaque étape du processus de livraison comporte une étape équivalente qui est exécutée si la livraison échoue et doit être annulée.
Les configuration nécessaires pour l’application
L’équipe effectue les configurations d’application à l’aide de la technologie de conteneur et discute des avantages de l’utilisation des conteneurs Docker, Kubernetes, Windows Server et d’autres technologies de conteneur. Cela garantit que tous les services d’application sont configurés et présentés de manière uniforme et peuvent être construits de manière cohérente.
L’équipe réfléchit également aux problèmes de données rencontrés depuis la dernière version. Les données de production est en constante évolution, comment ces données peuvent-elles être reflétées dans l’environnement de développement et de test ? La réponse : Elles sont aussi scriptées afin que les données de production soient masquées et puissent être envoyées dans des environnements de développement et de test selon un planning ou à la demande.
Ensuite, l’équipe repense à ses besoins en matière d’environnement. Au lieu d’avoir un seul environnement de développement, l’équipe permet à la création d’une nouvelle branche de fonctionnalités de déclencher la création d’un environnement dédié pour développer cette branche et les configurations nécessaires au déploiement dans cet environnement.
L’équipe décide également de configurer deux environnements de test, l’un dans lequel les données sont normalisées et permettent d’effectuer des tests fonctionnels par rapport à un jeu de données stable, et un environnement séparé avec un jeu de données de production complet pour effectuer des tests de performance.
Etablir CI/CD progressivement
En réalité, la plupart des entreprises ne peuvent pas facilement mettre au point une pratique de CI/CD en une seule fois ou mettre en attente les exigences de l’entreprise jusqu’à ce qu’elles soient établies. Par conséquent, les entreprises de développement doivent établir les pratiques au fur et à mesure.
Puis, de nombreuses applications existantes ne peuvent pas être facilement converties de manière globale en pipelines CI/CD lorsque certaines des meilleures pratiques ne peuvent pas être mises en œuvre dans des délais raisonnables ou avec les compétences de l’équipe disponible.
Ainsi, dans la plupart des entreprises, CI/CD est établi au fil du temps, à commencer par les pratiques et l’automatisation qui traitent des problèmes les plus importants et évitent les obstacles techniques les plus importants.
Un bon point de départ consiste à définir et à hiérarchiser les problèmes et les opportunités. Les équipes peuvent ensuite établir une épopée de développement dans leur carnet de commandes agile et chercher à développer des éléments de leur approche CI/CD au fil du temps et parallèlement à la satisfaction des besoins de l’entreprise.
