CI/CD: o que é e como publicar sistemas sem medo de quebrar

Sexta-feira, nove da noite. A versão nova do sistema precisa subir antes da segunda, porque o comercial prometeu a funcionalidade a um cliente. Um desenvolvedor copia arquivos para o servidor, roda um script que só ele conhece, ajusta uma configuração na mão e torce. No sábado de manhã, o financeiro descobre que a emissão de boletos parou. Ninguém sabe exatamente o que mudou, e voltar à versão anterior leva o fim de semana inteiro.

Quem passou por isso algumas vezes aprende a ter medo de publicar. As entregas passam a ser raras e grandes, juntando semanas de mudanças num pacote só. Quanto maior o pacote, maior o risco, e mais medo se tem da próxima. O ciclo se alimenta sozinho.

CI/CD (integração contínua e entrega contínua) é o conjunto de práticas que quebra esse ciclo: automatiza o caminho do código até o ar, com testes e verificações a cada mudança, para que publicar seja rotineiro, rápido e reversível. Este texto explica o que é, em linguagem de gestão, o que muda no ritmo de entregas e na quantidade de erros em produção, e o que você deve cobrar do seu fornecedor de software.

CI/CD, o que é em uma resposta curta

CI/CD é a sigla para integração contínua (Continuous Integration) e entrega contínua (Continuous Delivery), às vezes também implantação contínua (Continuous Deployment). Na prática, é uma esteira automática, chamada de pipeline, por onde toda mudança no código passa antes de chegar ao usuário:

1. o desenvolvedor salva a mudança no repositório central do código;
2. a esteira monta o sistema automaticamente, do zero;
3. roda os testes automáticos e as verificações de qualidade e segurança;
4. publica a versão num ambiente de homologação para conferência;
5. publica em produção, com um clique ou automaticamente, e sabe voltar atrás se algo der errado.

O que muda para o negócio é simples de enunciar: entregas menores, mais frequentes e previsíveis, com menos erro chegando ao cliente e recuperação rápida quando algum erro chega. Publicar deixa de ser um evento e vira rotina.

Integração contínua em linguagem simples

Imagine cinco pessoas escrevendo capítulos do mesmo manual, cada uma no seu computador, durante um mês. No fim, alguém tenta juntar tudo e descobre que dois capítulos se contradizem, um renumerou as seções e outro apagou um trecho que um terceiro usava. Juntar leva mais tempo que escrever.

Com software acontece o mesmo. Quando cada desenvolvedor trabalha isolado por semanas, a hora de juntar o código vira um projeto à parte, cheio de conflitos.

Integração contínua é juntar o trabalho de todos várias vezes ao dia, em pedaços pequenos, e a cada junção verificar automaticamente se o sistema ainda funciona. Se uma mudança quebra algo, o aviso chega em minutos, para a pessoa que acabou de fazê-la, enquanto o assunto ainda está fresco na cabeça dela. Corrigir um problema de dez minutos atrás é rápido. Corrigir um problema que se misturou a um mês de mudanças é investigação.

O que a integração contínua verifica, no mínimo:

• o sistema compila e monta sem erro, num ambiente limpo, e não só na máquina de quem programou;
• os testes automáticos passam;
• o código segue os padrões combinados pela equipe;
• as bibliotecas usadas não têm falhas de segurança conhecidas, quando a esteira inclui essa checagem.

Entrega contínua e implantação automática

A integração contínua garante que o código está sempre em bom estado. A entrega contínua vai um passo além: garante que ele está sempre pronto para ir ao ar. Cada mudança aprovada gera um pacote publicável, já testado num ambiente parecido com o de produção. Colocar no ar vira uma decisão de negócio, tomada com um clique, e não uma operação técnica de madrugada.

A implantação contínua elimina até o clique: passou em todas as verificações, vai para produção sozinho. Faz sentido para alguns sistemas e não para outros.

Para a maioria dos sistemas de gestão de empresas pequenas e médias, entrega contínua com aprovação humana é o ponto de equilíbrio. O sistema está sempre pronto; a empresa escolhe o momento, por exemplo, evitando publicar no dia do fechamento do mês.

Um detalhe que muda a vida do gestor: com a esteira, a funcionalidade pode estar em produção, mas desligada. A equipe publica o código e liga a novidade só quando o comercial, o treinamento ou a comunicação estiverem prontos. Publicar e lançar viram duas decisões separadas.

Testes automáticos como porta de entrada

A esteira só é tão boa quanto os testes que ela roda. Sem testes automáticos, o pipeline apenas publica mais rápido os mesmos erros.

Testes automáticos são pequenos programas que verificam se o sistema faz o que deveria. Eles se dividem em camadas:

