Configurar um Pipeline de CI/CD em Duas Horas: Porque Só 21% o Conseguem
Só 21% das equipas conseguem pôr um pipeline de construção e implantação a funcionar num ambiente novo em menos de duas horas. O tempo que falta não é técnico: é a espera entre equipas. Um caminho padrão com autoatendimento resolve a maior parte.
Um serviço novo está pronto para sair do portátil de quem o escreveu. Falta pô-lo a correr num ambiente partilhado: construir, analisar, testar e implantar. Na maior parte das organizações, este passo não se mede em minutos. Mede-se em pedidos.
Um pedido para criar o ambiente. Outro para as credenciais. Outro para a análise de segurança. Outro para a aprovação de quem gere a infraestrutura. Cada um com a sua fila.
O que diz o relatório
O inquérito foi feito em Fevereiro de 2026 pela Coleman Parkes, a pedido da Harness, a 700 profissionais e gestores de engenharia de grandes empresas nos Estados Unidos, Reino Unido, Alemanha, França e Índia. É um valor declarado, não medido, mas o padrão que descreve é reconhecível.
O mesmo relatório explica onde está o atraso. Mais de três quartos dos inquiridos, 77%, dizem que as equipas esperam frequentemente por outras em trabalho de entrega de rotina antes de conseguirem pôr código em produção. E 69% admitem perder tempo com pipelines lentos ou instáveis, que associam ao desgaste das equipas.
Duas horas como medida de dependência
O tempo para pôr um pipeline novo a funcionar raramente mede a competência técnica da equipa. A configuração de um pipeline de integração e entrega contínuas (CI/CD) é conhecimento estabelecido. O que o tempo mede é quantas equipas e quantos pedidos ficam entre o código e o ambiente onde ele vai correr.
Por isso, contratar mais pessoas para responder a pedidos não encurta o caminho. Aumenta a capacidade da fila, mas a fila continua lá.
Onde se perde o tempo
Os passos que costumam depender de outra equipa repetem-se de organização para organização:
- Ambiente: criar o espaço onde o serviço vai correr, com rede e permissões.
- Credenciais e segredos: obter acesso a bases de dados, filas e serviços externos.
- Segurança: análise de dependências e de imagens antes de qualquer implantação.
- Configuração do pipeline: escrever, ou copiar e adaptar, a definição de construção e implantação.
- Aprovação: autorização para a primeira implantação num ambiente partilhado.
Cada passo é razoável isoladamente. O problema é a soma das esperas.
E as esperas não se somam de forma linear. Um pedido que fica parado ao fim do dia só volta a andar na manhã seguinte. Um pedido que volta com uma pergunta regressa ao fim da fila. A equipa que espera muda de tarefa entretanto e, quando a resposta chega, tem de retomar o contexto. O resultado é que um percurso de cinco passos simples pode ocupar vários dias de calendário sem que ninguém tenha estado a trabalhar nele mais de uma hora.
Há ainda um efeito menos visível. Quando pôr um serviço a correr é caro, as equipas evitam criar serviços novos e acrescentam funcionalidades aos que já existem. A arquitectura passa a ser decidida pelo custo da fila, e não pelo desenho que faria sentido.
O caminho padrão
A Cloud Native Computing Foundation (CNCF) descreve, no seu documento sobre plataformas, uma resposta concreta: um fluxo reutilizável para construir, analisar, testar, implantar e observar uma aplicação, oferecido com um modelo de projecto inicial e documentação. É a este conjunto que se costuma chamar caminho padrão, ou "golden path".
Na prática, a equipa não escreve um pipeline do zero. Parte de um modelo que já integra a construção, a análise de segurança, os testes e a implantação, e ajusta apenas o que é específico do serviço.
Autoatendimento com regras
O mesmo documento da CNCF define duas propriedades que mudam a conta do tempo.
A primeira é o autoatendimento: quem usa a plataforma deve conseguir pedir e receber capacidades de forma autónoma e automática, sem intervenção manual de outra equipa. Um ambiente ou uma base de dados pedidos por um comando ou por um formulário, e entregues com as credenciais.
A segunda é a segurança por omissão. As regras de segurança e as aprovações vivem dentro do modelo, em vez de serem pedidas caso a caso. A equipa de plataforma decide as regras uma vez; cada equipa de produto aplica-as ao activar o modelo.
É esta combinação que transforma uma sequência de pedidos num único passo controlado.
O que o caminho padrão não é
O caminho padrão não é uma obrigação nem uma camisa de forças. O documento da CNCF é explícito: a plataforma deve ser opcional e combinável, e permitir que as equipas de produto forneçam e gerem as suas próprias capacidades fora da oferta da plataforma quando for necessário. O modelo serve o caso comum; o caso invulgar continua possível, com mais esforço e mais responsabilidade para quem o escolhe.
Também não transfere a operação para as equipas de produto. A mesma fonte define que a plataforma deve esconder os detalhes de implementação, e que quem a usa não deve ser responsável por operar os serviços que ela oferece. A equipa activa o modelo; a equipa de plataforma mantém o que está por baixo.
Como medir
Três medidas simples chegam para saber se o caminho está a encurtar:
- Tempo do pedido à primeira implantação de um serviço novo num ambiente partilhado.
- Número de passos com espera por outra equipa nesse percurso.
- Proporção de pipelines que seguem o modelo, contra os escritos de raiz.
A estas soma-se a estabilidade. Um pipeline rápido de criar e lento ou instável a correr volta a gerar espera, e é esse o tempo que 69% dos inquiridos dizem perder.
Por onde começar
Não é preciso construir uma plataforma completa para encurtar o caminho. Um percurso prático começa por quatro passos:
- Escolher o tipo de serviço mais frequente, aquele que a organização cria mais vezes.
- Mapear o percurso actual desse serviço, do pedido à primeira implantação, com cada espera identificada.
- Transformar em autoatendimento o passo com mais espera, mantendo as regras que já existiam.
- Medir de novo o tempo do pedido à primeira implantação e repetir com o passo seguinte.
Cada volta retira uma fila do caminho. O modelo completo surge da soma destas voltas, e não de um projecto desenhado de raiz.
Cinco perguntas antes de declarar a entrega autónoma
- Existe um modelo de pipeline aprovado que qualquer equipa pode activar sem pedido?
- As análises de segurança e as aprovações estão dentro do modelo?
- Um ambiente novo é criado por autoatendimento, com credenciais incluídas?
- Alguém mede o tempo do pedido à primeira implantação?
- Existe uma equipa ou um responsável pela manutenção do caminho padrão?
Conclusão
Duas horas não é um alvo técnico difícil. É um alvo de organização. Enquanto pôr um serviço a correr depender de uma cadeia de pedidos, a velocidade de entrega fica limitada pela fila mais lenta, e não pela equipa que escreveu o código.
A diferença entre comprar capacidade e montar uma plataforma que funcione está descrita em Platform Engineering Outsourcing, e o enquadramento de quando faz sentido reforçar a equipa interna está em DevOps as a Service, quando faz sentido. Para avaliar o caminho até produção e desenhar o caminho padrão, é possível agendar uma Sessão de Esclarecimento, sem compromisso.