View a markdown version of this page

Detecte alterações automaticamente e inicie diferentes CodePipeline pipelines para um monorepo em CodeCommit - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosSolução de problemasRecursos relacionados

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Detecte alterações automaticamente e inicie diferentes CodePipeline pipelines para um monorepo em CodeCommit

Helton Ribeiro, Petrus Batalha e Ricardo Morais, Amazon Web Services

Resumo

Aviso: não AWS Cloud9 está mais disponível para novos clientes. Os clientes existentes do AWS Cloud9 podem continuar usando o serviço normalmente. Saiba mais

Esse padrão ajuda você a detectar automaticamente alterações no código-fonte de um aplicativo baseado em monorepo AWS CodeCommit e, em seguida, iniciar um pipeline AWS CodePipeline que executa a integração contínua e a entrega contínua (CI/CD) automation for each microservice. This approach means that each microservice in your monorepo-based application can have a dedicated CI/CDpipeline), o que garante melhor visibilidade, compartilhamento mais fácil do código e melhor colaboração, padronização e capacidade de descoberta.

A solução descrita neste padrão não realiza nenhuma análise de dependência entre os microsserviços presentes no Monorepo. Ele só detecta alterações no código-fonte e inicia o pipeline correspondente CI/CD .

O padrão é usado AWS Cloud9 como ambiente de desenvolvimento integrado (IDE) e AWS Cloud Development Kit (AWS CDK) para definir uma infraestrutura usando duas CloudFormation pilhas: MonoRepoStack e. PipelinesStack A MonoRepoStack pilha cria o monorepo in AWS CodeCommit e a AWS Lambda função que inicia os pipelines. CI/CD A pilha PipelinesStack define sua infraestrutura de pipeline.

Importante

O fluxo de trabalho deste padrão é uma prova de conceito (PoC, na sigla em inglês). Recomendamos que você o utilize somente em um ambiente de teste. Se você quiser usar a abordagem desse padrão em um ambiente de produção, consulte as melhores práticas de segurança no IAM na documentação AWS Identity and Access Management (IAM) e faça as alterações necessárias em suas funções do IAM Serviços da AWS e. 

Pré-requisitos e limitações

Pré-requisitos

Arquitetura

O diagrama a seguir mostra como usar o AWS CDK para definir uma infraestrutura com duas AWS CloudFormation pilhas: MonoRepoStack e. PipelinesStack

Fluxo de trabalho para usar o AWS CDK para definir uma infraestrutura com duas CloudFormation pilhas.

O diagrama mostra o seguinte fluxo de trabalho:

  1. O processo de bootstrap usa o AWS CDK para criar as AWS CloudFormation pilhas e. MonoRepoStack PipelinesStack

  2. A MonoRepoStack pilha cria o CodeCommit repositório para seu aplicativo e a função monorepo-event-handler Lambda que é iniciada após cada confirmação.

  3. A PipelinesStack pilha cria os pipelines CodePipeline que são iniciados pela função Lambda. Cada microsserviço deve ter um pipeline de infraestrutura definido.

  4. O pipeline para microservice-n é iniciado pela função Lambda e inicia seus CI/CD estágios isolados baseados no código-fonte em. CodeCommit

  5. O pipeline para microservice-1 é iniciado pela função Lambda e inicia seus CI/CD estágios isolados baseados no código-fonte em. CodeCommit

O diagrama a seguir mostra a implantação das AWS CloudFormation pilhas MonoRepoStack e PipelinesStack em uma conta.

Implantação das CloudFormation pilhas MonoRepoStack e PipelinesStack em uma conta da AWS.

  1. Um usuário altera o código em um dos microsserviços do aplicativo.

  2. O usuário envia as alterações de um repositório local para um CodeCommit repositório.

  3. A atividade push inicia a função Lambda que recebe todos os push no repositório. CodeCommit

  4. A função do Lambda realiza a leitura de um parâmetro no Parameter Store, uma funcionalidade do AWS Systems Manager, para recuperar o ID da confirmação mais recente. O parâmetro tem o formato de nomenclatura:/MonoRepoTrigger/{repository}/{branch_name}/LastCommit. Se o parâmetro não for encontrado, a função Lambda lê o último ID de confirmação do CodeCommit repositório e salva o valor retornado no Parameter Store.

  5. Depois de identificar o ID do commit e os arquivos alterados, a função Lambda identifica os pipelines para cada diretório de microsserviços e inicia o pipeline necessário. CodePipeline

Ferramentas

  • AWS Cloud Development Kit (AWS CDK)é uma estrutura de desenvolvimento de software para definir a infraestrutura de nuvem em código e provisioná-la por meio dela. CloudFormation

  • O Python é uma linguagem de programação que facilita o trabalho ágil e a integração eficiente de sistemas.

