Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Comprendre le CI/CD
L'intégration continue et la livraison continue (CI/CD) sont le processus d'automatisation du cycle de vie des versions logicielles. Dans certains cas, le *D* in CI/CD peut également signifier un *déploiement*. La différence entre la *livraison continue* et *le déploiement continu* se produit lorsque vous apportez une modification à l'environnement de production. Dans le cas d'une livraison continue, une approbation manuelle est requise avant de promouvoir des modifications de la production. Le déploiement continu permet un flux ininterrompu sur l'ensemble du pipeline, et aucune approbation explicite n'est requise. Étant donné que cette stratégie aborde CI/CD des concepts généraux, les recommandations et les informations fournies s'appliquent à la fois aux approches de livraison continue et de déploiement continu.
CI/CD automates much or all of the manual processes traditionally required to get new code from a commit into production. A CI/CD pipeline encompasses the source, build, test, staging, and production stages. In each stage, the CI/CD pipelines provisions any infrastructure that is needed to deploy or test the code. By using a CI/CDpipeline, les équipes de développement peuvent apporter des modifications au code qui sont ensuite automatiquement testées et poussées au déploiement.
Passons en revue le CI/CD processus de base avant de discuter de certaines des façons dont vous pouvez, sciemment ou non, vous écarter des CI/CD. The following diagram shows the CI/CD étapes complètes et des activités à chaque étape.
![\[Les cinq étapes d'un CI/CD processus ainsi que les activités et les environnements de chacune d'elles.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## À propos de l'intégration continue
L'intégration continue se produit dans un référentiel de code, tel qu'un référentiel Git dansGitHub. Vous considérez une seule branche principale comme la source de vérité de la base de code, et vous créez des branches éphémères pour le développement de fonctionnalités. Vous intégrez une branche de fonctionnalités dans la branche principale lorsque vous êtes prêt à déployer la fonctionnalité dans des environnements supérieurs. Les branches de fonctionnalités ne sont jamais déployées directement dans les environnements supérieurs. Pour plus d’informations, consultez [Approche basée sur le tronc](fully-cicd-process-differences.md#trunk-based-approach) dans ce guide.
*Processus d'intégration continue*
1. Le développeur crée une nouvelle branche à partir de la branche principale.
1. Le développeur apporte des modifications, construit et teste localement.
1. Lorsque les modifications sont prêtes, le développeur crée une [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub documentation) avec la branche principale comme destination.
1. Le code est revu.
1. Lorsque le code est approuvé, il est fusionné dans la branche principale.
## À propos de la livraison continue
La livraison continue s'effectue dans des environnements isolés, tels que les environnements de développement et les environnements de production. Les actions qui se produisent dans chaque environnement peuvent varier. Souvent, l'une des premières étapes est utilisée pour mettre à jour le pipeline lui-même avant de continuer. Le résultat final du déploiement est que chaque environnement est mis à jour avec les dernières modifications. Le nombre d'environnements de développement pour la création et les tests varie également, mais nous vous recommandons d'en utiliser au moins deux. Dans le pipeline, chaque environnement est mis à jour par ordre d'importance, en terminant par l'environnement le plus important, l'environnement de production.
*Processus de livraison continu*
La partie de distribution continue du pipeline commence en extrayant le code de la branche principale du référentiel source et en le transmettant à la phase de construction. Le document d'infrastructure sous forme de code (IaC) du référentiel décrit les tâches effectuées à chaque étape. Bien que l'utilisation d'un document IaC ne soit pas obligatoire, un service ou un outil IaC, tel que [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)ou [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html), est fortement recommandé. Les étapes les plus courantes sont les suivantes :
1. Tests unitaires
1. Création de code
1. Approvisionnement des ressources
1. Tests d'intégration
Si des erreurs se produisent ou si des tests échouent à un stade quelconque du pipeline, l'étape en cours revient à son état précédent et le pipeline est arrêté. Les modifications ultérieures doivent commencer dans le référentiel de code et suivre le CI/CD processus complet.
# Tests pour CI/CD pipelines
Les deux types de tests automatisés couramment mentionnés dans les pipelines de déploiement sont les *tests unitaires et les tests* *d'intégration*. Cependant, il existe de nombreux types de tests que vous pouvez exécuter sur une base de code et dans l'environnement de développement. L'[architecture de référence du pipeline de AWS déploiement](https://pipelines.devops.aws.dev/application-pipeline/) définit les types de tests suivants :
+ **Test unitaire** : ces tests génèrent et exécutent le code de l'application pour vérifier qu'il fonctionne conformément aux attentes. Ils simulent toutes les dépendances externes utilisées dans la base de code. Des exemples d'outils de test unitaire incluent [JUnit](https://junit.org/)[Jest](https://jestjs.io/) et [pytest](https://pytest.org/).
+ **Test d'intégration** : ces tests vérifient que l'application répond aux exigences techniques en effectuant des tests par rapport à un environnement de test provisionné. Des exemples d'outils de test d'intégration incluent [Cucumber](https://cucumber.io/), [vRest NG](https://vrest.io/) et [integ-tests (for](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html)). AWS CDK
+ **Test d'acceptation** — Ces tests vérifient que l'application répond aux exigences de l'utilisateur en effectuant des tests par rapport à un environnement de test provisionné. [Cypress](https://cypress.io/) et [Selenium](https://selenium.dev/) sont des exemples d'outils de test d'acceptation.
+ **Test synthétique** — Ces tests sont exécutés en continu en arrière-plan pour générer du trafic et vérifier que le système est en bon état. [Amazon Synthetics et Dynatrace CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) [Monitoring sont des exemples d'outils de test synthétiques.](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/)
+ **Test de performance** — Ces tests simulent la capacité de production. Ils déterminent si l'application répond aux exigences de performance et comparent les indicateurs aux performances passées. [Apache](https://jmeter.apache.org/), [Locust](https://locust.io/) et [Gatling](https://gatling.io/) sont JMeter des exemples d'outils de test de performance.
+ **Test de résilience** : également appelés *tests de chaos*, ces tests injectent les défaillances dans les environnements afin d'identifier les zones à risque. Les périodes pendant lesquelles les défaillances sont injectées sont ensuite comparées à des périodes sans défaillances. Parmi les exemples d'outils de test de résilience, citons [AWS Fault Injection Service](https://aws.amazon.com/fis/)[Gremlin](https://www.gremlin.com/).
+ **Test statique de sécurité des applications (SAST)** : ces tests analysent le code pour détecter les violations de sécurité, telles que l'[injection SQL](https://owasp.org/www-community/attacks/SQL_Injection) ou les [scripts intersites (](https://owasp.org/www-community/attacks/xss/)XSS). [Amazon](https://aws.amazon.com/codeguru/) et [Checkmarx](https://checkmarx.com/) sont des exemples CodeGuru d'[SonarQube](https://www.sonarqube.org/)outils SAST.
+ **Test dynamique de sécurité des applications (DAST)** — Ces tests sont également appelés tests de *pénétration ou tests* au *stylo*. Ils identifient les vulnérabilités, telles que l'injection SQL ou le XSS dans un environnement de test provisionné. [Les exemples d'outils DAST incluent [Zed Attack Proxy (ZAP) et HCL](https://www.zaproxy.org/). AppScan](https://www.hcltechsw.com/appscan) Pour plus d'informations, consultez la section [Tests de pénétration](https://aws.amazon.com/security/penetration-testing/).
Tous les CI/CD pipelines n'exécutent pas tous ces tests. Cependant, un pipeline doit au minimum exécuter des tests unitaires et des tests SAST sur la base du code ainsi que des tests d'intégration et d'acceptation sur un environnement de test.
# Métriques pour les CI/CD pipelines
Selon l'[architecture de référence du pipeline de AWS déploiement](https://pipelines.devops.aws.dev/application-pipeline/), vous devez au minimum suivre les quatre mesures suivantes pour les CI/CD pipelines :
+ **Délai** de livraison : temps moyen nécessaire pour qu'un seul engagement soit mis en production. Nous vous recommandons de cibler un délai compris entre 1 heure et 1 jour, selon votre cas d'utilisation.
+ **Fréquence de déploiement** : nombre de déploiements de production au cours d'une période donnée. Nous vous recommandons de cibler les fréquences de déploiement entre plusieurs fois par jour et deux fois par semaine, selon votre cas d'utilisation.
+ **Temps moyen entre les défaillances (MTBF)** : délai moyen entre le début d'un pipeline réussi et le début d'un pipeline défaillant. Nous recommandons de cibler un MTBF aussi élevé que possible. Pour plus d'informations, consultez la section [Augmenter le MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html).
+ **Temps moyen de restauration (MTTR)** : délai moyen entre le début d'un pipeline défaillant et le début du prochain pipeline réussi. Nous recommandons de cibler un MTTR aussi bas que possible. Pour plus d'informations, consultez la section [Réduction du MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html).
Ces indicateurs aident les équipes à suivre leurs progrès pour devenir pleinement CI/CD. Les équipes devraient avoir des discussions ouvertes avec les parties prenantes de l'organisation pour déterminer quels devraient être les objectifs optimaux. Les situations et les besoins varient considérablement d'une organisation à l'autre, et même d'une équipe à l'autre.
Il est très important de se rappeler qu'un changement rapide et radical augmente généralement le risque de problèmes. Fixez-vous des objectifs visant à apporter de petites améliorations progressives. Un délai optimal courant pour les CI/CD pipelines complets est inférieur à 3 heures. Une équipe qui commence avec un délai de 5,2 jours devrait viser une réduction d'un jour toutes les quelques semaines. Une fois que cette équipe a atteint un délai d'un jour ou moins, elle peut rester sur place pendant plusieurs mois et passer à un délai plus agressif uniquement si l'équipe et les parties prenantes de l'organisation le jugent nécessaire.