Detecta automáticamente los cambios e inicia diferentes CodePipeline canalizaciones para un monorepo en CodeCommit - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaHerramientasPrácticas recomendadasEpicsResolución de problemasRecursos relacionados

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Detecta automáticamente los cambios e inicia diferentes CodePipeline canalizaciones para un monorepo en CodeCommit

Creada por Helton Ribeiro (AWS), Petrus Batalha () y Ricardo Morais () AWS AWS

AWS CodeCommit Repositorio de código: activadores multicanalización de monorepo

Entorno: PoC o piloto

Tecnologías: infraestructura, DevOps sin servidor

AWSservicios: AWS CodeCommit AWS CodePipeline; AWS Lambda

Resumen

Este patrón le ayuda a detectar automáticamente los cambios en el código fuente de una aplicación basada en monorepo AWS CodeCommit y, a continuación, a iniciar una canalización AWS CodePipeline que ejecute la automatización de la integración y la entrega continuas (CI/CD) para cada microservicio. Este enfoque significa que cada microservicio de su aplicación basada en monorepo puede tener una canalización de CI/CD dedicada, lo que garantiza una mejor visibilidad, un intercambio de código más sencillo y una mayor colaboración, estandarización y capacidad de descubrimiento.

La solución descrita en este patrón no realiza ningún análisis de dependencia entre los microservicios del monorepo. Solo detecta los cambios en el código fuente e inicia la canalización de CI/CD correspondiente.

El patrón AWS Cloud9 se utiliza como entorno de desarrollo integrado (IDE) y AWS Cloud Development Kit (AWS CDK) para definir una infraestructura mediante dos AWS CloudFormation pilas: y. MonoRepoStack PipelinesStack La MonoRepoStack pila crea la entrada monorepo AWS CodeCommit y la AWS Lambda función que inicia las canalizaciones de CI/CD. La pila PipelinesStack define su infraestructura de canalizaciones.

Importante: El flujo de trabajo de este patrón es una prueba de concepto (PoC). Le recomendamos que lo use solo en un entorno de prueba. Si quieres utilizar el enfoque de este patrón en un entorno de producción, consulta las prácticas recomendadas de seguridad IAM en la documentación de AWS Identity and Access Management (IAM) y realiza los cambios necesarios en tus IAM funciones y Servicios de AWS. 

Requisitos previos y limitaciones

Requisitos previos 

Arquitectura

En el siguiente diagrama se muestra cómo utilizar el AWS CDK para definir una infraestructura con dos AWS CloudFormation pilas: y. MonoRepoStack PipelinesStack

Flujo de trabajo para usar el AWS CDK para definir una infraestructura con dos CloudFormation pilas.

En el diagrama, se muestra el siguiente flujo de trabajo:

  1. El proceso de arranque utiliza el AWS CDK para crear las AWS CloudFormation pilas MonoRepoStack y. PipelinesStack

  2. La MonoRepoStack pila crea el CodeCommit repositorio para la aplicación y la función monorepo-event-handler Lambda que se inicia después de cada confirmación.

  3. La PipelinesStack pila crea las canalizaciones CodePipeline iniciadas por la función Lambda. Cada microservicio debe tener una canalización de infraestructura definida.

  4. La canalización para microservice-n la inicia la función Lambda e inicia sus etapas de CI/CD aisladas que se basan en el código fuente de. CodeCommit

  5. La canalización para microservice-1 la inicia la función Lambda e inicia sus etapas de CI/CD aisladas que se basan en el código fuente de. CodeCommit

El siguiente diagrama muestra el despliegue de las AWS CloudFormation pilas MonoRepoStack y PipelinesStack en una cuenta.

Despliegue de las CloudFormation pilas MonoRepoStack y PipelinesStack en una AWS cuenta.

  1. Un usuario cambia el código de uno de los microservicios de la aplicación.

  2. El usuario envía los cambios de un repositorio local a un CodeCommit repositorio.

  3. La actividad de envío inicia la función Lambda que recibe todos los envíos al repositorio. CodeCommit

  4. La función Lambda lee un parámetro del almacén de parámetros, una capacidad de AWS Systems Manager, para recuperar el ID de confirmación más reciente. El parámetro tiene el formato de denominación:/MonoRepoTrigger/{repository}/{branch_name}/LastCommit. Si no se encuentra el parámetro, la función Lambda lee el último ID de confirmación del CodeCommit repositorio y guarda el valor devuelto en el almacén de parámetros.

  5. Tras identificar el ID de confirmación y los archivos modificados, la función Lambda identifica las canalizaciones de cada directorio de microservicios e inicia la canalización requerida. CodePipeline

Herramientas

  • AWS Cloud Development Kit (AWS CDK)es un marco de desarrollo de software para definir la infraestructura de nube en código y aprovisionarla mediante ella. AWS CloudFormation

  • Python es un lenguaje de programación que permite trabajar con rapidez e integrar sistemas de forma más eficaz.

Código

El código fuente y las plantillas de este patrón están disponibles en el repositorio de activadores multicanalización de GitHub AWS CodeCommit monorepo.

