# CodePipeline: primeiro fluxo de CI/CD na AWS com Docker e GitHub

> Monte um pipeline no AWS CodePipeline que faz o deploy no Elastic Beanstalk a cada push no GitHub, com um projeto Node e React em Docker.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Containers
- URL: https://pages.formacaoaws.com.br/blog/codepipeline-primeiro-fluxo-cicd/
- Aula de origem: "Como criar o seu primeiro fluxo de CI/CD na AWS (do zero com projeto em Node, React e Docker)" (https://www.youtube.com/watch?v=O2TbkEhpfBE)

Um pipeline de CI/CD tira o deploy da máquina do desenvolvedor: você faz o push no GitHub e a AWS entrega a nova versão sozinha. Abaixo eu monto o primeiro fluxo do zero com o AWS CodePipeline, para um projeto em Node com React que roda em Docker e vai para o Elastic Beanstalk.

Gravei a aula em fevereiro de 2024. As telas do CodePipeline e do Beanstalk, os tipos de pipeline e os preços mudam com o tempo. Confira os tipos de pipeline na [documentação oficial](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types-planning.html) e os valores na [página de preços](https://aws.amazon.com/codepipeline/pricing/).

## O que o pipeline faz

Sem pipeline, o deploy sai da sua máquina direto para o ambiente na AWS. No dia a dia isso não escala, e por isso as empresas procuram um processo de deploy automatizado que não dependa da máquina do desenvolvedor.

O fluxo que montei é este: o projeto fica no GitHub; quando chega um push, o CodePipeline dispara, faz a integração contínua e a entrega contínua, e a nova versão chega ao Elastic Beanstalk. O CodePipeline é o serviço da AWS para essa finalidade.

![Sem pipeline, os fontes vão direto da máquina local para o Elastic Beanstalk (seta tracejada); com pipeline, vão para o GitHub, que dispara o CodePipeline, e ele entrega no Elastic Beanstalk](https://pages.formacaoaws.com.br/blog/assets/posts/codepipeline-primeiro-fluxo-cicd/desenho-fluxo-cicd.svg)

**Fluxo:** Push (commit no GitHub) → CodePipeline (etapa Source) → Deploy (provider Elastic Beanstalk) → Elastic Beanstalk (build do Dockerfile na EC2) → Aplicação (nova versão no ar)

Como o projeto usa Docker, o build da imagem acontece dentro do Beanstalk. A versão da aplicação sobe para a área **Application Versions**, e quando ela é baixada na instância o Beanstalk faz o build com base no seu Dockerfile. Por isso o pipeline deste exemplo não tem etapa de build.

## Passo 1: criar o ambiente no Elastic Beanstalk

Primeiro o ambiente, depois o pipeline. Os passos de criação eu cobri em outra aula, e o texto [Elastic Beanstalk com Docker](https://pages.formacaoaws.com.br/blog/elastic-beanstalk-com-docker/) mostra o caminho com zip. O que escolhi aqui:

- **Aplicação:** `bia`. O ambiente é para aplicação web, chamado `Bia-pipeline-youtube`.
- **Plataforma:** Docker, na versão mais recente. Nos quadros aparece "Docker running on 64bit Amazon Linux 2023/4.2.1".
- **Preset:** Single Instance, com capacidade 1.
- **Perfil da instância:** uma role com a policy `AWSElasticBeanstalkWebTier` (você cria a role e escolhe essa policy). A minha se chama `EC2 Beanstalk`.
- **Rede:** a rede padrão, com IP público e as zonas A, B e C.
- **Security group:** o meu, `BIA Web`, que só tem regra de entrada na porta 80.
- **Instância:** T3 Medium. O build acontece dentro da EC2, e uma máquina menor não aguenta. Não é uma instância da camada gratuita.

Monitoramento ficou no padrão, sem log stream e sem notificação, e o deploy acontece em 100% das instâncias de uma vez.

## Passo 2: o que o projeto precisa ter

O projeto é um fork da aplicação BIA, em Node com React, e já traz Dockerfile e `docker-compose.yml`. O Compose é peça fundamental para este pipeline:

```yaml
services:
  server:
    build: .
    container_name: bia
    ports:
      - 80:8080
```

O serviço `server` faz o build do contexto atual, lê o Dockerfile e publica a porta 80 do ambiente na 8080 do container. Em um deploy manual você usaria um script, o `eb deploy` ou um zip. Aqui quero que cada alteração no repositório dispare o deploy sozinha.

## Passo 3: criar o pipeline

No console do CodePipeline, clique em **Create pipeline** e configure:

- **Nome:** `bia-pipeline-youtube`.
- **Tipo:** V2.
- **Modo de execução:** Superseded. É o padrão do console. Se vier outro push antes de o deploy terminar, a execução mais recente passa por cima da mais antiga. Queued executa uma de cada vez, em fila, e Parallel executa ao mesmo tempo.
- **Service role:** nova. Deixe o CodePipeline criar a role que ele precisa. Variáveis e configurações avançadas dos artefatos ficam no padrão.

![A tela de criação do pipeline com o tipo V2 marcado e o modo de execução Superseded](https://pages.formacaoaws.com.br/blog/assets/posts/codepipeline-primeiro-fluxo-cicd/pipeline-v2-modo-superseded.webp)

## Passo 4: ligar o GitHub

Em **Source provider**, escolha o GitHub (versão 2). Em **Connection**, use uma conexão que já exista ou clique em conectar: abre uma janela, você cria o application, avança e escolhe os repositórios da sua conta que podem ser usados. Eu já tinha a conexão e já havia liberado alguns repositórios.

Depois escolha o repositório (o meu é `bia-pipeline-yt`) e o branch `main`. Em saída dos artefatos, deixei o padrão, **CodePipeline default**. Em trigger, não coloquei filtro.

> **Importante:** sem filtro, todo push, em qualquer branch, dispara o pipeline. Para limitar isso, o trigger pode ser customizado, e a [documentação do CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-filter.html) explica como.

## Passo 5: pular o build e configurar o deploy

Na etapa **Build provider** você colocaria testes e build. No meu caso o build da imagem acontece no Beanstalk, então ignorei essa etapa.

No **Deploy provider**, escolha o **AWS Elastic Beanstalk**, a região, a aplicação `bia` e o ambiente `Bia-pipeline-youtube`. Confira o resumo e clique em **Create pipeline**.

O pipeline nasce com duas etapas, Source e Deploy, e já dispara sozinho: ele pegou o último commit que eu tinha feito no GitHub e fez o deploy para o Beanstalk. Esse primeiro deploy é sem push, só a criação do pipeline.

## Passo 6: testar com um push

Na aplicação, o botão de adicionar era verde e o de fechar, preto. Alterei o `Header.js`: é um botão só, que alterna de estado: o texto de Fechar virou `Close` e o de adicionar virou `Add`, com o Add em azul e o Close em vermelho. Fiz commit e push com a mensagem "mudando para inglês".

O pipeline iniciou na hora: a etapa Source concluiu e o Deploy começou. O CodePipeline fica acompanhando o Beanstalk até o ambiente informar que a atualização terminou.

![O pipeline logo após o push mudando para inglês: Source com status Succeeded e Deploy em andamento no AWS Elastic Beanstalk](https://pages.formacaoaws.com.br/blog/assets/posts/codepipeline-primeiro-fluxo-cicd/pipeline-deploy-em-andamento.webp)

Quando o deploy terminou, abri a aplicação: o botão "Add" azul no lugar do verde. O histórico mostrou os dois deploys, o do primeiro disparo e o do push, ambos com sucesso.

![A aplicação BIA antes do push (botão Fechar preto, em português) e depois (botão Add azul)](https://pages.formacaoaws.com.br/blog/assets/posts/codepipeline-primeiro-fluxo-cicd/antes-e-depois-do-push.webp)

## Passo 7: desligar o que cobra

Acabou o teste, desalocar o ambiente: apague o pipeline e, no Beanstalk, encerre o ambiente para a instância parar de gerar custo.

Na aula eu disse que a camada gratuita traz 100 minutos de execução e que, passando disso, o custo por projeto é baixo (na gravação, em fevereiro de 2024, eu disse que achava que ficava em 1 ou 2 dólares por projeto). Esse número pode ter mudado: confira na [página de preços](https://aws.amazon.com/codepipeline/pricing/).

## Checklist

- Ambiente do Elastic Beanstalk criado com plataforma Docker, Single Instance e uma instância com memória para o build (T3 Medium).
- Projeto com Dockerfile e `docker-compose.yml` publicando a porta 80.
- Pipeline V2 criado, com a service role nova e o modo de execução escolhido.
- Conexão com o GitHub, repositório e branch `main` selecionados.
- Etapa de build ignorada e deploy configurado para o Elastic Beanstalk.
- Um push de teste que disparou o pipeline e mudou a aplicação.
- Pipeline apagado e ambiente encerrado depois do teste.

Esse é o primeiro fluxo, o mais simples: quem quer ir além acrescenta etapas de build e testes ao mesmo desenho.