• Testes de unidade. Verificam uma regra isolada: o cálculo do desconto, a validação do CNPJ, o arredondamento do imposto. São rápidos e baratos de manter.
• Testes de integração. Verificam se as partes conversam: o pedido grava no banco de dados, a chamada à API bancária retorna o que se espera, o arquivo de remessa sai no formato certo.
• Testes de ponta a ponta. Simulam o usuário: entrar no sistema, criar um pedido, faturar, conferir o resultado. São os mais lentos e mais frágeis, então ficam reservados aos fluxos críticos.

O gestor não precisa saber escrever testes, mas precisa saber onde eles existem. A pergunta certa não é "quantos testes vocês têm", é "os fluxos que param a empresa se quebrarem estão cobertos?". Faturamento, cobrança, cálculo de impostos, integração com o ERP e com o banco, fechamento de caixa. Se um erro ali passa despercebido, o prejuízo é imediato.

Um bom hábito: todo bug que chega à produção vira um teste. Assim, o mesmo problema não volta pela segunda vez. Bugs que reaparecem são um dos sintomas clássicos de dívida técnica, e a esteira com testes é uma das formas mais concretas de pagá-la.

Voltar uma versão em minutos

Nenhuma esteira impede todos os erros. A diferença está em quanto tempo o erro fica no ar.

No deploy manual, voltar atrás é refazer tudo ao contrário, de memória, sob pressão. Com uma esteira bem montada, cada versão publicada fica guardada, identificada e pronta para ser reinstalada. Voltar à anterior é a mesma operação de publicar, só que apontando para a versão de ontem.

O que torna isso possível:

• Versões numeradas e guardadas. Sempre se sabe o que está em produção e o que estava antes.
• Configuração separada do código. Os parâmetros de cada ambiente ficam registrados e versionados, e senhas e chaves de acesso ficam num cofre de segredos, não em arquivos editados na mão no servidor.
• Mudanças no banco de dados planejadas para conviver com a versão anterior por um tempo. Esse é o ponto mais delicado: código se troca rápido, dado não. A equipe precisa desenhar alterações de tabela que permitam voltar o código sem perder informação.
• Publicação gradual quando o risco é alto. A versão nova vai primeiro para uma parte dos usuários ou para um servidor, e só depois para todos.

E para saber que é preciso voltar, o sistema precisa avisar quando algo piora logo depois de uma publicação: aumento de erros, lentidão, fila parada. É o papel da observabilidade com logs, métricas e traces. Esteira sem monitoramento publica rápido e descobre o problema pelo telefone do cliente.

O que muda na prática para a empresa

Resumindo o efeito no dia a dia de quem decide:

• Ritmo. Em vez de uma grande entrega a cada mês ou trimestre, pequenas entregas frequentes. O pedido do comercial chega ao usuário quando fica pronto, não quando "sair a próxima versão".
• Erros em produção. Mudanças pequenas são mais fáceis de testar e de entender. Quando algo quebra, sabe-se qual mudança causou, porque ela é uma só.
• Tempo de recuperação. Erro que chega ao ar fica pouco tempo, porque voltar é uma operação conhecida.
• Dependência de pessoas. O processo de publicação está escrito na esteira, não na cabeça de um desenvolvedor. Férias e troca de fornecedor deixam de ser risco operacional.
• Rastreabilidade. Para cada versão em produção, sabe-se o que entrou, quem aprovou e quando. Isso ajuda em auditorias e em qualquer conversa sobre controle de mudanças.

Nada disso acontece da noite para o dia. Montar a esteira de um sistema que nunca teve testes é um trabalho gradual, que começa pelos fluxos críticos e avança junto com a manutenção evolutiva do sistema.

O que perguntar ao fornecedor sobre o pipeline

Estas perguntas cabem numa reunião de acompanhamento ou numa avaliação de proposta. As respostas dizem muito sobre a maturidade de quem cuida do seu software.

1. Como uma mudança sai do computador do desenvolvedor e chega à produção? A resposta boa descreve uma esteira automática. A preocupante começa com "a gente acessa o servidor e...".
2. Quem consegue publicar uma versão hoje? Se a resposta é um nome só, existe dependência de pessoa.
3. Quais fluxos críticos têm testes automáticos? Peça a lista em linguagem de negócio.
4. Existe um ambiente de homologação parecido com o de produção? Testar num ambiente muito diferente dá falsa segurança.
5. Quanto tempo leva para voltar à versão anterior, e quando isso foi feito pela última vez? Volta que nunca foi testada não é plano, é esperança.
6. Como são feitas as mudanças no banco de dados? Elas são versionadas e passam pela esteira, ou alguém roda comandos à mão?
7. Onde ficam senhas e chaves de acesso? Num cofre, com acesso controlado, ou em arquivos e mensagens?
8. O código e a esteira estão em nome da empresa? O repositório e as configurações do pipeline devem pertencer a você, não ao fornecedor.
9. Como a equipe fica sabendo que uma publicação causou problema? Alerta automático ou reclamação de usuário?

