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, 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 para formatação e ESLint 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 é hoje a opção mais popular e é gratuito para a maioria dos usos. O Jenkins 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, plataforma por trás do Next.js, 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) 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 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.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits