Una startup migró un sitio de comercio electrónico de alto tráfico a AWS y ahora necesita CI/CD que notifique a los ingenieros sobre compilaciones fallidas, proporcione implementaciones sin tiempo de inactividad y admita reversiones sin problemas. Los desarrolladores utilizan un repositorio privado de GitHub y Jenkins para las compilaciones y las pruebas unitarias. El equipo utilizará AWS CodePipeline para orquestar las compilaciones y las implementaciones. ¿Qué diseño satisface los requisitos de notificación, cero tiempo de inactividad y reversión?

La opción correcta aborda todos los requisitos. Los webhooks de GitHub son el mecanismo estándar para activar CodePipeline cuando hay cambios en el repositorio. El complemento de Jenkins para AWS CodeBuild permite ejecutar pruebas unitarias en CodeBuild, aprovechando la infraestructura de AWS. Amazon SNS es ideal para notificar a los ingenieros sobre fallos de compilación. La implementación blue/green con AWS CodeDeploy es la única opción que garantiza cero tiempo de inactividad y facilita las reversiones sin problemas, ya que mantiene la versión anterior en funcionamiento hasta que la nueva versión es completamente validada. Las opciones incorrectas fallan en uno o más aspectos: Usar websockets de GitHub no es el método estándar para activar CodePipeline. Una implementación in-place, all-at-once con CodeDeploy causa tiempo de inactividad y dificulta las reversiones. Usar AWS X-Ray para pruebas unitarias y análisis de código estático es incorrecto; X-Ray es para rastreo de solicitudes y análisis de rendimiento, no para pruebas unitarias. Combinar X-Ray para pruebas unitarias con una implementación in-place, all-at-once tiene los mismos defectos que las opciones anteriores.