Automatize o gerenciamento dinâmico de pipelines para implantar soluções de hotfix em ambientes Gitflow usando e AWS Service Catalog AWS CodePipeline - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosSolução de problemasRecursos relacionadosMais informações

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á.

Automatize o gerenciamento dinâmico de pipelines para implantar soluções de hotfix em ambientes Gitflow usando e AWS Service Catalog AWS CodePipeline

Balaji Vedagiri, Faisal Shahdad, Shanmugam Shanker e Vivek Thangamuthu, Amazon Web Services

Resumo

nota

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

Este padrão aborda um cenário de gerenciamento de um pipeline dinâmico de hotfix dedicado exclusivamente à implantação segura de soluções de hotfix em um ambiente de produção. A solução é implementada e gerenciada usando um AWS Service Catalog portfólio e um produto. Uma EventBridge regra da Amazon é usada para automação de eventos. As restrições são aplicadas usando as restrições do portfólio do Service Catalog e os perfis do AWS Identity and Access Management (IAM) para desenvolvedores. Somente uma AWS Lambda função tem permissão para iniciar o produto Service Catalog, acionada pela EventBridge regra. Este padrão foi projetado para ambientes com uma configuração específica do Gitflow, descrita em Informações adicionais.

Normalmente, um hotfix é implantado para resolver problemas críticos ou de segurança relatados em um ambiente ativo, como de produção. Os hotfixes devem ser implantados diretamente somente nos ambientes de preparação e produção. Os pipelines de preparação e produção são usados extensivamente para solicitações regulares de desenvolvimento. Esses pipelines não podem ser usados para implantar hotfixes porque há atributos contínuos de garantia de qualidade que não podem ser promovidos à produção. Para lançar hotfixes, este padrão descreve um pipeline dinâmico e de curta duração com os seguintes atributos de segurança:

  • Criação automática — Um pipeline de hotfix é criado automaticamente sempre que uma ramificação de hotfix é criada em um AWS CodeCommit repositório.

  • Restrições de acesso: os desenvolvedores não têm acesso para criar esse pipeline fora do processo de hotfix.

  • Estágio controlado: o pipeline tem um estágio controlado com um token de acesso especial, garantindo que uma solicitação de pull (PR) só possa ser criada uma vez.

  • Estágios de aprovação: os estágios de aprovação são incluídos no pipeline para obter as aprovações necessárias das partes interessadas relevantes.

  • Exclusão automática — O pipeline de hotfix é excluído automaticamente sempre que uma hotfix ramificação é excluída no CodeCommit repositório após ser mesclada com um PR.

Pré-requisitos e limitações

Pré-requisitos

  • Contas da AWS São necessários três ativos da seguinte forma:

    • Conta de ferramentas: para a configuração de integração contínua e entrega contínua (CI/CD).

    • Conta de preparação: para testes de aceitação do usuário.

    • Conta de produção: para um usuário final comercial.

    • (Opcional) Adicione uma Conta da AWS para atuar como uma conta de controle de qualidade. Essa conta é necessária se você quiser uma configuração de pipeline principal, incluindo controle de qualidade, e uma solução de pipeline de hotfix para testes.

  • Uma AWS CloudFormation pilha com uma condição opcional para ser implantada na conta de controle de qualidade usando o pipeline principal, se necessário. O padrão ainda pode ser testado sem a configuração do pipeline principal, criando e excluindo uma ramificação hotfix.

  • Um bucket do Amazon Simple Storage Service (Amazon S3) para armazenar CloudFormation os modelos usados para criar produtos do Service Catalog.

  • Crie regras de aprovação de relações públicas para o CodeCommit repositório de acordo com os requisitos de conformidade (depois de criar o repositório).

  • Restrinja as permissões do IAM de desenvolvedores e líderes de equipe para negar a execução da função do Lambda prcreation-lambda, pois ela deve ser invocada somente pelo pipeline.

