# Como implementar CI/CD na prática com GitHub Actions

> Published 2026-10-11T13:56:48.291Z on https://www.crazystack.com.br/pt/p/como-implementar-ci-cd-na-pratica-com-github-actions/
> Source video: https://www.youtube.com/watch?v=95r8nJLq5zU

A maioria das empresas diz 'fazemos CI/CD' sem distinguir delivery de deploy, e isso quase nunca importa na prática. O CI/CD na prática, porém, exige entender uma separação real: deploy coloca o código no servidor; release o expõe aos usuários. A Meta separa os dois em escala; equipes médias geralmente não precisam.

## O que é CI/CD na prática e por que os dois 'CD' confundem todo mundo

CI/CD na prática reúne três conceitos com siglas parecidas: **continuous integration** (integração contínua), **continuous delivery** (entrega contínua) e **continuous deployment** (deploy contínuo). A confusão nasce porque ambos os 'CD' compartilham a sigla, mas significam etapas diferentes da jornada do código até o usuário.

Integração contínua é o hábito de integrar código novo à branch principal com verificação automática: a cada merge, uma pipeline roda build, lint e testes. Delivery contínuo deixa o código pronto para ser lançado a qualquer momento. Deploy contínuo vai além e publica automaticamente na cloud ou no servidor.

Nenhuma dessas definições é regra escrita em pedra. São conceitos abstratos, e cada empresa aplica do seu jeito. O que não muda é a direção: tudo que você faz manualmente num deploy cabe em um script versionado na codebase, sujeito a code review como qualquer outro código.

## Deploy e release são a mesma coisa?

Deploy e release não são a mesma coisa, e essa distinção é a base técnica do CI/CD bem feito. Deploy é colocar o código no servidor. Release é expor esse código aos usuários. Você pode subir uma feature atrás de uma feature flag, com tudo buildado e testado, sem que ninguém de fora veja nada.

