São dez da noite de uma quinta-feira. O time avisou que a nova versão sobe hoje, e a empresa inteira sabe o que isso significa: ninguém mexe no sistema, o suporte fica de sobreaviso e alguém precisa estar disponível no celular caso algo quebre. O responsável abre o notebook, roda uma sequência de comandos que só ele conhece de cor, copia arquivos, reinicia o servidor e torce.
Deu certo. Deu certo nas últimas onze vezes também. O problema é que essa pessoa vai tirar férias em janeiro, e ninguém mais na empresa sabe repetir aquela sequência. Quando alguém pergunta se tem um passo a passo escrito, a resposta é sempre a mesma: está tudo na cabeça dele.
A tese deste texto é simples. Publicar uma versão não deveria ser um evento. Quando subir sistema exige coragem, horário especial e uma pessoa insubstituível, o gargalo não é a competência do time: é a ausência de processo. E esse gargalo cobra um preço que quase nunca aparece na planilha de custos de TI.
O que é deploy e o que é uma esteira de CI/CD?
Deploy é o ato de colocar uma nova versão do software no ar, disponível para quem usa. Uma esteira de CI/CD é o mecanismo automático que faz esse caminho sozinho: recebe o código novo, testa, monta a versão e publica, sem alguém digitando comandos manualmente.
As duas letras significam coisas distintas e complementares. A integração contínua é a parte que verifica: toda vez que alguém altera o código, um robô roda a bateria de testes e avisa em minutos se algo quebrou. A entrega contínua é a parte que publica: uma vez aprovado, o mesmo mecanismo leva aquela versão para o ambiente de teste e, com um clique, para produção.
A analogia mais próxima é a linha de produção de uma fábrica. Antes, cada peça era montada à mão por um artesão que conhecia o segredo. Depois, a montagem virou processo documentado, repetível e conferido em cada etapa. O artesão continua sendo essencial, mas para desenhar a peça, não para apertar cada parafuso pela milésima vez.
Por que subir uma versão virou um evento na sua empresa?
Quase sempre por acúmulo, não por decisão. No começo, o sistema era pequeno e publicar levava cinco minutos. Automatizar parecia perda de tempo. Aí o sistema cresceu, ganhou banco de dados, integrações, área logada, e cada publicação passou a envolver mais passos. Ninguém parou para automatizar porque nunca houve uma semana calma para isso.
O resultado é um ciclo que se retroalimenta. Como publicar dá trabalho, o time publica menos. Como publica menos, cada versão acumula mais mudanças. Como cada versão traz mais mudanças, a chance de algo quebrar aumenta. Como a chance de quebrar aumenta, o time passa a ter medo de publicar. E o medo faz publicar ainda menos.
É por isso que empresas nessa situação convivem com prazos que escorregam sem explicação clara. A funcionalidade ficou pronta em uma terça, mas só chega ao cliente três semanas depois, quando abre a próxima janela de publicação. O tempo de desenvolvimento não foi o problema: o tempo de espera na fila foi.
Quanto custa depender de uma única pessoa para publicar?
O custo é real e some da vista porque está espalhado em rubricas diferentes. Vale listar:
- Indisponibilidade programada. Se cada publicação exige tirar o sistema do ar por trinta minutos, e isso acontece duas vezes por mês, são doze horas por ano de operação parada. Numa empresa que vende pelo sistema, isso é receita que não entrou.
- Atraso entre pronto e entregue. Funcionalidade concluída que fica esperando janela é capital parado. O investimento já foi feito, mas o retorno só começa quando o cliente usa.
- Risco de pessoa única. Férias, doença ou pedido de demissão do responsável travam a evolução do produto. Já vimos empresas ficarem seis semanas sem conseguir publicar uma correção simples por esse motivo.
- Correção lenta em emergência. Quando um bug crítico aparece numa sexta à tarde, a diferença entre corrigir em vinte minutos e corrigir na segunda de manhã é medida em clientes perdidos.
- Erro humano. Um passo esquecido na sequência manual derruba o sistema por motivo bobo. Quanto mais raro o procedimento, mais fácil errar.
Some tudo e o valor costuma superar, com folga, o esforço de automatizar. A conta raramente é feita porque nenhuma dessas linhas tem nome próprio no orçamento.
O que muda na prática quando a publicação é automática?
A mudança mais visível é de frequência. Times com esteira madura publicam várias vezes por semana, às vezes por dia, no meio do expediente, sem aviso e sem plateia. Cada publicação carrega pouca coisa, então quando algo dá errado é óbvio o que causou.
A segunda mudança é a possibilidade de voltar atrás. Numa esteira bem montada, desfazer uma versão problemática é uma operação de dois minutos, não uma madrugada de reconstrução. Isso muda a psicologia do time inteiro: publicar deixa de ser irreversível e vira reversível, e decisão reversível se toma rápido.
A terceira é a qualidade que entra sem esforço adicional. Como a esteira roda os testes automaticamente a cada mudança, problemas aparecem em minutos, enquanto quem escreveu ainda lembra do contexto. Isso reduz o acúmulo de remendos que descrevemos ao falar de dívida técnica e mantém o custo de manutenção previsível ao longo dos anos.
Quanto custa e quanto demora para montar essa esteira?
Depende do estado atual, mas a faixa é mais modesta do que a maioria imagina. Para um sistema de porte médio já hospedado em nuvem, montar publicação automatizada, ambiente de homologação separado e retorno rápido de versão costuma ser um trabalho de duas a quatro semanas de uma pessoa experiente. Trate esses números como ordem de grandeza para orientar conversa, não como orçamento.
O que encarece não é a esteira em si: são as pendências que ela revela. Sistema sem nenhum teste automatizado precisa ganhar ao menos uma camada mínima de verificação. Configuração de produção espalhada em arquivos manuais precisa ser organizada. Banco de dados sem controle de versão de estrutura precisa ganhar esse controle. Nada disso é trabalho perdido: é a mesma base que sustenta a manutenção de software nos anos seguintes.
Vale começar pequeno. Automatizar primeiro a publicação em homologação, deixando produção manual, já elimina metade do risco e prova o valor em duas semanas. Empresas que tentam montar a esteira perfeita de uma vez costumam não terminar.
Como avaliar se o seu fornecedor tem processo de publicação?
Você não precisa entender de tecnologia para fazer as perguntas certas. Cinco delas revelam quase tudo, e nenhuma exige vocabulário técnico:
- Quantas vezes vocês publicaram no último mês? Uma ou duas indica processo pesado. Oito ou mais indica esteira funcionando.
- Se a versão de hoje der problema, em quanto tempo voltamos à anterior? Resposta em minutos é bom sinal. Resposta em horas, ou hesitação, é sinal de que não existe caminho de volta ensaiado.
- Existe um ambiente igual ao de produção para testar antes? Testar direto em produção com clientes reais é o padrão que mais gera incidente evitável.
- Quantas pessoas do time conseguem publicar sozinhas? Se a resposta for uma, o risco de pessoa única é do seu negócio, não do fornecedor.
- Vocês conseguem publicar no horário comercial? Quem só publica de madrugada está dizendo, sem dizer, que não confia no próprio processo.
Essas respostas cabem naturalmente no acordo de nível de serviço que você já deveria manter com quem cuida do seu sistema, assunto que detalhamos ao tratar de indicadores e SLA de fornecedor de TI. E complementam bem a rotina de monitoramento de sistemas, porque publicar rápido sem enxergar o efeito da publicação é apenas errar mais rápido.
Publicar sem drama é o melhor termômetro de maturidade técnica
Existem muitos indicadores para avaliar a saúde técnica de um sistema, e a maioria exige um especialista para interpretar. Este não exige. Pergunte com que frequência a empresa consegue colocar uma melhoria no ar e o que acontece quando dá errado. A resposta descreve, em uma frase, o quanto o seu negócio depende de heroísmo individual.
Se o seu fornecedor não consegue publicar duas vezes na mesma semana sem transtorno, o problema provavelmente não é a competência da equipe: é o processo em volta dela. E processo, diferente de talento, se compra e se instala em poucas semanas.
Na DevCore, montamos e operamos esteiras de publicação automatizada dentro dos nossos serviços de DevOps, tanto para sistemas que desenvolvemos quanto para sistemas de terceiros que herdamos. Se subir versão na sua empresa ainda é um evento noturno, fale com o nosso time e vamos avaliar juntos o caminho mais curto para tirar essa dependência do caminho.
Perguntas frequentes sobre deploy automatizado
Automatizar a publicação aumenta o risco de subir erro para produção?
Acontece o contrário. A esteira só publica depois que a bateria de testes passa, o que hoje quase sempre é conferido apenas pela atenção de quem está publicando. O que a automação faz é transformar uma verificação que dependia de memória em uma verificação que acontece sempre, igual, mesmo numa sexta às dezoito horas.
Meu sistema é antigo e não roda em nuvem. Ainda dá para automatizar?
Dá, e o ganho costuma ser maior justamente nesses casos, porque o procedimento manual é mais longo. Sistemas hospedados em servidor próprio também aceitam publicação automatizada. A migração para nuvem pode até fazer sentido depois, mas não é pré-requisito para começar.
Preciso de um profissional dedicado de DevOps para manter isso?
Para empresas pequenas e médias, normalmente não. A esteira exige esforço concentrado na montagem e pouca atenção depois, o que torna comum contratar a implantação como projeto e manter apenas um acompanhamento mensal. Um profissional dedicado passa a fazer sentido quando existem vários sistemas e times publicando ao mesmo tempo.