AWS CodePipeline, CodeBuild, CodeDeploy

A tríade CodePipeline, CodeBuild e CodeDeploy compõe o serviço de integração e entrega contínua gerenciado da AWS, no qual orquestração, build e implantação são recursos da própria nuvem, cobrados por uso e sem servidor para administrar. O CodePipeline desenha o fluxo de estágios e aprovações, o CodeBuild executa compilação e testes em ambientes efêmeros definidos por um buildspec.yml, e o CodeDeploy implanta o artefato em EC2, ECS ou Lambda guiado por um appspec.yml. A vantagem estrutural é a integração nativa: credenciais via IAM, gatilhos via EventBridge, artefatos no S3 e permissões finas por recurso, tudo dentro do mesmo plano de controle. Em produção, esse conjunto é a resposta natural quando o runtime inteiro já vive na AWS e o time prefere absorver as peculiaridades da plataforma a operar um CI externo com acesso à infraestrutura.

Conceito e papel de cada serviço

Os três serviços têm fronteiras claras e se combinam como peças de um mesmo fluxo. Confundi-los é o erro mais comum de quem inicia na plataforma, e a tabela abaixo fixa o papel de cada um:

O pipeline é declarado como recurso AWS, versionável por CloudFormation ou Terraform, e cada estágio encadeia ações de tipos diferentes, source no CodeCommit ou GitHub, build no CodeBuild, deploy no CodeDeploy, além de ações manuais de aprovação e verificações externas via Lambda.

A consequência prática desse desenho é que o pipeline deixa de ser configuração viva de uma ferramenta e passa a ser infraestrutura sob controle de versão. Criar um pipeline novo para um serviço é aplicar um template já revisado; ajustar a política de deploy é uma pull request com revisão técnica; auditar quem mudou o processo de entrega é histórico de commits. Organizações com dezenas de times tratam essa propriedade como requisito de governança, e a stack nativa a entrega sem esforço adicional.

O problema que resolve

O conjunto elimina dois custos característicos de CI externo na AWS. O primeiro é o de credencial: um pipeline Jenkins ou GitHub Actions que precisa implantar na AWS carrega chaves de longa duração ou montagens de federação; com os serviços nativos, cada ação assume um role IAM com permissão mínima, sem segredo estático em lugar nenhum. O segundo é o de alcance: CodeDeploy conhece grupos de auto scaling, target groups do load balancer e serviços do ECS por dentro, e executa estratégias de implantação, como blue-green em ECS, que em ferramentas externas exigiriam scripts complexos e frágeis. Para times com runtime inteiramente na AWS, o resultado é menos cola entre pipeline e infraestrutura e um caminho de auditoria dentro do mesmo plano de controle.

CodeBuild e o buildspec.yml

O CodeBuild executa cada job em um container efêmero, com tamanho de computação escolhido por build e sem estado persistente entre execuções. O comportamento é definido no buildspec.yml, que vive no repositório e descreve variáveis, fases e artefatos de saída:

version: 0.2

env:
  variables:
    APP_NAME: "pedidos"        # nome base da imagem construída
  secrets-manager:
    DB_URI: pedidos/homolog:uri  # segredo injetado do Secrets Manager

phases:
  install:
    runtime-versions:
      nodejs: 20               # runtime fixado para reprodutibilidade
  pre_build:
    commands:
      - npm ci                 # instalação determinística pelo lockfile
  build:
    commands:
      - npm run lint           # verificação estática rápida
      - npm test -- --coverage # suíte unitária com cobertura
      - docker build -t $APP_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION .
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
      - docker push $ECR_URI/$APP_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION
  post_build:
    commands:
      - echo "Build concluído em $(date)"

artifacts:
  files:
    - appspec.yml              # appspec viaja junto do artefato
    - taskdef.json             # definição da task para deploy em ECS
  base-directory: deploy

Os pontos que separam uso profissional de uso casual são três: runtime fixado por versão, segredos vindos do Secrets Manager sem passar pelo repositório e tag de imagem derivada do SHA do commit, o que mantém rastreabilidade ponta a ponta entre release e código.

CodeDeploy e o appspec.yml

O CodeDeploy implanta o artefato guiado pelo appspec.yml, que descreve o que instalar e como validar. O comportamento muda por plataforma de destino, e é aí que a ferramenta mostra valor sobre scripts genéricos. Em EC2, o agente do CodeDeploy no host executa hooks de ciclo de vida, como parar a aplicação, copiar a nova versão e reiniciar, com rollback automático quando os alarmes de CloudWatch disparam durante a janela de monitoração. Em ECS, o serviço reescreve a task definition e conduz a troca entre conjuntos de tasks usando target groups do load balancer. Em Lambda, o tráfego é deslocado entre versões da função com validação por hooks. O exemplo abaixo descreve um appspec para ECS:

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "<TASK_DEFINITION>"   # substituída pelo CodeDeploy
        LoadBalancerInfo:
          ContainerName: "pedidos"
          ContainerPort: 8080

