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

O CI/CD é uma forma de entregar software em que cada alteração de código é automaticamente compilada, testada e — se passar — preparada para lançamento ou lançada. CI (integração contínua) significa que as alterações são integradas com frequência e verificadas por testes automáticos de cada vez. CD (entrega ou implementação contínua) significa que as alterações aprovadas são empacotadas e enviadas para os utilizadores com pouco ou nenhum trabalho manual.

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

Porque é que o CI/CD importa quando cria com IA

Os criadores com IA fazem alterações de código depressa. Um único prompt pode tocar em dez ficheiros. Essa rapidez é ótima, até ao momento em que uma alteração na página de checkout parte silenciosamente a página de login e ninguém repara até um utilizador lhe enviar um email.

O CI/CD é a rede de segurança para exatamente este caso. Em vez de confiar que cada alteração está bem, um pipeline executa as mesmas verificações sempre:

• A app continua a compilar sem erros?
• Os testes automáticos continuam a passar?
• O código segue as regras do projeto (tipos, formatação, verificações de segurança)?

Se alguma verificação falhar, a alteração é travada antes de chegar aos utilizadores. Quanto mais depressa mudar o código, mais valiosa é uma verificação que nunca se cansa nem salta um passo.

Uma analogia do dia a dia

Pense numa padaria que vende pão às lojas todas as manhãs.

• Sem CI/CD, cada padeiro trabalha sozinho em ajustes à receita durante uma semana, e depois todos juntam as alterações na sexta-feira à noite e esperam que o pão levede. Quando não leveda, ninguém sabe qual alteração foi a culpada.
• Com CI, cada pequena alteração à receita é logo cozida numa fornada de teste e verificada — sabor, peso, forma. Um mau ajuste é apanhado no próprio dia, e sabe-se exatamente qual foi.
• Com CD, as fornadas que passam na inspeção seguem diretamente para a carrinha de entregas, embaladas e rotuladas sempre da mesma forma, em vez de alguém a embalar caixas à mão às 5 da manhã.

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

Como funciona um pipeline de CI/CD

Um pipeline é uma lista de passos 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 tem este aspeto:

Cada passo corre numa máquina limpa, não no portátil de alguém, por isso o «funciona no meu computador» deixa de servir de desculpa. Se um passo falhar, o pipeline para e avisa quem fez a alteração.

Os passos estão definidos num ficheiro de configuração que vive junto do código. No GitHub Actions, por exemplo, é um ficheiro YAML na pasta .github/workflows do repositório.

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

O «CD» é ambíguo, e as pessoas usam-no nos dois sentidos:

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

Um exemplo prático: uma app de marcações com um pipeline

Imagine que tem uma app de marcações para um salão de cabeleireiro, com o código num repositório do GitHub. Pede a um criador com IA: «Acrescenta um desconto de 10% para clientes que vêm pela primeira vez.»

1. A alteração é enviada para um novo ramo e é aberto um pull request.
2. O pipeline arranca. Instala os pacotes e compila a app — isto passa.
3. Executa os testes. Um deles, «um cliente que regressa paga o preço total», falha: o desconto está a ser aplicado a toda a gente.
4. O pull request mostra uma cruz vermelha. A alteração não pode ser integrada.
5. Pede à IA para corrigir. Ela envia uma correção; o pipeline corre de novo e tudo passa.
6. A alteração é integrada. O pipeline implementa-a num ambiente de staging, onde faz uma marcação de teste.
7. Aprova, e a alteração é implementada em produção.

Sem o pipeline, o passo 3 teria acontecido na carteira dos seus clientes.

Termos-chave

Ideias erradas comuns

• «CI/CD significa que a minha app está testada.» Um pipeline só executa os testes que tiver. Se não houver testes, o CI apenas prova que a app compila — nada mais. Peça à IA para escrever testes para os fluxos mais importantes.
• «CI/CD é só para grandes empresas.» Ferramentas alojadas como o GitHub Actions precisam de um ficheiro de configuração curto para ficar prontas, e as equipas pequenas usam-nas constantemente. O esforço está nos testes, não nas ferramentas.
• «Implementação automática significa que ninguém verifica nada.» Bons pipelines acrescentam verificações, não as retiram. Muitas equipas mantêm um passo de aprovação humana antes da produção.
• «Se o pipeline está verde, a app funciona.» Significa que as verificações automáticas passaram. Ainda deve experimentar a alteração você próprio, de preferência numa pré-visualização ou em staging.
• «O CI/CD substitui as cópias de segurança.» Não substitui. Uma migração de base de dados que passa nos testes pode, ainda assim, danificar dados reais. Mantenha cópias de segurança e uma forma de reverter.

O que pedir ao seu criador com IA

• «Escreve testes automáticos para o registo, o login e o checkout, e mostra-me como os executar.»
• «Configura um workflow do GitHub Actions que instale as dependências, compile a app e execute os testes em cada pull request.»
• «Acrescenta ao pipeline uma verificação de tipos e um linter, e faz com que falhe em caso de erros.»
• «Explica em linguagem simples o que faz cada passo do pipeline.»
• «O que acontece se uma implementação falhar a meio? Como reverto?»
• «Confirma que não há segredos escritos no repositório nem impressos nos registos do pipeline.»

Se a sua app usa chaves de API, o pipeline também precisa delas — guardadas como segredos cifrados na ferramenta de CI, nunca no ficheiro 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 si, mas cobre várias das mesmas necessidades à sua maneira:

• Pontos de verificação. Depois de cada turno bem-sucedido do agente, o Mythex guarda um ponto de verificação do git, e Reverter para este ponto repõe o projeto se uma alteração correr mal. Veja Chat.
• Testes da app. Escreva /test e o agente percorre a sua pré-visualização ao vivo como um utilizador e reporta os fluxos partidos — útil antes de cada publicação. Veja Testes da app.
• Publicar é um passo deliberado. As alterações aparecem primeiro na pré-visualização privada; a sua app pública só é atualizada quando publica de novo — mais perto da entrega contínua do que da implementação contínua.
• Sincronização com o GitHub (Pro). Sincronize o projeto com um repositório do GitHub e pode acrescentar os seus próprios workflows do GitHub Actions para executar testes em cada envio. Veja GitHub e exportação.

Para uma lista do que testar à mão antes de lançar, veja como testar a sua app antes do lançamento, e para trabalhar com controlo de versões, como usar o Git com uma app criada com IA.

Perguntas