O que é CI/CD

Sem automação, fazer deploy de código costuma ser assim: você termina uma mudança, lembra de rodar os testes (ou não), compacta o projeto, envia e reinicia a aplicação. Cada passo é uma chance de esquecer algo, e quem conhece a rotina vira gargalo.

O CI/CD troca essa rotina por um script que roda do mesmo jeito em toda mudança. É prática comum em equipes de software e funciona também em escala pequena, para uma pessoa só com um bot ou uma API.

O que significa CI/CD?#

CI/CD junta duas ideias que costumam ser confundidas:

• CI, integração contínua: quem programa junta as próprias mudanças numa branch compartilhada com frequência, e cada junção dispara um build e uma rodada de testes automáticos. O objetivo é achar uma mudança quebrada minutos depois de escrita, não semanas depois.
• CD, entrega contínua ou deploy contínuo: a parte que vem depois da CI. A mudança aprovada é empacotada e segue para produção.

É no "D" que a confusão começa, porque ele significa duas coisas diferentes.

Qual a diferença entre entrega contínua e deploy contínuo?#

As duas automatizam tudo até a publicação. A diferença está no último passo:

Deploy contínuo não é "melhor". Ele exige testes em que você confia, porque ninguém segura uma mudança ruim no final. Muitas equipes começam com entrega contínua e aprovação manual, e só tiram a aprovação quando os testes conquistam essa confiança.

Como funciona um pipeline de CI/CD?#

Um pipeline é a sequência de etapas automáticas pela qual uma mudança passa. Um pipeline típico funciona assim:

1. Gatilho. Um evento inicia a execução: um push numa branch, um pull request, uma release publicada, um agendamento ou um clique manual.
2. Checkout. Uma máquina limpa recebe uma cópia do código naquele commit.
3. Build. As dependências são instaladas e o projeto é compilado ou empacotado.
4. Testes. Rodam os testes unitários e, às vezes, linters, checagem de tipos e testes de integração. Se algo falha, o pipeline para aqui.
5. Publicação. O resultado vai para produção, ou antes para um ambiente de staging.
6. Verificação. Um smoke test ou health check confirma que a nova versão está de pé.

O ponto central é que uma falha interrompe o fluxo: teste quebrado, nada de deploy.

Como fica um pipeline de CI/CD na prática?#

No GitHub, um workflow é um arquivo YAML guardado em .github/workflows/ no seu repositório. Um evento, como um push, inicia o workflow. Ele contém um ou mais jobs, e cada job roda num runner, o servidor que executa os passos. Os jobs rodam em paralelo por padrão, e needs faz um esperar o outro.

Este workflow é a parte de CI de um projeto Node.js: ele roda os testes em todo push na main e em todo pull request.

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: lts/*
      - run: npm ci
      - run: npm test

actions/checkout@v7 copia o seu código para o runner (confira a versão maior atual na página de releases da ação), e lts/* instala a versão LTS ativa do Node.js. npm ci instala exatamente o que o lockfile diz, o que mantém a CI reproduzível. Para transformar isso em CD, você adiciona um segundo job com needs: test que envia o código para o servidor. A versão completa, com secrets e etapa de deploy, está em deploy automático com GitHub Actions.

GitLab CI, CircleCI e Jenkins fazem o mesmo trabalho com outra sintaxe, e os conceitos acima valem para todas.

Por que as equipes usam CI/CD?#

• Menos publicações quebradas. Os testes rodam em toda mudança, inclusive nas que você tinha certeza de que eram inofensivas.
• Mudanças menores e mais seguras. Quando fazer deploy é barato, você publica pedaços pequenos. Uma mudança pequena é mais fácil de revisar e de desfazer.
• Repetibilidade. O pipeline faz os mesmos passos na mesma ordem. O "na minha máquina funciona" pesa menos quando um runner limpo faz o build.
• O conhecimento não fica com uma pessoa só. O procedimento de deploy mora num arquivo do repositório, não na cabeça de alguém.
• Retorno mais rápido. Você descobre que o build falhou enquanto a mudança ainda está fresca na memória.

Quando o CI/CD não vale a pena?#

O pipeline também tem custo. É código que você precisa manter, secrets que você precisa proteger e uma fonte de falhas própria (um teste instável trava todo mundo).

• Um bot de hobby de uma pessoa só, sem testes, ganha pouco com CI. Um deploy manual leva um minuto.
• Sem testes, a CI só prova que o código compila. Deploy automático sem testes só publica bugs mais rápido.
• Um pipeline lento é ignorado. Se os testes levam 40 minutos, as pessoas param de esperar por eles.

Um caminho razoável: comece rodando testes nos pull requests (só CI), depois adicione um deploy automático para um ambiente de staging e só então automatize o deploy em produção.

Como voltar atrás quando um deploy dá errado?#

O CI/CD leva código para produção rápido, então você precisa de um caminho de volta igualmente rápido. O mais simples é publicar de novo o último commit bom. Em aplicações com dados, guarde também cópias dos dados: código se reverte, banco corrompido não. Veja rollback e deploy sem downtime para as opções.

Como fazer isso na Square Cloud#

A Square Cloud é uma hospedagem self-service, então quem controla o pipeline é você: a sua CI decide quando algo está pronto, e a etapa de deploy faz o envio. Você pode fazer o deploy a partir do GitHub com a GitHub Action oficial ou chamar a CLI open source de qualquer sistema de CI. Nesse caso, ela se autentica pela variável SQUARECLOUD_API_KEY, sem login pelo navegador.

A GitHub Action oficial, squarecloudofc/github-action@v2, roda o comando da CLI informado na entrada command, por exemplo commit <appId> --restart, em todo push, release ou execução manual. Ela só precisa de uma API key, guardada como secret no repositório e passada na entrada token. Coloque os testes num job antes dela e use needs: um teste que falha interrompe o deploy.

As variáveis de ambiente são definidas por aplicação no painel, na API, na CLI ou no VS Code, e a mudança vale no próximo restart, sem rebuild, então você não precisa colocá-las no pipeline. O arquivo de configuração squarecloud.app é opcional: o painel o gera no deploy, ou você pode escrevê-lo na raiz do projeto.

Veja a página da GitHub Action para a configuração.