Código

O código-fonte e os modelos desse padrão estão disponíveis no repositório de gatilhos multipipeline GitHub AWS CodeCommit monorepo.

Práticas recomendadas

Épicos

TarefaDescriptionHabilidades necessárias

Crie um ambiente virtual Python.

Em seu AWS Cloud9 IDE, crie um ambiente virtual em Python e instale as dependências necessárias executando o seguinte comando:

make install

Desenvolvedor

Inicialize o Conta da AWS e Região da AWS para o. AWS CDK

Inicialize o necessário Conta da AWS e a região executando o seguinte comando:

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

Desenvolvedor
TarefaDescriptionHabilidades necessárias

Adicione seu código de amostra ao diretório do aplicativo.

Adicione o diretório que contém o código do aplicativo de amostra ao monorepo-sample diretório no repositório clonado de gatilhos de vários GitHub AWS CodeCommit pipelines monorepo.

Desenvolvedor

Edite o arquivo monorepo-main.json.

Adicione o nome do diretório do código da sua aplicação e o nome do pipeline ao arquivo monorepo-main.json no repositório clonado.

Desenvolvedor

Criar o pipeline.

No diretório Pipelines do repositório, adicione a class do pipeline para sua aplicação. O diretório contém dois arquivos de amostra, nomeadamente pipeline_hotsite.py e pipeline_demo.py. Cada arquivo conta com três estágios: origem, desenvolvimento e implantação.

Você pode copiar um dos arquivos e alterá-lo de acordo com os requisitos do seu aplicativo. 

Desenvolvedor

Edite o arquivo monorepo_config.py.

Em service_map, adicione o nome do diretório do seu aplicativo e a classe que você criou para o pipeline.

Por exemplo, o código a seguir mostra uma definição de pipeline no diretório Pipelines que usa um arquivo nomeado pipeline_mysample.py com uma classe 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()
}
Desenvolvedor
TarefaDescriptionHabilidades necessárias

Implante a AWS CloudFormation pilha.

Implante a AWS CloudFormation MonoRepoStack pilha com valores de parâmetros padrão no diretório raiz do repositório clonado executando o comando. make deploy-core

Você pode alterar o nome do repositório executando o comando make deploy-core monorepo-name=<repo_name>.

nota

Você pode implantar simultaneamente ambos os pipelines usando o comando make deploy monorepo-name=<repo_name>.

Desenvolvedor

Valide o CodeCommit repositório.

Valide se seus recursos foram criados executando o comando aws codecommit get-repository --repository-name <repo_name>.

Importante

Como a CloudFormation pilha cria o CodeCommit repositório em que o monorepo é armazenado, não execute o cdk destroy MonoRepoStack  comando se você tiver começado a fazer modificações nele.

Desenvolvedor

Valide os resultados da CloudFormation pilha.

Valide se a CloudFormation MonoRepoStack pilha foi criada e configurada corretamente executando o seguinte comando:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
Desenvolvedor
TarefaDescriptionHabilidades necessárias

Implante a CloudFormation pilha.

A AWS CloudFormation PipelinesStack pilha deve ser implantada após a implantação da MonoRepoStack pilha. A pilha aumenta de tamanho quando novos microsserviços são adicionados à base de código do monorepo e é reimplantada quando um novo microsserviço é integrado.

Implante a PipelinesStack pilha executando o make deploy-pipelines comando.

nota

Você também pode implantar ambos os pipelines simultaneamente executando o comando make deploy monorepo-name=<repo_name>.

O exemplo de saída a seguir mostra como a PipelinesStacks implantação imprime URLs os microsserviços no final da implementação:

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

Valide os resultados da AWS CloudFormation pilha.

Valide se a AWS CloudFormation PipelinesStacks pilha foi criada e configurada corretamente executando o seguinte comando:

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
Desenvolvedor
TarefaDescriptionHabilidades necessárias

Exclua suas AWS CloudFormation pilhas.

Execute o comando make destroy.

Desenvolvedor

Exclua os buckets do S3 dos pipelines.

  1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon Simple Storage Service (Amazon S3).

  2. Exclua os buckets do S3 associados aos seus pipelines e use o seguinte nome: pipelinesstack-codepipeline*

Desenvolvedor

Solução de problemas

ProblemaSolução

Eu encontrei AWS CDK problemas.

Consulte Solução de AWS CDK problemas comuns na documentação do AWS CDK.

Eu enviei o código do meu microsserviço, mas o pipeline do microsserviço não foi executado.

Validação da configuração