Limitações

  • O CloudFormation provedor é usado no estágio de implantação e o aplicativo é implantado usando um conjunto de CloudFormation alterações. Se você quiser usar uma opção de implantação diferente, modifique a CodePipeline pilha conforme necessário.

  • Esse padrão usa outros arquivos AWS CodeBuild de configuração para implantar um microsserviço de amostra. Se você tiver um tipo de workload diferente (por exemplo, workloads com tecnologia sem servidor), deverá atualizar todas as configurações relevantes.

  • Esse padrão implanta o aplicativo em um único lado Região da AWS (por exemplo, Leste dos EUA (Norte da Virgínia) us-east-1). Contas da AWS Para implantar em várias regiões, altere a referência da região em comandos e pilhas.

  • Alguns Serviços da AWS não estão disponíveis em todos Regiões da AWS. Para conferir a disponibilidade de uma região, consulte AWS Services by Region. Para endpoints específicos, consulte Service endpoints and quotas e clique no link correspondente ao serviço desejado.

Arquitetura

Os diagramas nesta seção fornecem fluxos de trabalho para um evento do ciclo de vida de criação e para um evento do ciclo de vida de exclusão.

Fluxo de trabalho para criar um evento de ciclo de vida.

O diagrama anterior para criar um evento de ciclo de vida mostra o seguinte:

  1. O desenvolvedor cria uma hotfix-* ramificação no CodeCommit repositório para desenvolver uma solução relacionada ao hotfix.

  2. O evento de criação da hotfix-* ramificação é capturado por meio da EventBridge regra. Os detalhes do evento incluem o nome do repositório e o nome da ramificação.

  3. A EventBridge regra invoca a AWS Lambda função. hotfix-lambda-function A EventBridge regra passa as informações do evento para a função Lambda como entrada.

  4. A função do Lambda processa a entrada para recuperar o nome do repositório e o nome da ramificação. Ele lança o produto do Service Catalog com valores recuperados da entrada processada.

  5. O produto do Service Catalog inclui uma configuração de pipeline que implantará a solução nos ambientes de preparação e produção. O bloco de pipeline inclui estágios de origem, compilação e implantação. Além disso, há um estágio de aprovação manual para promover a implantação no ambiente de produção.

  6. O estágio de origem recupera o código do repositório e da ramificação hotfix-* que foram criados na primeira etapa. O código é passado para o estágio de compilação por meio de um bucket do Amazon S3 para artefatos. No estágio de compilação, é criada uma imagem de contêiner que inclui o hotfix que é desenvolvido na ramificação hotfix-* e enviado ao Amazon Elastic Container Registry (Amazon ECR).

  7. O estágio de implantação ao ambiente de estágio atualiza o Amazon Elastic Container Service (Amazon ECS) com a imagem de contêiner mais recente que inclui o hotfix. O hotfix é implantado criando e executando um CloudFormation conjunto de alterações.

  8. A função prcreation-lambda do Lambda é invocada após a implantação bem-sucedida no ambiente de preparação. Essa função do Lambda cria uma PR com base na ramificação hotfix-* para as ramificações develop e main do repositório. A função do Lambda garante que a correção desenvolvida na ramificação hotfix-* seja mesclada novamente e incluída nas implantações subsequentes.

  9. Um estágio de aprovação manual ajuda a garantir que as partes interessadas necessárias revisem a correção e aprovem a implantação na produção.

  10. O estágio de implantação ao ambiente de produção atualiza o Amazon ECS com a imagem de contêiner mais recente que inclui o hotfix. O hotfix é implantado criando e executando um CloudFormation conjunto de alterações.

Fluxo de trabalho para excluir um evento de ciclo de vida.

