Análise do CI/CD - AWS Orientação prescritiva

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

Análise do CI/CD

Integração e entrega contínuas (CI/CD) é o processo de automatizar o ciclo de vida do lançamento do software. Em alguns casos, o D em CI/CD também pode significar implantação. A diferença entre entrega contínua e implantação contínua ocorre quando você libera uma alteração no ambiente de produção. Com a entrega contínua, é necessária uma aprovação manual antes de promover mudanças na produção. A implantação contínua apresenta um fluxo ininterrupto em todo o pipeline, e nenhuma aprovação explícita é necessária. Como essa estratégia analisa os conceitos gerais de CI/CD, as recomendações e as informações fornecidas são aplicáveis às abordagens de entrega contínua e implantação contínua.

O CI/CD automatiza muitos ou todos os processos manuais tradicionalmente necessários para obter um novo código de um commit na produção. Um pipeline de CI/CD abrange as etapas de origem, criação, teste, preparação e produção. Em cada etapa, os pipelines de CI/CD provisionam qualquer infraestrutura necessária para implantar ou testar o código. Ao usar um pipeline de CI/CD, as equipes de desenvolvimento podem fazer alterações no código que são automaticamente testadas e enviadas para implantação.

Vamos analisar o processo básico de CI/CD antes de discutir algumas das maneiras pelas quais você pode, consciente ou inconscientemente, se desviar do CI/CD totalmente automatizado. O diagrama a seguir mostra as etapas e as atividades de CI/CD em cada etapa.

As cinco etapa de um processo de CI/CD e as atividades e ambientes de cada um.

Sobre a integração contínua

A integração contínua ocorre em um repositório de código, como um repositório Git no GitHub. Você trata uma única ramificação principal como a fonte confiável da base de código, e cria ramificações de curta duração para o desenvolvimento de recursos. Você integrará uma ramificação de recurso à ramificação principal quando estiver pronto para implantar o recurso em ambientes superiores. As ramificações de recurso nunca são implantadas diretamente nos ambientes superiores. Para obter mais informações, consulte Abordagem baseada no trunk neste guia.

Processo de integração contínua

  1. O desenvolvedor cria uma nova ramificação da ramificação principal.

  2. O desenvolvedor faz alterações, cria e testa localmente.

  3. Quando as alterações estiverem prontas, o desenvolvedor criará uma pull request (documentação do GitHub) com a ramificação principal como destino.

  4. O código é revisado.

  5. Quando o código é aprovado, ele é incorporado à ramificação principal.

Sobre a entrega contínua

A entrega contínua ocorre em ambientes isolados, como ambientes de desenvolvimento e de produção. As ações que ocorrem em cada ambiente podem variar. Muitas vezes, uma das primeiras etapas é usada para fazer atualizações no próprio pipeline antes de continuar. O resultado final da implantação é que cada ambiente é atualizado com as alterações mais recentes. O número de ambientes de desenvolvimento para criação e teste também varia, mas recomendamos que você use pelo menos dois. No pipeline, cada ambiente é atualizado em ordem de importância, terminando com o ambiente mais importante, o ambiente de produção.

Processo de entrega contínua

A parte de entrega contínua do pipeline começa extraindo o código da ramificação principal do repositório de origem e passando-o para a etapa de criação. O documento de infraestrutura como código (IaC) do repositório descreve as tarefas que são executadas em cada etapa. Embora o uso de um documento de IaC não seja obrigatório, um serviço ou uma ferramenta de IaC, como AWS CloudFormation ou AWS Cloud Development Kit (AWS CDK), é altamente recomendado. As etapas mais comuns incluem:

  1. Testes de unidades

  2. Criação de código

  3. Provisionamento de recursos

  4. Testes de integração

Se algum erro ocorrer ou algum teste falhar em qualquer etapa do pipeline, a etapa atual voltará ao estado anterior e o pipeline será encerrado. As alterações subsequentes devem começar no repositório de código e passar por todo o processo de CI/CD.