Hooks:                                         # validação no meio da troca
  - BeforeAllowTraffic: "validate-migrations"
  - AfterAllowTraffic: "validate-smoke"

Estratégias de implantação por destino

A escolha da plataforma de destino determina o comportamento do deploy, e a tabela resume as combinações que aparecem em produção:

O parâmetro decisivo na escolha é o custo do rollback. Blue-green em ECS mantém o conjunto antigo vivo até a confirmação, e a volta é instantânea; in-place em EC2 sobrescreve o host, e a volta depende de reimplantação ou de imagens de máquina anteriores. Times com exigência de reversão em segundos convergem para blue-green ou Lambda, mesmo quando o custo de capacidade dupla temporária incomoda.

Integração com IAM e eventos

A integração com o resto da plataforma é o argumento central da stack. Cada ação do pipeline assume um role específico, o que permite restringir por estágio, o build pode escrever no ECR e o deploy pode mexer apenas no serviço ECS de produção, por exemplo. Os eventos fluem por EventBridge, e o pipeline pode ser disparado por push em repositório, por imagem publicada no ECR ou por qualquer evento customizado, enquanto o andamento de cada execução publica eventos consumíveis por SNS, Slack via Lambda ou sistema de alerta corporativo. Essa composição transforma o pipeline em componente observável da infraestrutura, em vez de ferramenta paralela com vida própria.

A operação diária acontece majoritariamente por CLI, o que facilita automação e diagnóstico rápido:

# Dispara execução manual do pipeline após hotfix aprovado
aws codepipeline start-pipeline-execution --name pedidos-pipeline

# Consulta o estado de cada estágio da execução em curso
aws codepipeline get-pipeline-state --name pedidos-pipeline

# Lista as execuções recentes com resultado e horário
aws codepipeline list-pipeline-executions --pipeline-name pedidos-pipeline --max-items 10

Os alarmes completam o ciclo operacional: notificação por SNS para falha de estágio, métrica de duração de execução publicada no CloudWatch e alerta dedicado quando a taxa de rollback em produção cruza o limiar definido pelo time.

Aplicação prática: fluxo completo típico

O fluxo de referência em produção combina as peças assim: push em main dispara o pipeline; o CodeBuild roda lint, testes e constrói a imagem com tag do SHA; uma aprovação manual libera o estágio de produção; o CodeDeploy conduz blue-green no ECS com validação por alarmes; o rollback é automático quando a métrica de erro cruza o limiar na janela de monitoração. Dois cuidados práticos separam implantação confiável de demonstração:

• Permissão por estágio: roles distintos por ação, com o deploy de produção restrito ao ambiente correto, evita que um erro de configuração implante em produção sem passar pelo gate.
• Espaço para validação: hooks AfterAllowTraffic que exercitam o serviço com tráfego controlado antes de liberar 100 por cento, transformando a estratégia em segurança real e não em teoria.

Comparações: stack AWS versus ferramentas de terceiros

A escolha objetiva segue a forma do runtime: serviço inteiramente na AWS com necessidade de deploy sofisticado favorece a stack nativa; times multi-nuvem ou com ecossistema GitHub forte mantêm o CI externo e usam o CodeDeploy isolado quando a estratégia de implantação dele compensa.

Erros comuns e boas práticas

Os erros abaixo aparecem com frequência em adoções da stack:

• Pipeline com permissão ampla demais: ação única com role que cobre build e produção; separação por estágio é a correção de maior impacto em segurança.
• appspec desatualizado no artefato: hooks antigos sobrevivendo em artefatos novos porque ninguém versiona o deploy junto do código; appspec no repositório e no artefato evita a deriva.
• Rollback não testado: estratégia blue-green nunca exercitada em falha real; simular o rollback em homologação é pré-requisito de confiança.
• Segredos em variáveis de ambiente simples: credenciais fixadas no buildspec em texto puro; Secrets Manager ou Parameter Store com referência no buildspec eliminam o vazamento.
• Buildspec gigante e sem dono: lógica de negócio embutida nas fases do build; scripts versionados chamados pelo buildspec mantêm a configuração enxuta.
• Gate de aprovação simulado: ação de aprovação manual aceita por qualquer pessoa com acesso ao pipeline; o gate vale quando está associado a um grupo IAM específico e registrado em auditoria.

Entre as boas práticas que sustentam a stack em produção, três se destacam. Declarar pipeline, build e infraestrutura de deploy por código, em CloudFormation ou Terraform, com o mesmo rigor de revisão do restante do sistema. Travar versões de runtime e imagens do CodeBuild para que builds do mesmo commit sejam reproduzíveis meses depois. E monitorar o pipeline como serviço, com alarmes para duração, taxa de falha e rollbacks executados, porque a automação de entrega é parte do plano de produção e merece o mesmo nível de observação da aplicação que ela coloca no ar.