Prácticas recomendadas

Epics

TareaDescripciónHabilidades requeridas

Cree un entorno virtual de Python.

En su AWS Cloud9 IDE interior, cree un entorno virtual de Python e instale las dependencias necesarias ejecutando el siguiente comando:

make install

Desarrollador

Arranca el Cuenta de AWS y Región de AWS para el. AWS CDK

Inicie la región Cuenta de AWS y requerida ejecutando el siguiente comando:

make bootstrap account-id=<your-AWS-account-ID> region=<required-region>

Desarrollador
TareaDescripciónHabilidades requeridas

Añada su código de muestra al directorio de su aplicación.

Añada el directorio que contiene el código de la aplicación de muestra al monorepo-sample directorio del repositorio clonado de GitHub AWS CodeCommit monorepo multi-pipeline triggers.

Desarrollador

Edite el archivo monorepo-main.json.

Agrega el nombre del directorio del código de tu aplicación y el nombre de la canalización al monorepo-main.json archivo del repositorio clonado.

Desarrollador

Cree la canalización.

En el Pipelines directorio del repositorio, agrega la canalización class de tu aplicación. El directorio contiene dos archivos de ejemplo pipeline_hotsite.py ypipeline_demo.py. Cada archivo tiene tres etapas: origen, compilación e implementación.

Puede copiar uno de los archivos y modificarlo según los requisitos de su aplicación. 

Desarrollador

Edite el archivo monorepo_config.py.

En service_map, añada el nombre del directorio de su aplicación y la clase que creó para la canalización.

Por ejemplo, en el siguiente código, se muestra una definición de canalización en el directorio Pipelines que usa un archivo llamado pipeline_mysample.py con una clase MySamplePipeline:

...
# Pipeline definition imports
from pipelines.pipeline_demo import DemoPipeline
from pipelines.pipeline_hotsite import HotsitePipeline
from pipelines.pipeline_mysample import MySamplePipeline

### Add your pipeline configuration here
service_map: Dict[str, ServicePipeline]  = {
    # folder-name -> pipeline-class
    'demo': DemoPipeline(),
    'hotsite': HotsitePipeline(),
    'mysample': MySamplePipeline()
}
Desarrollador
TareaDescripciónHabilidades requeridas

Despliegue la AWS CloudFormation pila.

Ejecute el make deploy-core comando para implementar la AWS CloudFormation MonoRepoStack pila con los valores de los parámetros predeterminados en el directorio raíz del repositorio clonado.

Puede cambiar el nombre del repositorio si ejecuta el comando make deploy-core monorepo-name=<repo_name>.

Nota: Puede implementar ambas canalizaciones simultáneamente mediante el comando make deploy monorepo-name=<repo_name>.

Desarrollador

Valide el CodeCommit repositorio.

Valide si sus recursos se crearon mediante la ejecución del comando aws codecommit get-repository --repository-name <repo_name>.

Importante: dado que la AWS CloudFormation pila crea el CodeCommit repositorio en el que se almacena el monorepo, no ejecute el cdk destroy MonoRepoStack  comando si ha empezado a introducir modificaciones en él.

Desarrollador

Valide los resultados de la AWS CloudFormation pila.

Valide que la AWS CloudFormation MonoRepoStack pila se haya creado y configurado correctamente ejecutando el siguiente comando:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
Desarrollador
TareaDescripciónHabilidades requeridas

Despliegue la AWS CloudFormation pila.

La AWS CloudFormation PipelinesStack pila debe desplegarse después de MonoRepoStack desplegarla. La pila aumenta de tamaño cuando se añaden nuevos microservicios al código base del monorepo y se vuelve a implementar cuando se incorpora un nuevo microservicio.

Implemente la PipelinesStack pila ejecutando el make deploy-pipelines comando.

Nota: También puede ejecutar el comando make deploy monorepo-name=<repo_name> para implementar simultáneamente ambas canalizaciones.

El siguiente ejemplo de resultado muestra cómo la PipelinesStacks implementación imprime URLs los microservicios al final de la implementación:

Outputs:
PipelinesStack.demourl = .cloudfront.net
PipelinesStack.hotsiteurl = .cloudfront.net
Desarrollador

Valide los resultados de la AWS CloudFormation pila.

Valide que la AWS CloudFormation PipelinesStacks pila se haya creado y configurado correctamente ejecutando el siguiente comando:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
Desarrollador
TareaDescripciónHabilidades requeridas

Elimina tus AWS CloudFormation pilas.

Ejecute el comando make destroy.

Desarrollador

Elimine los buckets de S3 para sus canalizaciones.

  1. Inicie sesión en la consola AWS Management Consolede Amazon Simple Storage Service (Amazon S3) y ábrala.

  2. Elimine los buckets de S3 que están asociados a sus canalizaciones y utilice el siguiente nombre: pipelinesstack-codepipeline*

Desarrollador

Resolución de problemas

ProblemaSolución

He encontrado problemas AWS CDK .

Consulte Solución de AWS CDK problemas comunes en la AWS CDK documentación.

Inserté mi código de microservicio, pero la canalización de microservicios no funcionó.

Validación de la configuración

Verifique la configuración de la sucursal:

  • Asegúrese de enviar el código a la rama correcta. Esta canalización está configurada para ejecutarse solo cuando se realizan cambios en la main rama. Los envíos a otras ramas no inician la canalización a menos que estén configurados específicamente.

  • Después de insertar el código, comprueba si la confirmación está visible AWS CodeCommit para asegurarte de que la inserción se ha realizado correctamente y de que la conexión entre tu entorno local y el repositorio está intacta. Actualiza tus credenciales si hay problemas al insertar el código.

Valide los archivos de configuración:

  • Confirme que la service_map variable refleja monorepo_config.py con precisión la estructura de directorios actual de sus microservicios. Esta variable desempeña un papel crucial a la hora de mapear el envío de código a la canalización correspondiente.

  • Asegúrese de que monorepo-main.json esté actualizado para incluir el nuevo mapeo para su microservicio. Este archivo es esencial para que la canalización reconozca y gestione correctamente los cambios en el microservicio.

Solución de problemas en la consola

AWS CodePipeline comprueba:

  • En el AWS Management Console, confirma que estás en el Región de AWS lugar donde está alojada tu canalización. Abre la CodePipeline consola y comprueba si se ha iniciado la canalización correspondiente a tu microservicio.

    Análisis de errores: si la canalización se inició pero falló, revise los mensajes de error o los registros proporcionados por usted CodePipeline para saber qué es lo que ha fallado.

AWS Lambda solución de problemas:

  • En la AWS Lambda consola, abra la función monorepo-event-handler Lambda. Compruebe que la función se haya iniciado en respuesta a la inserción del código.

    Análisis de registros: examine los registros de la función Lambda para detectar cualquier problema. Los registros pueden proporcionar información detallada sobre lo que ocurrió cuando se ejecutó la función y ayudar a identificar si la función procesó el evento según lo esperado.

Necesito volver a implementar todos mis microservicios.

Existen dos enfoques para forzar la redistribución de todos los microservicios. Elija la opción que mejor se adapte a sus necesidades.

Método 1: Eliminar un parámetro del almacén de parámetros

Este método implica eliminar un parámetro específico del almacén de parámetros de Systems Manager que rastrea el último ID de confirmación utilizado para la implementación. Al eliminar este parámetro, el sistema se ve obligado a volver a implementar todos los microservicios en el siguiente activador, ya que lo percibe como un estado nuevo.

Pasos:

  1. Busca la entrada específica del almacén de parámetros que contiene el ID de confirmación o un marcador de despliegue relacionado con tu monorepo. El nombre del parámetro sigue el formato: "/MonoRepoTrigger/{repository}/{branch_name}/LastCommit"

  2. Considere la posibilidad de hacer una copia de seguridad del valor del parámetro si es crítico o si desea mantener un registro del estado de despliegue antes de restablecerlo.

  3. Utilice AWS Management Console AWS CLI, o SDKs para eliminar el parámetro identificado. Esta acción restablece el marcador de despliegue.

  4. Tras la eliminación, la siguiente inserción en el repositorio debería provocar que el sistema despliegue todos los microservicios, ya que buscará la última confirmación que tenga en cuenta para el despliegue.

Ventajas:

  • Sencillo y rápido de implementar con unos pasos mínimos.

  • No es necesario realizar cambios arbitrarios en el código para iniciar las implementaciones.

Desventajas:

  • Control menos detallado sobre el proceso de implementación.

  • Potencialmente riesgoso si el almacén de parámetros se utiliza para gestionar otras configuraciones críticas.

Método 2: Inserte una confirmación en cada subcarpeta de monorepo

Este método implica realizar un cambio menor e insertarlo en cada subcarpeta de microservicios del monorepo para iniciar sus canalizaciones individuales.

Pasos:

  1. Enumere todos los microservicios del monorepo que necesitan ser redistribuidos.

  2. Para cada microservicio, realice un cambio mínimo y sin impacto en su subcarpeta. Esto puede consistir en actualizar un README archivo, añadir un comentario en un archivo de configuración o realizar cualquier cambio que no afecte a la funcionalidad del servicio.

  3. Confirme estos cambios con un mensaje claro (como «Inicie la redistribución de los microservicios») y envíelos al repositorio. Asegúrese de enviar los cambios a la rama que inicia la implementación.

  4. Supervise las canalizaciones de cada microservicio para confirmar que se han iniciado y completado correctamente.

Ventajas:

  • Proporciona un control detallado sobre los microservicios que se vuelven a implementar.

  • Es más seguro porque no implica eliminar los parámetros de configuración que podrían usarse para otros fines.

Desventajas:

  • Consume más tiempo, especialmente con una gran cantidad de microservicios.

  • Requiere realizar cambios de código innecesarios que podrían saturar el historial de confirmaciones.

Recursos relacionados