Verifique a configuração da ramificação:

  • Certifique-se de que está enviando o código para a ramificação correta. Este pipeline está configurado para ser executado apenas quando mudanças são realizadas na ramificação main. Envios para outras ramificações não iniciam o pipeline, a menos que tenham sido configurados especificamente para isso.

  • Depois de enviar seu código, verifique se o commit está visível AWS CodeCommit para garantir que o push tenha sido bem-sucedido e que a conexão entre seu ambiente local e o repositório esteja intacta. Caso haja problemas no envio do código, atualize suas credenciais.

Valide os arquivos de configuração:

  • Confirme se a variável service_map presente no arquivo monorepo_config.py reflete com precisão a estrutura atual dos diretórios dos seus microsserviços. Esta variável é fundamental para mapear o envio do seu código ao pipeline correspondente.

  • Certifique-se de que o arquivo monorepo-main.json foi atualizado para incluir o novo mapeamento do seu microsserviço. Este arquivo é essencial para que o pipeline reconheça e trate corretamente as alterações no seu microsserviço.

Solução de problemas no console

AWS CodePipeline verificações:

  • No Console de gerenciamento da AWS, confirme se você está no Região da AWS local onde seu funil está hospedado. Abra o CodePipeline console e verifique se o pipeline que corresponde ao seu microsserviço foi iniciado.

    Análise de erros: se o pipeline foi iniciado, mas falhou, revise todas as mensagens de erro ou registros fornecidos pelo CodePipeline para entender o que deu errado.

AWS Lambda solução de problemas:

  • No console do AWS Lambda, abra a função do Lambda monorepo-event-handler. Verifique se a função foi iniciada em resposta ao envio de código.

    Análise de logs: examine os logs da função do Lambda para identificar possíveis problemas. Os logs podem fornecer insights detalhados sobre o que ocorreu quando a função foi executada e ajudar a verificar se a função processou o evento conforme esperado.

Preciso implantar novamente todos os meus microsserviços.

Existem duas abordagens para aplicar a reimplantação de todos os microsserviços. Escolha a opção que melhor se adequa às suas necessidades.

Abordagem 1: excluir um parâmetro no Parameter Store

Este método envolve excluir um parâmetro específico no Systems Manager Parameter Store, que rastreia o último ID de confirmação utilizado para a implantação. Ao remover esse parâmetro, o sistema será forçado a reimplantar todos os microsserviços no próximo acionamento, pois o considera um novo estado.

Etapas:

  1. Localize a entrada específica do Parameter Store que contém o ID da confirmação ou um marcador de implantação relacionado ao seu Monorepo. O nome do parâmetro segue este formato: "/MonoRepoTrigger/{repository}/{branch_name}/LastCommit"

  2. Se o valor do parâmetro for crítico ou você desejar manter um registro do estado da implantação antes de redefini-lo, considere fazer um backup.

  3. Use o Console de gerenciamento da AWS AWS CLI, ou SDKs para excluir o parâmetro identificado. Essa ação redefine o marcador de implantação.

  4. Após a exclusão, o próximo envio para o repositório deverá fazer o sistema implantar todos os microsserviços, pois ele buscará a confirmação mais recente para considerar na implantação.

Prós:

  • Simples e rápido de implementar, com o mínimo de etapas.

  • Não requer alterações arbitrárias no código para iniciar as implantações.

Contras:

  • Controle menos granular sobre o processo de implantação.

  • Pode ser arriscado se o Parameter Store for usado para gerenciar outras configurações críticas.

Abordagem 2: enviar uma confirmação em cada subpasta do Monorepo

Este método envolve fazer uma alteração pequena e enviá-la em cada subpasta de microsserviço no Monorepo para iniciar os pipelines individuais.

Etapas:

  1. Liste todos os microsserviços no Monorepo que necessitam de reimplantação.

  2. Para cada microsserviço, faça uma alteração mínima e sem impacto em sua subpasta. Isso pode ser atualizar um arquivo README, adicionar um comentário em um arquivo de configuração ou qualquer alteração que não afete a funcionalidade do serviço.

  3. Confirme essas alterações com uma mensagem clara (como “Iniciar reimplantação dos microsserviços”) e envie-as para o repositório. Certifique-se de enviar as alterações para a ramificação que inicia a implantação.

  4. Monitore os pipelines de cada microsserviço para confirmar que foram iniciados e concluídos com êxito.

Prós:

  • Oferece controle granular sobre quais microsserviços são reimplantados.

  • Mais seguro, pois não envolve a exclusão de parâmetros de configuração que possam ser usados para outros fins.

Contras:

  • Mais demorado, especialmente quando há um grande número de microsserviços.

  • Exige alterações desnecessárias no código, o que pode congestionar o histórico de confirmações.

Recursos relacionados