Sinais de que o processo de entrega está frágil

Você não precisa abrir o código para perceber. Os sinais aparecem na operação:

• publicações só acontecem à noite ou no fim de semana, com plantão;
• existe um "dia de deploy" temido pela equipe;
• versões juntam muitas semanas de mudanças;
• o mesmo bug volta depois de corrigido;
• ninguém sabe dizer com certeza qual versão está em produção;
• uma correção urgente demora dias porque "precisa esperar a próxima versão";
• uma pessoa de férias trava as entregas;
• o sistema funciona na homologação e quebra em produção com frequência;
• voltar uma versão já levou horas ou exigiu restaurar backup.

Três ou mais desses sinais indicam que vale olhar o processo de entrega antes de acelerar o plano de novas funcionalidades. Acelerar em cima de um processo frágil só aumenta a quantidade de incidentes.

Um caminho em etapas para chegar lá

Para um sistema que hoje é publicado à mão, um roteiro realista:

1. Colocar todo o código num repositório versionado, em nome da empresa, se ainda não estiver.
2. Automatizar a montagem do sistema, para que ele seja gerado sempre do mesmo jeito, sem depender da máquina de ninguém.
3. Automatizar a publicação em homologação a cada mudança aprovada.
4. Escrever testes para os fluxos críticos, começando pelo que mais dói quando quebra.
5. Automatizar a publicação em produção, com aprovação humana e volta testada.
6. Ligar monitoramento e alertas que comparem o comportamento antes e depois de cada versão.
7. Ampliar a cobertura de testes aos poucos, a cada funcionalidade nova e a cada bug corrigido.

As primeiras etapas costumam trazer ganho rápido, porque só tirar o passo manual da publicação já elimina uma classe inteira de erros. O prazo do roteiro completo varia muito com o tamanho do sistema e o estado em que ele está, e só um diagnóstico permite estimar com honestidade.

Perguntas frequentes

Quanto tempo leva para implantar CI/CD em um sistema que já existe?

Depende do tamanho do sistema e do estado em que ele está. As primeiras etapas, como versionar o código e automatizar a publicação, costumam trazer ganho rápido. O roteiro completo, com testes nos fluxos críticos e volta de versão testada, avança de forma gradual, e só um diagnóstico permite estimar o prazo com honestidade.

Qual a diferença entre entrega contínua e implantação contínua?

Na entrega contínua, cada mudança aprovada gera uma versão testada e pronta para produção, mas a empresa decide o momento de publicar, com um clique. Na implantação contínua, a própria esteira publica em produção sempre que a mudança passa em todas as verificações. Para sistemas de gestão, a entrega contínua com aprovação humana costuma ser o equilíbrio.

Empresa pequena precisa de CI/CD?

Sim, se o sistema é importante para a operação. O CI/CD não é exclusivo de grandes equipes: mesmo com um ou dois desenvolvedores, automatizar a montagem, os testes dos fluxos críticos e a publicação elimina erros manuais e reduz a dependência de uma pessoa. A esteira pode começar simples e crescer junto com o sistema.

O que é pipeline de CI/CD?

Pipeline de CI/CD é a esteira automática por onde toda mudança no código passa antes de chegar ao usuário. A esteira monta o sistema do zero, roda testes automáticos e verificações de qualidade e segurança, publica em homologação para conferência e depois em produção, guardando cada versão para que seja possível voltar atrás se algo der errado.

Como a Pervian Tech trabalha pipelines de entrega

Na Pervian Tech, todo sistema que construímos nasce com esteira de integração e entrega contínuas, testes nos fluxos críticos, ambientes separados e volta de versão testada. Para sistemas que já existem, o trabalho de cloud e DevOps começa por entender como a publicação acontece hoje, onde estão os riscos e quais fluxos não podem parar. A partir daí montamos a esteira sob medida, em etapas, sem interromper a operação, e com o repositório e as configurações sempre em nome do cliente.

O diagnóstico inicial é gratuito e o investimento é definido sob consulta, conforme o tamanho e o estado do sistema. Para mais conteúdos sobre o tema, veja a categoria cloud e infraestrutura. Se publicar uma versão ainda tira o sono da sua equipe, conte como é o processo hoje.