O que significa CI/CD na prática?

CI (integração contínua) é a verificação automática de que a alteração não quebrou o que já funcionava. CD (entrega ou implantação contínua) é a publicação automática dessa alteração no ambiente. Juntas, formam a esteira que vai do código escrito ao sistema atualizado sem passos manuais.

Vale a pena para um sistema pequeno?

Vale a partir do momento em que existe mais de uma pessoa mexendo no código ou o sistema é usado de verdade pelo negócio. Uma esteira básica leva algumas horas para montar e elimina a classe de erro mais comum, que é o passo manual esquecido durante uma publicação.

Como isso aparece no meu contrato com o fornecedor?

Peça que a proposta descreva ambientes separados de teste e produção, publicação automatizada, testes executados a cada alteração e procedimento de reversão. Também peça que a configuração da esteira fique no seu repositório, e não apenas na conta do fornecedor.

CI/CD explicado para quem não é desenvolvedor

CI/CD é a esteira automática que, a cada alteração feita no sistema, verifica se nada quebrou e publica a nova versão sem ninguém executar comandos à mão. Para quem contrata software, o que importa não é a sigla: é que a esteira transforma publicação em rotina previsível, em vez de evento arriscado que só uma pessoa sabe conduzir.

O que acontece hoje sem esteira

Numa publicação manual típica, alguém precisa: copiar arquivos para o servidor, rodar as alterações do banco, reiniciar o serviço, limpar o cache e conferir se subiu. São cinco a dez passos, na ordem certa, sem esquecer nenhum, geralmente à noite.

Esse desenho tem quatro consequências que aparecem na conta da empresa:

Publicações raras. Como dá trabalho e assusta, junta-se um mês de alterações num pacote só. Pacote grande é mais arriscado, e quando dá problema ninguém sabe qual das trinta mudanças causou.
Correção urgente demora. Um erro que custa horas de trabalho por dia espera a próxima janela.
Dependência de uma pessoa. Se só um desenvolvedor sabe publicar, férias e desligamento viram risco operacional.
Erro humano. Passo esquecido derruba o sistema, e a causa é procedimento, não código.

O que a esteira faz, passo a passo

Quando um desenvolvedor envia uma alteração, a esteira dispara sozinha:

Baixa o código e instala as dependências
Roda os testes automatizados, o conjunto de verificações que confirma que as funções principais continuam corretas
Verifica padrões e falhas conhecidas em bibliotecas de terceiros
Monta o pacote da aplicação
Publica em ambiente de teste, uma cópia do sistema onde ninguém real é afetado
Aguarda aprovação (ou publica direto, se a política for essa)
Publica em produção e confirma que o sistema respondeu
Reverte automaticamente se a verificação falhar

Se qualquer passo falhar, a esteira para e avisa. A alteração não chega ao usuário.

O que muda para o negócio

Dimensão	Publicação manual	Com esteira
Frequência típica	Mensal ou quinzenal	Diária ou sob demanda
Tempo para corrigir um erro	Dias, até a próxima janela	Horas
Quem consegue publicar	Uma pessoa específica	Qualquer um da equipe
Chance de erro por passo esquecido	Alta	Praticamente eliminada
Reverter versão ruim	Manual, demorado, tenso	Minutos, procedimento conhecido
Custo de montar	Zero	Algumas horas, uma vez

O ganho mais relevante não é velocidade, é tamanho do lote. Publicar dez alterações pequenas ao longo do mês é muito menos arriscado do que publicar as dez de uma vez. Quando algo dá errado, a causa é óbvia porque a mudança foi pequena.

O papel dos testes automatizados

A esteira sozinha só automatiza o transporte. O que dá segurança é o que ela verifica no caminho.

Teste automatizado é um trecho de código que confere se uma função do sistema continua se comportando como deveria, "o cálculo de desconto para cliente do tipo B retorna 12%", "usuário sem permissão recebe erro ao acessar o relatório financeiro". Roda em segundos, a cada alteração, sem ninguém clicar.

Não é preciso testar tudo. Cobrir os caminhos de dinheiro, de permissão e de integração já elimina a maior parte dos incidentes graves. Ao contratar, vale perguntar quais fluxos estão cobertos por teste automatizado, não a porcentagem de cobertura, que diz pouco.

Os ambientes

Uma esteira madura trabalha com pelo menos dois ambientes:

Teste (ou homologação): cópia do sistema onde a alteração é validada. Deve ser parecida com produção, mas nunca com dados pessoais reais sem anonimização, copiar a base de produção para o ambiente de teste é uma exposição desnecessária.
Produção: o sistema que as pessoas usam.

Se o fornecedor desenvolve direto em produção, esse é o primeiro item a mudar, antes de qualquer automação.

O que pedir ao fornecedor

Independentemente de quem desenvolve, estes pontos protegem a empresa:

Ambientes separados de teste e produção, com dados de teste anonimizados
Publicação automatizada e documentada, executável por mais de uma pessoa
Testes automatizados rodando a cada alteração, cobrindo os fluxos críticos
Procedimento de reversão escrito e já testado
Configuração da esteira versionada no seu repositório, não presa à conta pessoal do fornecedor
Histórico de versões, permitindo saber o que foi publicado e quando

Esse último item costuma ser esquecido e vira problema na troca de fornecedor. A esteira precisa ser sua, junto com o código.

Quanto custa

Para um sistema de porte pequeno ou médio, montar a esteira é trabalho de algumas horas a poucos dias, uma vez só. As ferramentas mais usadas, GitHub Actions, GitLab CI, têm cota gratuita suficiente para a maioria dos projetos desse porte.

O custo real está em escrever os testes automatizados, que é esforço contínuo. Mas esse esforço substitui outro: o de testar tudo à mão a cada publicação, que ninguém consegue manter por muito tempo e que falha justamente quando o prazo aperta.

Numa empresa que publica alterações com alguma regularidade, a esteira se paga no primeiro incidente evitado.