Construyendo un sofisticado CodePipeline con CDK en una configuración de Monorepo

Hola. Imagina que comenzaste como ingeniero de DevOps de AWS en una pequeña empresa y tu jefe quiere que vayamos por completo con AWS. Por supuesto, el CICD debe estar completamente en AWS para implementaciones automatizadas. Toda la infraestructura debe estar en código. Y estamos utilizando un monorepo que contiene un backend y frontend, ambos en TypeScript.

Genial. Has estado trabajando con GitLab CI o GitHub Actions donde solo necesitas definir el archivo YAML y crea en la plataforma la canalización por ti. En AWS, es un poco diferente. Cada recurso debes crearlo tú mismo. Por lo tanto, decidiste utilizar AWS CDK porque puedes usar TypeScript. Puedes utilizar las mismas herramientas que los desarrolladores. Puedes poner el código dentro de su monorepo. Y también tienes una buena abstracción, que también puede entender el desarrollador.

Pongamos manos a la obra. Comienzas creando una canalización utilizando esta nueva abstracción de canalización. Y cada canalización de código contiene etapas. Y una etapa contiene acciones. Las acciones generan resultados y producen un artefacto. Este artefacto se puede almacenar en un bucket de S3. Por lo tanto, importas el código desde CodeCommit donde se encuentra alojado el monorepo. Y puedes usarlo para crear tu primera etapa utilizando el comando 'add stage'. Y aquí creas la acción de origen de CodeCommit. Por lo tanto, esto se activará cada vez que ocurra algo en la rama principal. Y creas una segunda etapa utilizando la acción de fragmento de código. Y allí utilizas un proyecto de fragmento de código. Puedes definir cada fase del proyecto de fragmento de código. En este caso, utilizo la fase de construcción, donde quiero instalar el linting y las pruebas unitarias. Y el resultado de esta acción se puede almacenar en esta carpeta en este caso. Y ahora las siguientes etapas son las etapas de implementación. Por lo tanto, deseas implementar en diferentes cuentas de AWS.

Por lo tanto, creas el bucle de todas las cuentas. Y también puedes hacer uso de la abstracción de CDK. Por lo tanto, puedes crear tu propio método, en este caso, el proyecto de creación de canalización. Entonces, en lugar de usar este código, nuevamente, puedes hacerlo más fácil abstrayéndolo y colocándolo en tu propio método, y luego simplemente hacer uso de cada fase. Primero, asumes el rol y luego utilizas el comando CDK deploy. Y después de eso, después de la implementación, puedes ejecutar pruebas de integración. También puedes utilizar operaciones de mantenimiento. Como puedes ver en los entornos de puesta en escena y producción, tenemos la aprobación manual. Y esta acción de aprobación manual, puedes combinarla con la acción corporativa. Por lo tanto, solo si no está en def, de lo contrario, simplemente omitimos la acción de aprobación manual. Pero cada vez que haya un cambio en el front-end, también se implementará el back-end. Entonces, ¿cómo lo manejas? Para eso, necesitas crear múltiples canalizaciones. Ahora tienes una canalización para el front-end, y otra canalización para el back-end. Este podría ser el código, cómo se ve. Por lo tanto, puedes encontrar múltiples canalizaciones, y puedes manejarlo utilizando variables de entorno.

Pero la verdadera pregunta será cuándo activar qué canalización. Y la solución para eso es utilizar EventBridge y Lambda de AWS. Así que debes saber que cada servicio de AWS emite un evento. En este caso, cada vez que algo sucede en el repositorio de código, queremos capturar este evento. Queremos capturarlo utilizando EventBridge. Y queremos decirle a la canalización: `Oye, utiliza EventBridge para emitir este evento`. Y este evento será luego enviado a una función Lambda. Definimos la función Lambda aquí. Con este código, nos aseguramos de tener solo una función Lambda. De lo contrario, crearíamos múltiples funciones Lambda.

Pero con este código, nos aseguramos de tener esta función Lambda solo una vez. La función Lambda utiliza el comando de diferencias de confirmación de código. Así verifica qué archivo ha cambiado y luego activa la canalización en consecuencia. Dentro de la función Lambda, definimos cada canalización. Creamos un objeto donde tenemos la canalización de la pila de front-end, la canalización de la pila de back-end y la canalización de la pila de front-end y back-end. También definimos cuándo se debe activar esta canalización. Aquí definimos la ruta de cada canalización.

Entonces, en este caso, cada vez que cambie un archivo en la carpeta de back-end o cambiemos algo en la pila de back-end, se debe activar la canalización de la pila de back-end. También tenemos la capacidad de tener una carpeta común. Digamos que tienes un paquete que se comparte entre el back-end y el front-end. Y para eso, podemos utilizar el operador de propagación para activar todas las canalizaciones. Utilizamos el SDK de JavaScript para confirmación de código y canalización de código. Y el controlador utiliza el comando de obtener diferencias para obtener todos los cambios de archivos. Luego recorremos cada canalización y recorremos cada ruta de canalización para verificar si el nombre del archivo forma parte del cambio. Y si es así, comenzamos a ejecutar la canalización de código.

Lo que hemos visto aquí es que podemos utilizar CDK para hacer que la canalización de código sea menos complicada. También podemos hacer algo como la ingeniería de plataformas para utilizar la abstracción de manera que cada vez que crees una nueva canalización, puedas utilizar ciertos métodos como el método de creación de proyecto de canalización. Podemos utilizar EventBridge para activar cada canalización en consecuencia. Por lo tanto, también podemos decir que cada vez que haya una nueva solicitud de extracción, activamos la canalización, o hay muchos otros eventos que puedes verificar, puedes encontrar en línea. Y con eso, puedes crear canalizaciones sofisticadas. Gracias. Encontrarás toda la información aquí. También puedes encontrar el repositorio. Y gracias por tu tiempo.