En prévision du début du cours "CI / CD sur AWS, Azure et Gitlab", nous avons préparé une traduction de matériel utile pour vous.
L'intégration continue (CI) et la livraison continue (CD) sont une culture, un ensemble de principes et de pratiques qui permettent aux développeurs de déployer plus fréquemment et de manière plus fiable des modifications logicielles.
CI / CD est l' une des pratiques DevOps . Elle s'applique également aux pratiques agiles : l'automatisation du déploiement permet aux développeurs de se concentrer sur la satisfaction des exigences métier, la qualité du code et la sécurité.
DĂ©finition de CI / CD
L'intégration continue est une méthodologie de développement et un ensemble de pratiques dans lesquelles de petites modifications sont apportées au code avec des validations fréquentes. Et comme la plupart des applications modernes sont développées à l'aide de diverses plates-formes et outils, il est nécessaire de disposer d'un mécanisme d'intégration et de tester les changements introduits.
Techniquement parlant, le but de CI est de fournir un moyen cohérent et automatisé pour créer, empaqueter et tester des applications. Avec un processus d'intégration continue rationalisé, les développeurs sont plus susceptibles de faire des commits fréquents, ce qui à son tour aidera à améliorer la communication et la qualité des logiciels.
La livraison continue commence là où se termine l'intégration continue. Il automatise le déploiement des applications dans différents environnements: la plupart des développeurs travaillent à la fois avec un environnement de production et avec des environnements de développement et de test.
Les outils CI / CD aident à personnaliser les paramètres d'environnement spécifiques qui sont configurés pendant le déploiement. Et aussi CI / CD-automation effectue les requêtes nécessaires aux serveurs Web, bases de données et autres services qui peuvent avoir besoin d'être redémarrés ou effectuer des actions supplémentaires lors du déploiement de l'application.
L'intégration continue et la livraison continue nécessitent des tests continuscar le but ultime est de développer des applications de qualité. Les tests continus sont souvent mis en œuvre sous la forme d'un ensemble de divers tests automatisés (régression, performances et autres) exécutés dans le pipeline CI / CD.
La pratique mature de CI / CD permet un déploiement continu: lorsque le code passe avec succès dans le pipeline CI / CD, les assemblys sont automatiquement déployés dans l'environnement de production. Les équipes pratiquant la livraison continue peuvent se permettre un déploiement quotidien ou même horaire. Il convient de noter ici, cependant, que la livraison continue ne convient pas à toutes les applications métier .
L'intégration continue améliore la communication et la qualité
L'intégration continue est une méthodologie de développement basée sur des processus régulés et l'automatisation. Avec l'intégration continue mise en œuvre, les développeurs confient souvent leur code au référentiel de code source. Et la plupart des équipes suivent la règle de s'engager au moins une fois par jour. Les petits changements sont plus faciles à repérer les défauts et les problèmes divers que les grands changements qui ont été travaillés sur une longue période de temps. De plus, travailler avec des cycles de validation courts réduit les chances que plusieurs développeurs modifient le même morceau de code, ce qui peut entraîner des conflits de fusion.
Les équipes mettant en œuvre l'intégration continue commencent souvent par mettre en place un système de contrôle de version et définir un flux de travail. Malgré le fait que les commits soient effectués fréquemment, la mise en œuvre des fonctionnalités et la correction des bogues peuvent prendre du temps. Il existe plusieurs approches pour contrôler les fonctionnalités et le code prêts.
De nombreuses personnes utilisent des indicateurs de fonctionnalité - un mécanisme pour activer et désactiver la fonctionnalité lors de l'exécution. La fonctionnalité, qui est encore en cours de développement, est enveloppée dans des indicateurs de fonctionnalité et est déployée de la branche principale à la production, mais est désactivée jusqu'à ce qu'elle soit entièrement prête à être utilisée. Selon une étude récente63% des équipes utilisant la fonction de drapeau signalent une meilleure testabilité et une meilleure qualité logicielle. Il existe des outils spéciaux pour travailler avec des indicateurs de fonctionnalités, tels que CloudBees Rollout , Optimizely Rollouts et LaunchDarkly , qui s'intègrent dans CI / CD et permettent la configuration au niveau de la fonctionnalité.
Une autre façon de travailler avec les fonctionnalités consiste à utiliser des branches dans le système de contrôle de version. Dans ce cas, vous devez définir un modèle de branchement (par exemple, tel que Gitflow) et décrire comment le code entre dans les branches de développement, de test et de production. Pour les fonctionnalités avec un long cycle de développement, des branches de fonctionnalités distinctes sont créées. Après avoir terminé le travail sur une fonctionnalité, les développeurs fusionnent les modifications de la branche de fonctionnalité dans la branche de développement principale. Cette approche fonctionne bien, mais elle peut être peu pratique si de nombreuses fonctionnalités sont développées en même temps.
La phase de construction consiste à automatiser l'emballage du logiciel, de la base de données et des autres composants requis. Par exemple, si vous développez une application Java, le CI regroupera tous les fichiers statiques tels que HTML, CSS et JavaScript avec l'application Java et les scripts de base de données.
CI emballera non seulement tous les composants logiciels et bases de données, mais il effectuera également automatiquement des tests unitaires et d'autres types de tests. Ce test permet aux développeurs d'obtenir des commentaires indiquant que les modifications qu'ils ont apportées n'ont rien cassé.
La plupart des outils CI / CD vous permettent de démarrer une compilation manuellement, sur une validation ou selon un calendrier. Les équipes doivent discuter d'un calendrier de construction qui leur convient en fonction de la taille de l'équipe, des engagements quotidiens attendus et d'autres critères. Il est important que les validations et les builds soient rapides, sinon les builds longs peuvent devenir un obstacle pour les développeurs qui essaient de s'engager rapidement et souvent.
Les tests continus sont plus que l'automatisation des tests
Les cadres de test automatisés aident les ingénieurs QA à concevoir, exécuter et automatiser divers types de tests qui aident les développeurs à suivre le succès de la construction. Les tests comprennent des tests fonctionnels qui sont développés à la fin de chaque sprint et combinés en tests de régression pour l'ensemble de l'application. Les tests de régression informent l'équipe si leurs modifications ont cassé quelque chose ailleurs dans l'application.
La meilleure pratique consiste à obliger les développeurs à exécuter tout ou partie des tests de régression dans leur environnement local. Cela garantira que les développeurs valident le code déjà vérifié.
Les tests de régression ne sont que le début. Tests de performance, tests d'API, analyse de code statique, tests de sécurité - ces types de tests et d'autres peuvent également être automatisés. Le point clé est la possibilité d'exécuter ces tests à partir de la ligne de commande, via un webhook ou via un service web et de renvoyer le résultat de l'exécution: le test a-t-il réussi ou non.
Les tests continus impliquent non seulement l'automatisation, mais également l'intégration de tests automatisés dans le pipeline CI / CD. Les tests unitaires et fonctionnels peuvent faire partie du CI et identifier les problèmes avant ou pendant le lancement du pipeline CI. Les tests qui nécessitent un déploiement complet de l'environnement, tels que les tests de performances et de sécurité, font souvent partie du CD et sont exécutés après le déploiement des builds dans les environnements cibles.
Le pipeline CD automatise la livraison des modifications à différents environnements
La livraison continue est le déploiement automatique d'une application dans son environnement cible. En règle générale, les développeurs travaillent avec un ou plusieurs environnements de développement et de test dans lesquels une application est déployée à des fins de test et d'examen. Pour cela, des outils CI / CD tels que Jenkins , CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI sont utilisés.
Un pipeline de CD typique comprend des étapes de construction, de test et de déploiement. Les pipelines plus complexes comprennent les étapes suivantes:
- Récupération du code du contrôle de code source et exécution d'une compilation
- Configuration de l'infrastructure automatisée grâce à une approche d'infrastructure en tant que code.
- Copie du code dans l'environnement cible.
- DĂ©finition des variables d'environnement pour l'environnement cible.
- (-, API-, ).
- , , .
- .
- .
Par exemple, dans le fichier Jenkins, déterminé par le convoyeur Jenkins , qui décrit les différentes étapes telles que l'assemblage (construction), le test (test) et le déploiement (déployer). Il décrit également les variables d'environnement, les clés secrètes, les certificats et d'autres paramètres pouvant être utilisés dans les étapes du pipeline. La section de publication configure la gestion des erreurs et les notifications.
Dans un pipeline de CD plus complexe, il peut y avoir des étapes supplémentaires, telles que la synchronisation des données, l'archivage des ressources d'informations, l'installation de mises à jour et de correctifs. Les outils CI / CD prennent généralement en charge les plugins. Par exemple, Jenkins a plus de 1500 plugins pour l'intégration avec des plates-formes tierces, pour étendre l'interface utilisateur, l'administration, la gestion du code source et la création.
Lors de l'utilisation d'un outil CI / CD, les développeurs doivent s'assurer que tous les paramètres sont configurés en dehors de l'application via des variables d'environnement. Les outils CI / CD vous permettent de définir les valeurs de ces variables, de masquer les mots de passe et les clés de compte et de les personnaliser pendant le déploiement pour un environnement spécifique.
Les outils CD contiennent également des tableaux de bord et des rapports. En cas d'échec de build ou de livraison, ils en informent. En intégrant le CD avec le contrôle de version et les outils agiles, il est plus facile de trouver les changements de code et les user stories inclus dans la construction.
Implémentation de pipelines CI / CD avec Kubernetes et des architectures sans serveur
De nombreuses équipes utilisant des pipelines CI / CD dans les clouds utilisent des conteneurs tels que Docker et des systèmes d'orchestration tels que Kubernetes . Les conteneurs aident à standardiser l'emballage, la livraison et à simplifier la mise à l'échelle et la destruction des environnements volatils.
Il existe de nombreuses options pour partager des conteneurs, une infrastructure sous forme de code et des pipelines CI / CD. Pour en savoir plus Ă ce sujet, consultez les articles Kubernetes avec Jenkins et Kubernetes avec Azure DevOps .
L'informatique sans serveur est une autre façon de déployer et de mettre à l'échelle des applications. Dans un environnement sans serveur, l'infrastructure est entièrement gérée par le fournisseur de cloud et l'application consomme les ressources selon les besoins en fonction de ses paramètres. Par exemple, dans AWS, les applications sans serveur sont exécutées via des fonctions AWS Lambda , dont le déploiement peut être intégré dans le pipeline Jenkins CI / CD à l' aide d'un plug-in.
CI / CD permet un déploiement de code plus fréquent
Alors, résumons. CI packages, teste les builds et avertit les développeurs en cas de problème. Le CD déploie automatiquement les applications et exécute des tests supplémentaires.
Les pipelines CI / CD sont conçus pour les organisations qui doivent apporter des modifications fréquentes aux applications avec un processus de livraison fiable. En plus de standardiser les builds, de développer des tests et d'automatiser les déploiements, nous bénéficions d'un flux de travail holistique pour déployer les changements de code. La mise en œuvre de CI / CD permet aux développeurs de se concentrer sur l'amélioration de leurs applications et de ne pas perdre de temps à les déployer.
CI / CD est l'une des pratiques DevOpscar il vise à lutter contre les contradictions entre les développeurs qui veulent faire des changements fréquents et une exploitation, ce qui nécessite de la stabilité. Grâce à l'automatisation, les développeurs peuvent apporter des modifications plus souvent et les équipes opérationnelles, à leur tour, gagnent en stabilité, car la configuration des environnements est standardisée et des tests continus sont effectués pendant le processus de livraison. En outre, la configuration des variables d'environnement est distincte de l'application et il existe des procédures de restauration automatisées.
L'impact de la mise en œuvre de pipelines CI / CD peut être mesuré en termes d' indicateurs clés de performance (KPI) DevOps... Les indicateurs clés de performance tels que la fréquence de déploiement, le délai de changement et le temps moyen de récupération s'améliorent souvent avec les déploiements CI / CD avec des tests continus. Cependant, CI / CD n'est qu'un processus qui peut contribuer à ces améliorations. Il existe d' autres conditions pour augmenter la fréquence de livraison.
Pour démarrer avec CI / CD, l'équipe de développement et d'exploitation doit collaborer sur les technologies, les pratiques et les priorités. Les équipes doivent parvenir à un consensus sur les bonnes approches de leur activité et de leur technologie afin qu'après la mise en œuvre de CI / CD, l'équipe adhère systématiquement aux pratiques choisies.
Présentation des outils CICD: Gitlab CI, Docker, Ansible