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.
# Compréhension 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 automatise une grande partie ou la totalité des processus manuels traditionnellement nécessaires pour faire passer le nouveau code d'une validation à la production. Un CI/CD pipeline englobe les étapes de source, de construction, de test, de préparation et de production. À chaque étape, les CI/CD pipelines fournissent toute infrastructure nécessaire au déploiement ou au test du code. En utilisant un CI/CD pipeline, 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 complètement de l'être. CI/CD Le schéma suivant montre les CI/CD étapes et les activités de chaque étape.
## À 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 [Trunk-based approche](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.