De CI a CD
A CI verifica que o código está correto. A entrega/implantação contínua (CD) dá o passo seguinte: levar automaticamente esse código verificado a um ambiente onde ele é executado. Distingue-se:
- Continuous Delivery: o artefato fica pronto para implantar; a implantação final é aprovada manualmente.
- Continuous Deployment: cada mudança que passa na CI é implantada em produção sem intervenção manual.
O fluxo de implantação com contêineres
O padrão habitual quando você usa Docker é:
- Construir a imagem a partir do Dockerfile.
- Publicar (push) a imagem em um registro (Docker Hub, GitHub Container Registry, etc.), etiquetada com uma versão.
- Implantar: o ambiente baixa essa imagem e inicia contêineres novos.
Um job de CD que continua o de CI:
deploy:
needs: build # somente se o job de CI terminou bem
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Login no registro
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Construir e publicar imagem
run: |
docker build -t ghcr.io/minha-org/meu-app:${{ github.sha }} .
docker push ghcr.io/minha-org/meu-app:${{ github.sha }}
- name: Implantar
run: ./deploy.sh ghcr.io/minha-org/meu-app:${{ github.sha }}
Repare em needs: build: a implantação só ocorre se a CI passou. As
credenciais ficam em secrets, nunca no código.
Ambientes e aprovações manuais
Raramente se implanta direto em produção. O habitual é uma cadeia de
ambientes: staging (pré-produção, para validar) e depois production. A
passagem para produção costuma exigir uma aprovação manual de uma pessoa
responsável, que atua como porteiro de controle.
Rollback
Se uma implantação introduz uma falha, você precisa reverter rápido. Como cada versão é uma imagem imutável etiquetada, o rollback consiste em voltar a implantar a etiqueta anterior que funcionava. Ter imagens versionadas faz com que voltar atrás seja questão de segundos, não de horas.
Implantações pequenas e frequentes + imagens versionadas = risco baixo e recuperação rápida.