O exemplo clássico vem da Meta. No artigo [Rapid Release at Massive Scale](https://engineering.fb.com/2017/08/31/developer-tools/rapid-release-at-massive-scale/), publicado em 2017, a empresa descreve como o código flui continuamente para a main, mas cada release chega primeiro aos funcionários, depois a 2% da produção e só então a 100%. É um rollout gradual que desacopla deploy de release.

Na prática, a maioria das empresas médias não faz essa separação e trata delivery e deploy como a mesma coisa. Só operações de escala gigantesca, como a Meta, mantêm os dois processos formalmente distintos.

## O que roda dentro de uma pipeline de integração contínua

Uma pipeline típica de CI executa três tipos de verificação a cada merge: build, lint e testes. O build prova que o código compila. O lint confere se o código segue os padrões definidos pela equipe. Os testes cobrem unitários, de integração e, quando faz sentido, testes de ponta a ponta.

No ecossistema JavaScript, a maioria das equipes usa [Prettier](https://prettier.io/) para formatação e [ESLint](https://eslint.org/) para regras de código. Em Python, ferramentas como Ruff cumprem papel parecido. Nada disso é obrigatório, mas padronizar antes de revisar poupa discussão em pull request.

Para executar a pipeline, o [GitHub Actions](https://github.com/features/actions) é hoje a opção mais popular e é gratuito para a maioria dos usos. O [Jenkins](https://www.jenkins.io/) já dominou esse mercado e continua sendo uma alternativa válida, principalmente em infraestruturas self-hosted. A escolha importa menos do que a consistência: a pipeline precisa rodar em todo merge.

Os workflows ficam dentro do próprio repositório, na pasta `.github/workflows`. Um job de CI chama `npm run test` e `npm run build`, os mesmos scripts que você já roda localmente pelo `package.` antes de commitar. Assim, se passa na sua máquina, a lógica é a mesma na pipeline.

## CI, delivery e deploy: comparando os três estágios

Os três estágios respondem perguntas diferentes sobre o mesmo commit. A tabela abaixo resume o que cada um entrega e onde termina a automação.

| Estágio | Pergunta que responde | Onde termina |
| --- | --- | --- |
| Integração contínua (CI) | O código funciona e segue os padrões? | Build, lint e testes aprovados |
| Delivery contínuo (CD) | O código está pronto para lançar? | Artefato pronto, release pode exigir aprovação |
| Deploy contínuo (CD) | O código já está no ar? | Publicação automática na produção a cada merge |

O delivery vira deploy quando não há interação humana no caminho. Se alguém precisa clicar em um botão de aprovação antes de publicar, o processo deixa de ser 100% contínuo. As duas abordagens são legítimas, e a escolha depende do apetite da equipe por risco e da maturidade dos testes.

## Como organizar branches e ambientes antes de chegar na main

Se o deploy acontece a cada merge na main, você precisa de um lugar para testar antes. Por isso a maioria das equipes usa feature branches que passam primeiro por uma branch de `dev` ou `staging`. O fluxo típico é: feature → dev/staging → main, com QA e testes manuais acontecendo no ambiente intermediário.

Um detalhe que faz diferença: empresas costumam clonar o banco de dados de produção para o ambiente de staging, mas anonimizam tudo que é sensível. Senhas, nomes, compras e pagamentos viram dados randomizados. O que permanece é a estrutura do schema e a dispersão dos dados, suficiente para testar num ambiente parecido com o real.

Sobre nomes de branch, a `main` é o padrão atual. Bases de código antigas ainda usam `master`, então não se surpreende ao encontrar as duas em repositórios diferentes.

## Deploy contínuo na prática: de um commit a uma VPS

A etapa de deploy varia completamente com a infraestrutura. A [Vercel](https://vercel.com), plataforma por trás do [Next.js](https://nextjs.org/), automatiza o processo para aplicações React. A AWS oferece infinitas combinações. Para uma demo enxuta, o caminho direto é um job que abre SSH numa VPS, instala as dependências e coloca a aplicação para rodar com `next start` ou equivalente.

O fluxo demonstrado no vídeo segue exatamente esse caminho: um commit altera as cores do site, o push dispara dois jobs no GitHub Actions, o de teste e build roda em segundos e o de deploy conecta na VPS via SSH. Pouco depois, um F5 no navegador mostra o site com as novas cores no ar.

Conteúdos brasileiros sobre o tema abundam, de canais como o do Gustavo Dev Doido a formações como o Crazystack Typescript ([crazystack.com.br](https://crazystack.com.br)) e o Bootcamp do Dev Doido. O denominador comum é sempre o mesmo: entender a pipeline antes de confiar nela.

Uma ressalva honesta vale ouro aqui: depender de um único provedor de CI tem custo. Durante a gravação da demo, o GitHub passou por instabilidade e atrasou o deploy por horas. Quando sua produção depende de uma pipeline externa, um incidente do fornecedor vira o seu incidente.

## Credenciais e secrets: a parte que ninguém pode errar

Todo deploy contínuo exige credenciais: você não conecta na sua cloud sem elas. A regra é absoluta — credenciais nunca vão para dentro do código. Se você commitar uma senha, deletar o arquivo não resolve, porque o histórico do git preserva tudo. A limpeza completa é trabalhosa e nunca vale o risco.

No GitHub Actions, o lugar certo é a seção **Secrets and Variables**, nas configurações do repositório. O valor salvo lá é write-only: você pode atualizá-lo, mas nunca lê-lo de novo, nem como administrador. No workflow, você acessa com a sintaxe `${{ secrets.NOME_DO_SECRET }}`, que injeta a senha na hora da execução sem expô-la nos logs.

Cada plataforma tem seu mecanismo equivalente, como os gerenciadores de segredos da AWS. O princípio é o mesmo em todas: a credencial vive fora da codebase, entra no ambiente de execução no último momento possível e jamais aparece em texto plano.

## Perguntas frequentes sobre CI/CD na prática

- **Qual a diferença entre continuous delivery e continuous deployment?** Delivery deixa o código pronto para lançar a qualquer momento, podendo exigir uma aprovação manual. Deployment publica automaticamente em produção a cada merge, sem intervenção humana no caminho.

- **Preciso de staging se já testo localmente?** Sim, se sua pipeline faz deploy contínuo na main. O ambiente de staging com dados anonimizados de produção revela problemas que o teste local não pega, porque roda em condições parecidas com as reais.

- **O GitHub Actions é gratuito?** Para a maioria dos usos pessoais e de equipes pequenas, sim. Projetos com alto volume de execução ou runners maiores começam a consumir créditos pagos, e o preço depende do plano e do sistema operacional do runner.

- **Deploy e release são sinônimos?** Não. Deploy coloca o código no servidor; release expõe esse código aos usuários, por exemplo via feature flag ou rollout gradual. A Meta, conforme descreveu em 2017, separa os dois em escala global.

- **Posso fazer CI/CD sem Vercel ou AWS?** Pode. Um job de GitHub Actions que abre SSH numa VPS e roda os comandos de instalação e start já é deploy contínuo funcional. A ferramenta importa menos do que a automação completa do caminho do commit até o servidor.

## Transforme suas aulas sobre deploy em artigos com o Skala Blog

Você acabou de ver como um simples commit atravessa build, testes e SSH até virar código rodando em produção. Se você ensina esse tipo de conteúdo em vídeo, provavelmente tem aulas completas sobre pipeline, secrets e deploy guardadas no YouTube, esperando alcançar quem prefere ler.

O [Skala Blog](https://skalablog.com) transforma esse material existente em artigo estruturado: você cola a URL do vídeo, a transcrição é gerada e o artigo sai pronto para revisar e publicar. Mesmo conhecimento, alcance maior, sem regravar nada.

[Source video](https://www.youtube.com/watch?v=95r8nJLq5zU)