Amazon DVA-C02: Déploiement et CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, Conteneurs) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Fondations CI/CD avec CodePipeline et CodeBuild : patterns, API et pièges courants

Concevez des pipelines avec des étapes claires : source, build, test, approbation, déploiement et vérification post-déploiement. CodePipeline coordonne ces étapes ; utilisez un rôle de pipeline qui accorde des autorisations minimales et ciblées, et configurez des rôles d’action pour les intégrations tierces. Déclenchez les pipelines via les webhooks CodeCommit ou avec StartPipelineExecution (SDK AWS : codepipeline.startPipelineExecution) pour des lancements programmatiques. Pour les builds, préférez les projets CodeBuild avec un fichier buildspec.yml définissant les phases (install, pre_build, build, post_build) ; invoquez les builds directement avec StartBuild ou StartBuildBatch lorsque vous avez besoin de builds ad-hoc ou par lots. Pour les builds d’images, utilisez aws ecr get-login-password redirigé (piped) vers docker login dans la phase pre_build, puis effectuez un docker build/push vers ECR et capturez le digest de l’image pour produire des références d’artefact immuables. Évitez d’utiliser des tags flottants comme « latest » ; émettez plutôt des définitions de tâches ou des fichiers manifestes qui référencent les digests d’image afin que les déploiements soient déterministes. Faites attention aux pièges courants : les jetons d’authentification ECR expirés dans les scripts de longue durée, les politiques IAM de CodeBuild inadéquates pour pousser vers ECR ou appeler des API AWS, et le codage en dur des ARN. Instrumentez les builds pour téléverser (upload) les artefacts vers S3 ou vers le magasin d’artefacts du pipeline, et utilisez des variables d’environnement et Parameter Store/Secrets Manager pour les valeurs sensibles, nécessaires uniquement à l’exécution (runtime), plutôt que d’intégrer des secrets dans les artefacts de build.

Stratégies de déploiement : CodeDeploy, alias Lambda et choix de configuration Elastic Beanstalk

Choisissez le modèle de déploiement qui correspond à votre tolérance au risque et à vos besoins de restauration (rollback). Pour Lambda, utilisez les versions et les alias ; publiez une version (lambda.publishVersion) et mettez à jour les alias avec des règles de répartition du trafic (traffic-shifting) via CodeDeploy en créant un déploiement (codedeploy.createDeployment) référençant l’application Lambda et le groupe de déploiement. Utilisez les configurations intégrées de CodeDeploy comme CodeDeployDefault.LambdaCanary10Percent5Minutes ou un routage de trafic personnalisé pour des basculements précis de type canary ou linéaire. Pour les applications EC2 et sur site (on-prem), CodeDeploy prend en charge le blue/green avec des hooks de cycle de vie pour les validations avant le trafic et la restauration automatique en cas d’échec des vérifications de santé (health-check). Elastic Beanstalk fournit plusieurs politiques : All at Once (rapide, risqué), Rolling, Rolling with Additional Batch (plus sûr) et Immutable (le plus sûr), et vous pouvez les modifier avec eb deploy ou l’API update-environment en spécifiant DeploymentPolicy et OptionSettings. Les pièges courants pour les développeurs incluent l’oubli de configurer les vérifications de santé de l’application (santé du groupe cible ALB, rapports de santé EB), ce qui empêche le basculement automatique du trafic, et des autorisations IAM insuffisantes pour que CodeDeploy puisse invoquer Lambda ou mettre à jour ECS. Pour les mises en production s’appuyant sur une base de données, envisagez des modifications de schéma rétrocompatibles et des feature toggles (commutateurs de fonctionnalités) avant le déploiement pour éviter de coupler le code et le schéma dans la même transaction.

Pipelines de conteneurs, ECR, ECS/Fargate et EKS : build, déploiement et références immuables

Un pipeline de conteneurs robuste construit des images dans CodeBuild, les pousse vers ECR et déclenche le déploiement vers ECS, Fargate ou EKS. Dans CodeBuild, exécutez aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com, puis docker build -t repo:tag ., docker push, et capturez le digest de l’image via docker inspect –format=’{{index .RepoDigests 0}}’ image. Pour ECS/Fargate, enregistrez la nouvelle définition de tâche (ecs.registerTaskDefinition) avec le digest de l’image dans containerDefinitions, puis mettez à jour le service (ecs.updateService) pour utiliser la nouvelle définition de tâche ou définissez forceNewDeployment pour forcer un nouveau déploiement ; utilisez CodeDeploy pour les déploiements blue/green sur ECS

