Deploy

Um deploy manual quase nunca falha na primeira vez. Ele falha na décima segunda, numa quinta-feira à noite, quando a pessoa que conhece a ordem exata dos comandos está de férias e quem a substitui inverte dois passos. Um procedimento escrito num arquivo DEPLOIEMENT.md sempre acaba divergindo do que realmente se faz, porque nada verifica se ele está atualizado. Um workflow, por sua vez, é o procedimento: se estiver errado, ele falha, e você fica sabendo.

Automatizar um deploy, porém, não é simplesmente adicionar um último job à sua cadeia de testes. Três perguntas precisam ser respondidas antes de escrever uma linha: sob qual condição exata o deploy é disparado, qual artefato preciso é publicado e como se volta ao estado anterior. A terceira é a que mais costuma ser adiada, e é a que sai mais cara no dia em que falta. Um deploy automático sem rollback preparado apenas acelera a chegada dos incidentes à produção.

A condição de disparo

O deploy deve ser disparado em um caso, e somente um: um commit mesclado na branch principal, com todas as verificações em verde.

name: Deploiement

on:
  push:
    branches: [main]

concurrency:
  group: deploiement-production
  cancel-in-progress: false

permissions:
  contents: read

jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: npm
      - run: npm ci
      - run: npm test

  deployer:
    needs: tests
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://exemple.com
    steps:
      - run: echo "Deploiement en cours"