Une startup a migré un site e-commerce à fort trafic vers AWS et a maintenant besoin d'un CI/CD qui avertit les ingénieurs des échecs de build, permet des déploiements sans interruption de service et prend en charge des restaurations transparentes. Les développeurs utilisent un dépôt GitHub privé et Jenkins pour les builds et les tests unitaires. L'équipe utilisera AWS CodePipeline pour orchestrer les builds et les déploiements. Quelle conception satisfait aux exigences de notification, de zéro interruption de service et de restauration ?

La bonne réponse satisfait toutes les exigences. Les webhooks GitHub déclenchent CodePipeline, ce qui est standard pour l'intégration de dépôts externes. L'utilisation du plugin Jenkins pour AWS CodeBuild permet de réutiliser les tests unitaires Jenkins existants tout en bénéficiant de la scalabilité de CodeBuild. Amazon SNS est le service AWS approprié pour les notifications d'échec de build. Enfin, le déploiement blue/green avec CodeDeploy garantit des déploiements sans interruption de service et des restaurations transparentes en basculant le trafic vers une nouvelle version après validation, tout en conservant l'ancienne version disponible pour une restauration rapide. Les options incorrectes échouent sur plusieurs points : Les websockets GitHub ne sont pas le mécanisme standard pour déclencher CodePipeline ; ce sont les webhooks. AWS X-Ray est un service de traçage distribué et d'analyse de performance, non adapté aux tests unitaires ou à l'analyse statique du code. Le déploiement in-place avec CodeDeploy peut entraîner des interruptions de service et ne permet pas de restaurations aussi transparentes qu'un déploiement blue/green.