Validation pré-déploiement, rollbacks et observabilité : tests, hooks et garde-fous opérationnels

Intégrez des tests unitaires, d’intégration et de fumée (smoke tests) automatisés dans les étapes du pipeline. Utilisez CodeBuild pour exécuter les tests et AWS X-Ray ou CloudWatch Logs pour le traçage et les logs structurés ; annotez les traces X-Ray avec

undefined

dans les SDK pour que les requêtes en aval puissent filtrer par utilisateur ou par attributs de requête. Pour le pré-déploiement, employez des actions d’approbation manuelle dans CodePipeline ou des étapes de validation automatisées : exécutez des vérifications Canary via CodeBuild qui sollicitent le point de terminaison déployé, ou invoquez des canaries CloudWatch Synthetics pour exécuter des vérifications scriptées. Utilisez les hooks de cycle de vie de CodeDeploy (

undefined

,

undefined

) pour exécuter des vérifications de santé et une logique d’enregistrement/désenregistrement. Implémentez des déclencheurs de rollback automatique : configurez CodeDeploy pour effectuer un rollback en cas de statut de déploiement non nul ou d’alarmes échouées (alarmes CloudWatch attachées au groupe de déploiement), et pour Lambda, utilisez des alias avec répartition du trafic pour permettre un rollback rapide en mettant à jour l’alias pour qu’il pointe vers la version précédente. Les pièges pour les développeurs incluent des timeouts mal assortis (timeout Lambda plus court que le timeout de visibilité SQS), l’oubli de configurer correctement les hooks AppSpec pour ECS/CodeDeploy, et le fait de se fier au succès des appels d’API de déploiement sans valider le comportement d’exécution. Instrumentez les déploiements avec des métriques et des alertes, et utilisez des identifiants immuables dans les artefacts pour la traçabilité.

Problème pratique : Scénario d’utilisation

Scénario : ExampleRetail exploite une vitrine de microservices sur AWS à travers des comptes dev/test/prod. Ils utilisent CodeCommit pour la source, CodePipeline/CodeBuild pour la CI, ECR pour les images, ECS/Fargate pour les services derrière un ALB, et Lambda pour les workers asynchrones.

Défi : Un développeur doit ajouter un pipeline sûr et automatisé pour déployer un nouveau conteneur de service de paiement avec répartition de trafic canary et une validation pré-déploiement automatisée qui effectuera un rollback en cas d’échec.

Approche recommandée :

1. Créez un projet CodeBuild qui construit l’image Docker, exécute les tests unitaires, se connecte à ECR (

undefined

), pousse l’image, et émet un artefact JSON contenant le digest de l’image. 2. Dans CodePipeline, ajoutez une étape de déploiement qui enregistre une nouvelle définition de tâche ECS via

undefined

en référençant le digest de l’image, puis crée un déploiement CodeDeploy ECS en appelant

undefined

avec un AppSpec qui lie la nouvelle définition de tâche et un deploymentConfig défini pour le canary (par ex.,

undefined

). 3. Ajoutez une action de validation basée sur CodeBuild ou un canary CloudWatch Synthetics comme test post-déploiement qui appelle les points de terminaison critiques du service de paiement et valide les réponses ; faites en sorte que le pipeline attende la validation réussie. 4. Configurez les options de rollback de CodeDeploy et une alarme CloudWatch liée au groupe de déploiement (par ex., taux d’erreurs 5xx ou latence) pour annuler et effectuer un rollback automatiquement si les seuils sont dépassés.

Justification : La construction d’images immuables, l’enregistrement de définitions de tâches avec des digests d’image explicites, et l’utilisation de la répartition de trafic de CodeDeploy ainsi que de la validation automatisée permettent des déploiements canary sûrs et un rollback rapide et automatisé, tout en garantissant que les déploiements sont reproductibles et observables.

← CloudFormation et Infrastructure en tant que code (SAM · Tous les domaines · Sécurité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →