L'intégration continue et le déploiement continu expliqués (1er Partie)

L'intégration continue (CI) et le déploiement continu (CD) - également appelé distribution continue ou livraison continue - incarnent une culture, un ensemble de principes opérationnels et un ensemble de pratiques qui permettent aux équipes de développement d'applications de livrer plus fréquemment et de manière plus fiable les modifications de code. L’implementation est également connue sous le nom de pipeline CI/CD. Le CI/CD est l'une des meilleures pratiques que les équipes de développement peuvent adopter. C'est également l’une meilleure pratique en matière de méthodologie agile, car l’automatisation des étapes de déploiement permet aux équipes de développement de logiciels de se concentrer sur les besoins commerciaux de l’entreprise, la qualité du code et la sécurité.

L’approche CI/CD

L'intégration continue est une philosophie de codage et un ensemble de pratiques qui conduisent les équipes de développement à implementer de petites modifications et à vérifier fréquemment le code source dans les référentiels de contrôle de version. Aujourd’hui, la plupart des applications modernes imposent de développer du code sur différentes plateformes et avec différents outils. C’est pour cette raison que les équipes de développement ont besoin d'un mécanisme pour intégrer et valider ces changements. L'objectif technique de l’intégration continue (CI) est d'établir une méthode cohérente et automatisée pour construire, empaqueter et tester les applications. Une fois ce processus d'intégration cohérent mis en place, les équipes peuvent appliquer des changements de code plus fréquemment. La méthode permet une meilleure collaboration entre les équipes et contribue ainsi à une meilleure qualité des logiciels.

La livraison continue (CD) reprend là où s'arrête l'intégration continue. Elle automatise la livraison des applications à des environnements d'infrastructure sélectionnés. La plupart des équipes travaillent avec plusieurs environnements autres que l’environnement de production, des environnements de développement et de test par exemple, et la livraison continue garantit que les changements de code seront déployés automatiquement. Les outils CI/CD permettent de stocker les paramètres spécifiques à l'environnement qui doivent être packagés avec chaque livraison. L'automatisation CI/CD effectue ensuite tous les appels de service nécessaires aux serveurs web, bases de données et autres services qui doivent être redémarrés ou elle applique d'autres procédures une fois que les applications ont été déployées.

Meilleure collaboration et meilleure qualité du code en CI

L'intégration continue et la livraison continue nécessitent des tests continus, car l'objectif est de fournir des applications et du code de qualité aux utilisateurs. Les tests continus consistent souvent à implementer un ensemble de tests automatisés de régression, de performance et d’autres tests qui sont exécutés dans le pipeline CI/CD. Dans une pratique devops CI/CD mature, il est possible d’implementer un déploiement continu quand les changements d'application sont exécutés dans le pipeline CI/CD et quand les versions successives sont déployées directement dans les environnements de production. Les équipes qui pratiquent la livraison continue choisissent de déployer en production selon un calendrier quotidien, voire parfois sur une base horaire, même si la livraison continue n’est pas toujours optimale pour chaque application métier.

Le concept d'intégration continue (CI) est porté par une mécanique des processus et une certaine automatisation. Quand ils pratiquent l’intégration continue, les développeurs procèdent fréquemment à des modifications de leur code dans le référentiel de contrôle de version et la plupart des équipes s’imposent au minimum une modification de code journalière. Une des raisons à cela, c’est qu'il est plus facile d'identifier des erreurs et d’apprécier d’autres problèmes de qualité de code quand il y a peu de modifications entre chaque version que lorsqu’il y a d’importantes modifications entre deux versions qui ont demandé plus de temps à développer. En outre, quand les développeurs travaillent sur des cycles de validation plus courts, il y a moins de chance que plusieurs développeurs modifient le même code et qu’il y ait besoin de fusionner les modifications lors de la validation. Les équipes qui adoptent l’intégration continue commencent souvent par configurer le contrôle de version et par définir des pratiques. Même si le contrôle du code est effectué fréquemment, les fonctionnalités et les corrections sont appliquées sur des périodes courtes ou plus longues. Les équipes de développement pratiquant l'intégration continue utilisent différentes techniques pour contrôler les fonctionnalités et le code prêts à être mis en production.

Contrôle de version

Par exemple, un grand nombre d’équipes utilisent les « feature flags », autrement dit, des indicateurs de fonctionnalités. Ce mécanisme de configuration permet d'activer ou de désactiver des fonctionnalités et du code au moment de l'exécution. Les fonctionnalités encore en cours de développement sont balisées dans le code par des indicateurs de fonctionnalités déployées en production avec la branche maître, et désactivées jusqu'à ce qu'elles soient prêtes à être utilisées. Selon une enquête récente, 63 % des équipes qui utilisent des indicateurs de fonctionnalités font état d’une meilleure qualité de leurs tests et de leurs logiciels. Des outils d’indication de fonctionnalités, comme CloudBees Rollout, Optimizely Rollouts et LaunchDarkly, s'intègrent aux outils CI/CD et permettent des configurations au niveau des fonctionnalités.

Une autre technique de gestion des fonctionnalités consiste à effectuer un contrôle de version par branche. Certaines équipes optent pour un workflow Git comme Gitflow, lequel peut séparer, sur des branches distinctes, le code en cours de développement et le code validé et testé. Gitflow permet de définir des protocoles de fusion du nouveau code dans des branches standard pour le développement, les tests et la production. Des branches de fonctionnalités supplémentaires sont créées pour celles qui nécessiteront des cycles de développement plus longs. Quand la fonctionnalité est achevée, les développeurs peuvent alors fusionner les modifications des branches de fonctionnalités dans la branche de développement principale. Cette approche fonctionne bien, mais elle peut devenir difficile à gérer si de nombreuses fonctionnalités sont développées simultanément.

L'importance du calendrier build

Le processus de build lui-même est ensuite automatisé en regroupant tous les logiciels, la base de données et les autres composants. Par exemple, si vous développez une application Java, l’intégration continue (CI) regroupera tous les fichiers statiques du serveur web comme HTML, CSS et JavaScript, ainsi que l'application Java et les scripts de la base de données. L’intégration continue ne se contente pas de packager tous les logiciels et les composants de la base de données, mais l'automatisation exécute également des tests unitaires et d'autres tests. Ces tests permettent aux développeurs de savoir que leurs modifications de code n'ont pas interrompu des tests unitaires en cours.

La plupart des outils CI/CD permettent aux développeurs de publier des builds à la demande, soit déclenchées par des modifications de code dans le référentiel de contrôle de version, soit selon un calendrier défini. Les équipes doivent discuter du calendrier build qui convient le mieux à la taille de l'équipe, au nombre de modifications de code attendu chaque jour et à d'autres considérations relatives à l'application. C’est une bonne pratique pour s'assurer que les modifications de code et les builds sont rapides. En effet, l’absence de calendrier pour les builds peut entraver la progression des équipes qui essaient de coder rapidement et de modifier du code fréquemment.

Pour lire la suite de ce sujet, cliquez sur ce lien.