O diagrama anterior para excluir um evento de ciclo de vida mostra o seguinte:

  1. O desenvolvedor exclui a ramificação hotfix-* após a implantação bem-sucedida do hotfix no ambiente de produção.

  2. O evento de exclusão da hotfix-* ramificação é capturado por meio de uma EventBridge regra. Os detalhes do evento incluem o nome do repositório e o nome da ramificação.

  3. A EventBridge regra invoca a função Lambda. A EventBridge regra passa as informações do evento para a função Lambda como entrada.

  4. A função do Lambda processa a entrada para recuperar o nome do repositório e o nome da ramificação. A função do Lambda determina o respectivo produto do Service Catalog com base na entrada passada e, em seguida, encerra o produto.

  5. O encerramento do produto provisionado pelo Service Catalog exclui o pipeline e os recursos relevantes que foram criados anteriormente nesse produto.

Automação e escala

  • O padrão inclui uma EventBridge regra e uma função Lambda, que podem lidar com várias solicitações de criação de ramificações de hotfix em paralelo. A função do Lambda provisiona o produto do Service Catalog para a regra de evento correspondente.

  • A configuração do pipeline é feita usando o produto do Service Catalog, que fornece recursos de controle de versão. A solução também se expande automaticamente para lidar com vários desenvolvimentos de hotfix para a mesma aplicação em paralelo.

  • A função prcreation-lambda garante que essas alterações de hotfix também sejam mescladas novamente nas ramificações main e develop por meio de uma criação automática de solicitação de pull. Essa abordagem é essencial para manter as ramificações main e develop atualizadas com todas as correções e evitar possíveis regressões de código. Esse processo ajuda a manter a consistência entre as ramificações e evitar regressões de código, garantindo que todas as ramificações de longa duração tenham as correções mais recentes.

Ferramentas

Serviços da AWS

  • AWS CloudFormationajuda você a configurar AWS recursos, provisioná-los de forma rápida e consistente e gerenciá-los durante todo o ciclo de vida em Contas da AWS e. Regiões da AWS

  • O AWS CodeBuild é um serviço de compilação totalmente gerenciado que permite compilar o código-fonte, realizar testes de unidade e produzir artefatos preparados para a implantação.

  • O AWS CodeCommit é um serviço de controle de versão que ajuda no armazenamento e no gerenciamento de repositórios Git de forma privada, sem a necessidade de administrar o próprio sistema de controle de origem. O AWS CodeCommit não está mais disponível para novos clientes. Os clientes existentes do AWS CodeCommit podem continuar usando o serviço normalmente. Para obter mais informações, consulte Como migrar seu AWS CodeCommit repositório para outro provedor Git.

  • O AWS CodePipeline ajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software, além de automatizar as etapas necessárias para a implantação contínua de alterações.

  • O Amazon Elastic Container Registry (Amazon ECR) é um serviço gerenciado de registro de imagens de contêineres seguro, escalável e confiável.

  • O Amazon Elastic Container Service (Amazon ECS) é um serviço de gerenciamento de contêineres escalável e rápido que facilita a execução, a interrupção e o gerenciamento de contêineres em um cluster.

  • AWS Key Management Service (AWS KMS) ajuda você a criar e controlar chaves criptográficas para ajudar a proteger seus dados.

  • AWS Service Catalogajuda você a gerenciar centralmente catálogos de serviços de TI aprovados. AWS Os usuários finais podem implantar rapidamente somente os serviços de TI aprovados de que precisam, seguindo as restrições definidas pela organização.

  • O Amazon Simple Storage Service (Amazon S3) é um serviço de armazenamento de objetos baseado na nuvem que ajuda você a armazenar, proteger e recuperar qualquer quantidade de dados.

Outras ferramentas

Repositório de código

O código desse padrão está disponível no repositório GitHub dynamic_hotfix_codepipeline.

Práticas recomendadas

Analise e ajuste os perfis do IAM e as políticas de controle de serviços (SCP) em seu ambiente para garantir que elas restrinjam o acesso de forma adequada. Isso é crucial para evitar quaisquer ações que possam anular as medidas de segurança incluídas neste padrão. Respeite o princípio de privilégio mínimo, garantindo somente as permissões estritamente necessárias para a execução de uma tarefa. Para obter mais informações, consulte Concessão de privilégio mínimo e Práticas recomendadas de segurança na documentação do IAM.

Épicos

TarefaDescriptionHabilidades necessárias

