Uma startup migrou um site de e-commerce de alto tráfego para a AWS e agora precisa de CI/CD que notifique os engenheiros sobre falhas de build, forneça implantações sem tempo de inatividade e suporte rollbacks contínuos. Os desenvolvedores usam um repositório privado do GitHub e Jenkins para builds e testes de unidade. A equipe usará o AWS CodePipeline para orquestrar builds e implantações. Qual design satisfaz os requisitos de notificação, tempo de inatividade zero e rollback?

A opção correta utiliza webhooks do GitHub para acionar o CodePipeline, o que é o método padrão e eficiente para integração com repositórios externos. O plugin Jenkins para AWS CodeBuild permite que o Jenkins continue sendo usado para testes de unidade, aproveitando a infraestrutura existente. Notificações via Amazon SNS são ideais para alertar engenheiros sobre falhas de build. A implantação blue/green com AWS CodeDeploy é crucial para implantações sem tempo de inatividade e facilita rollbacks rápidos, pois mantém a versão antiga em execução até que a nova seja totalmente validada. As opções incorretas falham em um ou mais requisitos: Usar websockets do GitHub não é o método padrão para acionar o CodePipeline; webhooks são mais apropriados. Implantações in-place, all-at-once com CodeDeploy não garantem tempo de inatividade zero e dificultam rollbacks contínuos. Usar AWS X-Ray para testes de unidade e análise de código estática é inadequado; o X-Ray é para rastreamento de aplicações distribuídas, não para execução de testes de unidade.