O que é CI/CD? Integração e entrega contínuas explicadas de forma simples

CI/CD é uma forma de publicar software em que cada mudança de código é automaticamente compilada, testada e — se passar — preparada para lançamento ou lançada. CI (integração contínua) significa que as mudanças são unidas com frequência e verificadas por testes automatizados a cada vez. CD (entrega ou implantação contínua) significa que as mudanças aprovadas são empacotadas e levadas aos seus usuários com pouco ou nenhum trabalho manual.

A ideia é simples: detectar erros minutos depois de cometidos, e não semanas depois, quando um cliente os encontra.

Por que o CI/CD importa quando você cria com IA

Criadores de apps com IA fazem mudanças de código rapidamente. Um único prompt pode afetar dez arquivos. Essa velocidade é ótima até o momento em que uma mudança na página de checkout quebra silenciosamente a página de login, e ninguém percebe até um usuário mandar um e-mail para você.

O CI/CD é a rede de segurança exatamente para isso. Em vez de confiar que cada mudança está correta, um pipeline executa as mesmas verificações toda vez:

• O app ainda compila sem erros?
• Os testes automatizados continuam passando?
• O código segue as regras do projeto (tipos, formatação, verificações de segurança)?

Se qualquer verificação falhar, a mudança é interrompida antes de chegar aos usuários. Quanto mais rápido seu código muda, mais valiosa é uma verificação que nunca se cansa nem pula uma etapa.

Uma analogia do dia a dia

Pense em uma padaria que vende pão para lojas todas as manhãs.

• Sem CI/CD, cada padeiro ajusta a própria receita por uma semana, e então todos juntam as mudanças na sexta à noite e torcem para o pão ainda crescer. Quando não cresce, ninguém sabe qual mudança causou o problema.
• Com CI, cada pequena mudança na receita vai imediatamente para uma fornada de teste e é verificada — sabor, peso, formato. Uma mudança ruim é detectada no mesmo dia, e você sabe exatamente qual foi.
• Com CD, os pães que passam na inspeção vão direto para a van de entrega, embalados e rotulados sempre do mesmo jeito, em vez de alguém encaixotando tudo à mão às 5 da manhã.

A inspeção não torna os padeiros melhores. Ela torna os erros deles baratos.

Como funciona um pipeline de CI/CD

Um pipeline é uma lista de etapas que um serviço de CI/CD executa automaticamente quando algo acontece — normalmente quando alguém envia código para um repositório como o GitHub. Um pipeline típico se parece com isto:

Cada etapa roda em uma máquina limpa, e não no notebook de alguém, então "funciona no meu computador" deixa de ser uma desculpa. Se uma etapa falhar, o pipeline para e avisa quem fez a mudança.

As etapas são definidas em um arquivo de configuração que fica junto com o código. No GitHub Actions, por exemplo, é um arquivo YAML na pasta .github/workflows do repositório.

Entrega contínua vs implantação contínua

O "CD" é ambíguo, e as pessoas usam os dois sentidos:

A implantação contínua só funciona bem se os testes forem bons. Se os seus testes não cobrem o checkout, a implantação contínua vai publicar alegremente um checkout quebrado.

Um exemplo prático: um app de reservas com pipeline

Suponha que você tem um app de reservas de salão, e o código está em um repositório do GitHub. Você pede a um criador de apps com IA: "adicione 10% de desconto para clientes que estão na primeira visita."

1. A mudança é enviada para um novo branch e um pull request é aberto.
2. O pipeline começa. Ele instala os pacotes e compila o app — isso passa.
3. Ele roda os testes. Um teste, "um cliente recorrente paga preço cheio", falha: o desconto está sendo aplicado a todos.
4. O pull request mostra um X vermelho. A mudança não pode ser unida ao código principal.
5. Você pede à IA para corrigir. Ela envia uma correção; o pipeline roda de novo e tudo passa.
6. A mudança é unida. O pipeline a implanta em um ambiente de staging, onde você faz uma reserva de teste.
7. Você aprova, e ela é implantada na produção.

Sem o pipeline, a etapa 3 teria acontecido no bolso dos seus clientes.

Termos-chave

Equívocos comuns

• "CI/CD significa que o meu app está testado." Um pipeline só executa os testes que você tem. Se não há testes, o CI comprova apenas que o app compila — nada além disso. Peça à sua IA para escrever testes dos fluxos mais importantes.
• "CI/CD é só para grandes empresas." Ferramentas hospedadas como o GitHub Actions exigem um arquivo de configuração curto para serem configuradas, e equipes pequenas as usam o tempo todo. O esforço está nos testes, não nas ferramentas.
• "Implantação automática significa que ninguém confere nada." Bons pipelines acrescentam verificações, não as removem. Muitas equipes mantêm uma aprovação humana antes da produção.
• "Se o pipeline está verde, o app funciona." Significa que as verificações automáticas passaram. Você ainda deve testar a mudança por conta própria, de preferência em uma prévia ou no staging.
• "CI/CD substitui backups." Não substitui. Uma migração ruim do banco de dados que passa nos testes ainda pode danificar dados reais. Mantenha backups e um jeito de reverter.

O que pedir ao seu criador de apps com IA

• "Escreva testes automatizados para cadastro, login e checkout, e me mostre como executá-los."
• "Configure um workflow do GitHub Actions que instale as dependências, compile o app e rode os testes em cada pull request."
• "Adicione uma verificação de tipos e um linter ao pipeline, e faça-o falhar em caso de erros."
• "Explique em português simples o que cada etapa do pipeline faz."
• "O que acontece se uma implantação falhar no meio do caminho? Como faço para reverter?"
• "Confira que nenhum segredo está fixo no código do repositório nem impresso nos logs do pipeline."

Se o seu app usa chaves de API, o pipeline também precisa delas — guardadas como segredos criptografados na ferramenta de CI, nunca no arquivo de configuração. Veja variáveis de ambiente e segredos.

CI/CD e o Mythex

O Mythex não executa um pipeline de CI para você, mas atende a várias das mesmas necessidades à sua maneira:

• Checkpoints. Depois de cada turno bem-sucedido do agente, o Mythex salva um checkpoint do git, e Reverter para este ponto volta o projeto atrás se uma mudança der errado. Veja Chat.
• Testes do App. Digite /test e o agente navega pela sua prévia ao vivo como um usuário e relata os fluxos quebrados — útil antes de cada publicação. Veja Testes do App.
• Publicar é uma etapa deliberada. As mudanças aparecem primeiro na prévia privada; o seu app público só é atualizado quando você publica de novo — mais perto de entrega contínua do que de implantação contínua.
• Sincronização com o GitHub (Pro). Sincronize o projeto com um repositório do GitHub e você pode adicionar seus próprios workflows do GitHub Actions para rodar testes a cada push. Veja GitHub e exportação.

Para uma lista do que testar manualmente antes de ir ao ar, veja como testar seu app antes do lançamento, e para trabalhar com controle de versão, como usar Git com um app criado com IA.

Perguntas