Clonar o repositório.

Para clonar o repositório de amostra em um novo diretório em seu local de trabalho, execute o seguinte comando:

git clone git@github.com:aws-samples/dynamic_hotfix_codepipeline.git
AWS DevOps

Exporte variáveis de ambiente para implantação CloudFormation de pilha.

Defina as seguintes variáveis de ambiente que serão usadas como entrada para as CloudFormation pilhas posteriormente nesse padrão.

  • ApplicationName: essa variável é usada para nomear recursos criados para uma aplicação, facilitando o rastreamento deles. Use o seguinte comando, substituindo Applicationname pelo nome real da aplicação: 

    export ApplicationName=<Applicationname>

  • BucketStartName: essa variável serve para nomear um bucket do Amazon S3. Os nomes dos buckets do S3 devem ser globalmente exclusivos em todos Contas da AWS. Use o seguinte comando, substituindo BucketName por um nome exclusivo do seu bucket do S3:

export BucketStartName=<BucketName>

  • Números de conta e regiões — Essas variáveis armazenam Conta da AWS números de diferentes ambientes e da região de implantação. Use os comandos a seguir, substituindo os espaços reservados (como prodaccountnumber eregion) pelos Conta da AWS números reais e pelos Região da AWS que você está usando.

    nota

    QAAccount é opcional. Se você quiser usar QAAccount, configure-o usando os parâmetros da pilha principal do pipeline.

export ProdAccount=<prodaccountnumber>
export StageAccount=<stage/preprodaccountnumber>
export QAAccount=<qaccountnumber>
export ToolsAccount=<toolsaccountnumber>
export DepRegion=<region>
AWS DevOps
TarefaDescriptionHabilidades necessárias

Crie os recursos necessários CI/CD na conta de ferramentas.

Para implantar a CloudFormation pilha na conta de ferramentas, use os comandos a seguir. (Remova o parâmetro QAAccount se você não estiver usando a conta de controle de qualidade para configuração.)

#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

Anote os recursos que o CodeCommit repositório e o Amazon ECR criaram a partir da pilha anterior. Esses parâmetros são necessários para configurar a ramificação main do pipeline nas próximas etapas.

AWS DevOps

Crie os recursos necessários CI/CD nas contas de carga de trabalho.

  1. Para empacotar o CloudFormation modelo em cada conta de carga de trabalho (estágio, produção e controle de qualidade opcional), use os comandos a seguir. No seguinte comando, substitua S3bucketpackage pelo nome do bucket do Amazon S3 que você deseja usar para empacotar.

    #InStageAccount
aws cloudformation package \
    --template-file pre-requisites/infrastack.yaml \
    --s3-bucket <S3bucketpackage> \
    --s3-prefix infraStack \
    --region ${DepRegion} \
    --output-template-file pre-requisites/infrastructure_stage.template

#InProdAccount
aws cloudformation package \
    --template-file pre-requisites/infrastack.yaml \
    --s3-bucket <S3bucketpackage> \
    --s3-prefix infraStack \
    --region ${DepRegion} \
    --output-template-file pre-requisites/infrastructure_prod.template

  2. Para implantar o CloudFormation modelo em cada conta de carga de trabalho, use os seguintes comandos:

    #InStageAccount
aws cloudformation deploy --stack-name inframainstack \
--parameter-overrides  ApplicationName=${ApplicationName} ToolsAccount=${ToolsAccount} DepRegion=${DepRegion} \
--template-file pre-requisites/infrastructure_stage.template  --region ${DepRegion} --capabilities CAPABILITY_NAMED_IAM

#InProdAccount
aws cloudformation deploy --stack-name inframainstack \
--parameter-overrides  ApplicationName=${ApplicationName} ToolsAccount=${ToolsAccount} DepRegion=${DepRegion} \
--template-file pre-requisites/infrastructure_prod.template  --region ${DepRegion} --capabilities CAPABILITY_NAMED_IAM
AWS DevOps

Atualize a política de bucket de artefatos do S3 para permitir o acesso às contas de workload.

Para atualizar os pré-requisitos da CloudFormation pilha na conta de ferramentas, use os comandos a seguir para adicionar todas as permissões necessárias para as contas de carga de trabalho de estágio e produção. (Remova o parâmetro QAAccount se você não o estiver usando para configuração.)

#InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/pre-reqs.yaml \
    --stack-name prereqs \
    --parameter-overrides BucketStartName=${BucketStartName} \
    ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
    StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
    QAAccount=${QAAccount} PutPolicy=true \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
AWS DevOps
TarefaDescriptionHabilidades necessárias

Configure o portfólio e os produtos do Service Catalog.

Para configurar o portfólio e os produtos do Service Catalog, faça o seguinte:

  1. Faça o upload dos modelos pipeline-main.yaml e pipeline-hotfix.yaml do repositório no diretório CodePipeline para um bucket existente do Amazon S3 () na região em que você deseja implantar (). Bucketname DepRegion

    #InToolsAccount
aws s3 cp ./codepipeline/pipeline-main.yaml s3://<Bucketname>/pipeline-main.yaml
aws s3 cp ./codepipeline/pipeline-hotfix.yaml s3://<Bucketname>/pipeline-hotfix.yaml

  2. Configure o portfólio e o produto do Service Catalog que vão gerenciar o pipeline das ramificações main e hotfix. Anote os detalhes da seção Outputs para MainProductId e MainProductArtifactId da pilha a seguir. As informações são necessárias em etapas posteriores durante o pipeline de configuração da ramificação main.

    #InToolsAccount
aws cloudformation deploy \
    --template-file pre-requisites/servicecatalogsetup.yaml \
    --stack-name servicecatalogsetup \
    --parameter-overrides TemplateBucket=<Bucketname> \
    --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

  3. Forneça acesso a um perfil do IAM que implantará recursos na conta de ferramentas no portfólio principal do pipeline do portfólio Service Catalog. Use esse portfólio para implantar a aplicação usando a ramificação main. Para obter mais informações sobre como fornecer acesso, consulte Granting Access to Users na documentação do Service Catalog.

AWS DevOps

Configure as funções do Lambda.

Essa solução usa as seguintes funções do Lambda para gerenciar fluxos de trabalho de hotfix:

  • hotfix-lambda-function executa o provisionamento de produtos do Service Catalog quando uma ramificação hotfix é criada.

  • hotfix-cleanup-lambda-function gerencia o encerramento do produto quando uma ramificação hotfix é excluída.

  • prcreation-lambda cria solicitações de pull da ramificação hotfix para as ramificações develop e main.

Para permitir que as funções do Lambda provisionem e encerrem produtos do Service Catalog quando hotfix ramificações são criadas ou excluídas por meio da EventBridge regra associada, use as seguintes etapas:

  1. Para criar as funções e permissões do IAM para as funções do Lambda, use o comando a seguir para implantar uma CloudFormation pilha:

    #InToolsAccount aws cloudformation deploy \ --template-file pre-requisites/lambdasetup.yaml \ --stack-name prsclambdasetup \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}

  2. Após a implantação da pilha, conceda o acesso hotfix-lambda-execution-role ao portfólio do pipeline de hotfix do portfólio Service Catalog usando o Console de gerenciamento da AWS. Esse acesso permite que a função do Lambda inicie ou encerre o produto do Service Catalog para ramificações de hotfix.

AWS DevOps
TarefaDescriptionHabilidades necessárias

Configure o pipeline da ramificação main.

Para configurar o pipeline da ramificação principal, execute o comando a seguir na conta de ferramentas. Substitua os parâmetros de MainProductId e MainProductArtifactId por valores das saídas da pilha servicecatalogsetup.

#InToolsAccount
aws servicecatalog provision-product \
    --product-id <MainProductId> \
    --provisioning-artifact-id <MainProductArtifactId> \
    --provisioned-product-name "${ApplicationName}-main-pipeline" \
    --provisioning-parameters Key=CodeCommitRepoName,Value="${ApplicationName}-repository" Key=ECRRepository,Value="${ApplicationName}-app" \
    --region=${DepRegion}
AWS DevOps

Implante a aplicação usando a ramificação main.

  1. Para clonar o CodeCommit repositório que foi criado nos pré-requisitos, use o comando. git clone Para obter mais informações, consulte Conectar-se ao CodeCommit repositório clonando o repositório conforme descrito na documentação. CodeCommit

  2. Copie todos os arquivos da aplicação do diretório repotemplates disponível no repositório para o clone local do seu repositório (${ApplicationName}-repository). Modifique os arquivos a seguir para atualizar o ID ToolsAccount. Em cada arquivo, localize o parâmetro RegistryAccountid e defina esse valor como seu ID ToolsAccount. Confirme as alterações no CodeCommit repositório e envie os arquivos para as develop ramificações main e para as ramificações.

  3. Para verificar a implantação do aplicativo, monitore a CodePipeline execução usando Console de gerenciamento da AWS o. Após a conclusão da implantação, acesse a aplicação usando o FQDN do Application Load Balancer no ambiente de preparação. Confirme se a aplicação funciona conforme o esperado.

  4. Para aprovar a implantação para produção, use o CodePipeline console para localizar o pipeline do seu aplicativo. Encontre o estágio ApprovalToStart. Analise as alterações e, se satisfatórias, forneça aprovação manual para continuar com a implantação da produção.

AWS DevOps
TarefaDescriptionHabilidades necessárias

Crie uma ramificação hotfix-* e confirme as alterações.

Para criar um pipeline para a ramificação hotfix-* e implantar o hotfix nas contas de workload, faça o seguinte:

  1. Crie uma ramificação usando um nome que inicie com a palavra-chave hotfix. Por exemplo, esse padrão usa a hotfix-check1 ramificação no repositório do CodeCommit aplicativo (${ApplicationName}-repository). Para obter etapas mais detalhadas, consulte Conectar a um AWS CodeCommit repositório e os comandos básicos do Git na CodeCommit documentação.

  2. Verifique se o produto Hotfix CICD Pipeline do Service Catalog foi provisionado dinamicamente com sucesso para a ramificação hotfix-check1. O nome do produto provisionado tem o nome dessa ramificação do hotfix e o nome do repositório do CodeCommit aplicativo.

  3. Confirme algumas pequenas alterações no arquivo index.html e envie-as para o CodeCommit repositório.

  4. Verifique se a CodePipeline execução foi bem-sucedida no ambiente de palco. Para implantar no ambiente de produção, forneça aprovação manual em CodePipeline.

  5. Verifique se as alterações estão visíveis na página inicial da aplicação usando o nome de domínio totalmente qualificado (FQDN) do Application Load Balancer. O FQDN está disponível na seção Outputs de inframainstack-ALBStack-*.

AWS DevOps

Exclua a ramificação hotfix-check1.

Para excluir a ramificação hotfix-check1 criada anteriormente, faça o seguinte:

  1. Exclua a hotfix-check1 ramificação que está no repositório do CodeCommit aplicativo.

  2. Verifique se o produto do Service Catalog que foi provisionado para a ramificação hotfix-check1 foi encerrado com êxito.

AWS DevOps
TarefaDescriptionHabilidades necessárias

Limpe os recursos implantados.

Para limpar os recursos que foram implantados anteriormente, faça o seguinte:

  1. Para reduzir a escala verticalmente do serviço Amazon ECS para zero réplicas nas contas de workload, use o seguinte comando:

    aws ecs update-service --cluster ${ApplicationName}-Cluster --service ${ApplicationName}-Service-stage --desired-count 0 --region ${DepRegion}
aws ecs update-service --cluster ${ApplicationName}-Cluster --service ${ApplicationName}-Service-prod --desired-count 0 --region ${DepRegion}

  2. Encerre o produto do Service Catalog que foi provisionado para a ramificação main.

  3. Limpe objetos criados nos buckets do Amazon S3 na conta de ferramentas. Exclua todas as imagens do Docker no Amazon ECR antes de excluir o registro em si.

  4. Remova os perfis do IAM na seção de acesso concedido dos portfólios do Service Catalog antes de excluir o portfólio do Service Catalog.

  5. Exclua as CloudFormation pilhas implantadas na conta de ferramentas e nas contas de carga de trabalho.

##In Tools Account##
aws cloudformation delete-stack --stack-name servicecatalogsetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prlambdasetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prereqs --region ${DepRegion}
##In Workload Accounts##
aws cloudformation delete-stack --stack-name inframainstack --region ${DepRegion}

Para obter mais informações, consulte Deleting provisioned products na documentação do Service Catalog.

AWS DevOps

Solução de problemas

ProblemaSolução

As alterações que você confirmou no CodeCommit repositório não estão sendo implantadas.

Verifique se há erros nos CodeBuild registros na ação de compilação do Docker. Para obter mais informações, consulte a documentação do CodeBuild .

O produto do Service Catalog não está sendo provisionado.

Analise as CloudFormation pilhas relacionadas em busca de eventos com falha. Para obter mais informações, consulte a documentação do CloudFormation .

Recursos relacionados

Mais informações

Esse padrão foi projetado para ambientes com uma configuração do Gitflow que é adotada para o fluxo de trabalho de desenvolvimento no CI/CD processo. Os pipelines seguem o ciclo de implantação que começa no desenvolvimento e passa pelos ambientes de garantia de qualidade (QA), preparação e produção. A CI/CD configuração inclui duas ramificações do git com implantações promocionais em ambientes da seguinte forma:

  • A ramificação develop é implantada no ambiente de desenvolvimento.

  • A ramificação main é implantada nos ambientes de controle de qualidade, preparação e produção.

Nessa configuração, é um desafio aplicar um hotfix ou um patch de segurança mais rápido do que o ciclo normal de implantação enquanto o desenvolvimento ativo de novos recursos está em andamento. É necessário um processo dedicado para atender às solicitações de hotfix ou segurança, garantindo que os ambientes ativos permaneçam funcionando adequadamente e com segurança.

No entanto, você pode usar outras opções disponíveis sem precisar de um processo de implantação dedicado se:

  • O CI/CD processo está bem equipado com testes automatizados, como testes funcionais e end-to-end testes, que eliminam a necessidade de testes manuais e evitam atrasos nas implantações na produção. No entanto, se os testes automatizados não estiverem bem integrados ao CI/CD processo, fazer uma pequena correção no ambiente de produção pode se tornar complexo e complicado para os desenvolvedores. Isso ocorre porque é possível que novos recursos estejam no ambiente de controle de qualidade aguardando aprovação e liberação. Um hotfix ou correção de segurança não pode ser colocado em produção de forma direta e simultânea.

  • As equipes de desenvolvimento implantam continuamente novos recursos no ambiente de produção, integrando hotfixes ou patches de segurança na implantação programada de cada novo recurso. Em outras palavras, a próxima atualização de recursos para o ambiente de produção compreende dois componentes: a adição de um novo recurso e a inclusão do hotfix ou patch de segurança. No entanto, se o ciclo de implantação não for contínuo, pode haver vários novos recursos já aguardando aprovação no ambiente de controle de qualidade. Gerenciar versões diferentes e garantir que as alterações corretas sejam reaplicadas pode se tornar um trabalho complexo e propenso a erros.

nota

Se você estiver usando a versão 2 do AWS CodePipeline com os acionadores adequados configurados na hotfix ramificação, ainda precisará de um processo dedicado para atender às solicitações não programadas. Na versão 2, você pode configurar gatilhos para solicitações de push ou pull. A execução será colocada em fila ou executada imediatamente, dependendo do estado anterior do pipeline. No entanto, com um pipeline dedicado, as correções são aplicadas imediatamente ao ambiente de produção, garantindo que problemas urgentes sejam resolvidos sem demora.