Close

Entrega contínua: valor comercial, benefícios, desafios e métricas

A entrega contínua melhora a velocidade, a produtividade e a sustentabilidade das equipes de desenvolvimento.

Foto de Juni Mukherjee
Juni Mukherjee

Autor colaborador

Por que entrega contínua?


Que emoções a palavra "versão" desperta em você? Alívio? Alegria intensa? Sensação de realização com pulos e socos no ar? Quando recursos novos são lançados para os clientes e bugs corrigidos, todo mundo fica feliz, certo? Bom, o segredo em muitas empresas é que lançar uma versão exige uma quantidade enorme de esforço. Se a equipe ainda estiver vivendo com testes manuais para preparar versões e implementações manuais ou com semi-script para execução delas, seus sentimentos talvez estejam próximo do "medo" e da "raiva pura".

Captura de tela do ciclo emocional de entrega manual

É por esse motivo que o desenvolvimento de software está avançando na direção da continuidade, por meio de metodologias ágeis e de DevOps. No paradigma contínuo, produtos de qualidade são lançados com frequência e previsão aos clientes. Portanto, a cerimônia e o risco em torno do lançamento são reduzidos. Se você estiver contando com os pipelines todos os dias, vai observar (e resolver!) as deficiências com muito mais rapidez em vez de eles fluírem uma vez por semanas ou meses. Ou seja, reduza a dificuldade aumentando a frequência dos lançamentos dos produtos. Uma cultura de melhoria contínua é uma métrica do DevOps para equipes de alto desempenho.

A ênfase na entrega contínua, incluindo integração contínua, testes contínuos, monitoramento constante e dados de análise de pipeline, aponta para a tendência geral no setor de software — ajudar as equipes a reagir às alterações do mercado. Não se engane, a CD não é o domínio exclusivo de empresas "unicórnios" e queridinhas da tecnologia. Cada equipe — da startup mais humilde à empresa mais robusta — pode e deve praticar a entrega contínua.

Este artigo analisa o caso de negócios para fazer essa mudança. Ele discutirá o trabalho à frente e os benefícios que serão gerados para enviar software usando pipelines de CD.

Ver solução

Crie e opere softwares com o Open DevOps

Material relacionado

Meça a frequência de implementações

Principais benefícios de negócios da entrega contínua


A entrega contínua melhora a velocidade, a produtividade e a sustentabilidade das equipes de desenvolvimento de software.

1. Velocidade

Os pipelines de entrega de software automatizados ajudam as empresas a responder melhor às mudanças do mercado. A necessidade de velocidade é de extrema importância para reduzir o tempo de prateleira de recursos novos. Com tempo baixo de entrega para o mercado, as empresas têm uma chance melhor de superar a concorrência e permanecer nos negócios.

Tenha em mente que a velocidade por si só não é uma métrica de sucesso. Sem qualidade, a velocidade é inútil. Não existe valor em ter pipelines de entrega contínua lançando códigos errados na produção em alta velocidade.

Bug

Assim, no mundo da entrega contínua, a velocidade quer dizer velocidade responsável e não velocidade suicida.

2. Produtividade

Produtividade converte-se em felicidade, e equipes felizes são mais engajadas.

A produtividade aumenta quando tarefas repetitivas e tediosas, como preencher um relatório de bugs para cada defeito descoberto, podem ser realizadas por pipelines, em vez de humanos. Isso permite às equipes focar a visão enquanto os pipelines cuidam da execução. E quem não quer delegar o trabalho pesado para ferramentas?

As equipes investigam problemas relatados pelos seus pipelines e, quando confirmam a correção, os pipelines são executados novamente para validar se o problema foi corrigido e se novos problemas foram introduzidos inadvertidamente.

Pessoas olhando para um fluxo de trabalho de desenvolvimento de software

3. Sustentabilidade

As empresas têm como objetivo vencer maratonas, não apenas corridas curtas. Sabemos que sair na frente requer determinação. Manter-se à frente de modo consistente pode ser ainda mais difícil. Requer disciplina e rigor. Trabalhar duro 24 horas por dia, sete dias por semana leva a esgotamentos prematuros. Em vez disso, trabalhe de modo inteligente e delegue o trabalho repetitivo para as máquinas, que, por sinal, não precisam de café nem contestam!

Cada organização, seja ou não uma empresa técnica, está usando tecnologia para diferenciar-se. Pipelines automatizados reduzem o trabalho manual e levam a eventuais economias, já que pessoal custa mais que ferramentas. O alto investimento antecipado pode causar preocupação a uma liderança inexperiente, porém, pipelines bem projetados posicionam as organizações a inovar melhor e mais rapidamente para atender às necessidades dos clientes. CD proporciona mais flexibilidade à empresa em como ela entrega recursos e correções. Conjuntos específicos de recursos podem ser lançados para clientes específicos, ou para um subconjunto de clientes, para garantir que funcionem e sejam dimensionados conforme o planejado. Os recursos podem ser testados e desenvolvidos, mas deixados dormentes no produto, prontos para versões futuras. Seu departamento de marketing deseja aquele grande impacto na convenção anual do setor? Com entrega contínua, isso não é apenas possível, é uma solicitação trivial.

Principais desafios da entrega contínua


Embora acreditemos firmemente que a entrega contínua é a coisa certa a fazer, pode ser desafiador para as organizações desenvolverem e criarem pipelines de entrega contínua. Uma vez que CD requer uma grande reforma nos processos técnicos, na cultura operacional e no pensamento organizacional, muitas vezes pode parecer que há uma grande barreira para começar. A verdade é que exige uma grande quantidade de investimento na infraestrutura de entrega de software da empresa que pode ter sido negligenciada ao longo dos anos, complicando ainda mais a situação.

Existem muitos problemas que as empresas enfrentam e os três a seguir são as armadilhas mais comuns: orçamento, pessoas e prioridade.

Orçamento: o seu é baixo demais?

A construção de pipelines contínuos consome seus melhores funcionários. Esse não é um projeto lateral cujos custos possam ser varridos para baixo do tapete. Sempre fiquei surpreso em como algumas organizações começam alocando membros juniores e cortando gastos na compra de ferramentas modernas. Em algum ponto, elas corrigem o curso e atribuem arquitetos seniores para investirem em desacoplamento de arquitetura e pipelines de entrega contínua resilientes.

Não desvalorize. Com base na sua visão, separe uma quantidade adequada de fundos para garantir que a execução seja ininterrupta. Gere um pipeline de entrega contínua MVP (produto mínimo viável) e então dimensione-o em toda a sua organização.

Você tem pessoas com pensamento inovador?

Mesmo quando você tem o orçamento, no final das contas, a execução pode ser uma questão de pessoas.

As equipes devem se automatizar sem medo das tarefas e seguir em frente para novos projetos. Se você tem funcionários que estão apreensivos por conta de agentes automatizados que realizam tarefas que estavam sendo feitas por meio manual, você está empregando as pessoas erradas.

Caso você se sinta estagnado, mude a marcha. Saiba como dar à sua equipe um carro quando ela pediu um cavalo mais rápido! Comece rapidamente com a ajuda de líderes experientes que o acompanharão nesse desafio inicial. As pessoas, afinal, são os seus principais ativos, então treine-as para fazer a coisa certa. Torne fácil fazer a coisa certa e difícil fazer a errada e você ficará positivamente surpreso com o resultado.

Falta de prioridade

Nunca nenhum proprietário de produto disse: "Vamos parar a fila e criar pipelines de entrega contínua".

Em defesa delas, estão focadas em ficar à frente da concorrência com novos recursos que encantem o mundo. Ao mesmo tempo, você sabe que tem um problema se, em cada planejador de sprint, os pipelines forem pesados com relação a recursos de produto e forem feitas concessões.

Em alguns backlogs de produtos, os pipelines, se eles sequer aparecem, esperam a vida toda no fim da fila. As lideranças de visão curta classificam trabalhos relacionados a pipelines como despesas, em vez de investimentos que manterão as equipes em uma boa posição. Elas permanecem em negação do dano a longo prazo criado e, infelizmente, às vezes saem incólumes.

Os pipelines são como a saúde. Se você quiser se manter nos negócios, pergunte a si mesmo: "saúde é importante?" Pode apostar que sim!

Métricas de entrega contínua


OLTP (processamento de transação on-line) e OLAP (processamento analítico on-line) são duas técnicas bem conhecidas no setor. Ambos os conceitos se aplicam a pipelines de entrega contínua e ajudam a gerar insights que conduzem as organizações na direção certa. Vamos ver como.

Pipelines veem hordas de dados transacionais

Imagine um dia típico na vida de uma equipe de desenvolvimento de software. A equipe faz o commit de um recurso priorizado pelos negócios, de testes para esse recurso e integra implementações com o pipeline de entrega contínua, para que cada mudança seja implementada no automático. A equipe percebe que o aplicativo ficou lento após adicionar esse recurso novo e faz o commit de uma correção para o item de desempenho. A equipe também adiciona testes de desempenho para garantir que tempos de resposta ruins sejam detectados antes de promover o aplicativo de teste para staging.

Pense em cada um desses commits como uma transação. E é assim que as equipes de desenvolvimento de software operam, uma transação após a outra, até que nasça um produto que encante o mundo. Então lá vão elas outra vez. Multiplique essas transações entre todos os engenheiros e equipes na sua organização e você terá hordas de dados transacionais ao seu dispor.

Ilustração de dois colegas de trabalho olhando um para o outro, sentados à mesa com monitores

Essa é uma boa transição para a próxima seção sobre análise de pipeline e como aproveitar ao máximo os dados transacionais.

Vamos analisar os dados de transação do pipeline

Poderíamos analisar os dados transacionais para extrair pepitas de informação? Com certeza!

Como acontece com todos os dados transacionais, o grande volume nos impede de fazer qualquer sentido. É por essa razão que a gente deve agregar e realizar análises para colher dados sobre a empresa. As análises ajudam a ver o panorama geral e aqui estão três exemplos de como melhorar as práticas de análises e dados de pipeline.

Das centenas de implementações que acontecem todas as semanas, a gente aprendeu que o número de falhas de implementação do aplicativo A é três vezes maior do que o do aplicativo B. Essa descoberta nos levou a investigar as opções de design do aplicativo A sobre estabilidade do ambiente e gerenciamento de configuração. A gente aprendeu que a equipe usava máquinas virtuais instáveis no data center para implementar, enquanto o aplicativo B era armazenado em contêineres. A gente priorizou um investimento em infraestrutura imutável e verificou em um mês para ter certeza de que o retorno desse investimento foi bom. Com certeza, foi. O que pode ser medido, pode ser corrigido.

Outro exemplo é quando aprendemos que os erros de análise de código estático do aplicativo B vieram crescendo continuamente nos últimos trimestres. Isso poderia significar que a equipe por trás do aplicativo B precisa ser treinada novamente para escrever código melhor. Também descobrimos que os analisadores de código estático relataram falsos-positivos, o que significa que sinalizaram violações de código quando não havia nenhuma. Assim, fizemos o upgrade do analisador para uma ferramenta padrão bem conhecida do setor, e os falsos-positivos diminuíram em alguma medida. Organizamos uma oficina de código em que discutimos e resolvemos os erros de análise estática legítimos. Ao final, a equipe estava alinhada novamente.

Outro insight interessante foi que testes de unidade do aplicativo A tinham menos cobertura de código que os aplicativos B e C e, ainda assim, o aplicativo A teve o menor número de problemas de produção no ano. Não há problema em escrever testes de unidade e medir cobertura de código. Realizar esse exercício excessivamente é improdutivo para a equipe e inútil para o cliente. Lição aprendida.

Indicadores-chave de desempenho (KPIs)

A gente não pode contar com opiniões para conduzir a empresa na direção certa. Primeiro, a gente precisa definir KPIs de acordo com a definição de sucesso. Segundo, é preciso tomar decisões conduzidas por dados analisando KPIs em meses, trimestres e anos.

KPIs organizacionais vs. KPIs departamentais

Muitas vezes, vimos departamentos individuais definirem as próprias métricas de sucesso. É bom que os departamentos entendam o que é o sucesso para eles, desde que essas métricas estejam vinculadas às metas da organização.

Falhas no teste vs. staging vs. produção

Algumas organizações exigem que os desenvolvedores assumam o ambiente de teste, o QA assuma o staging e a área de operações assuma a produção. Em vez de os desenvolvedores serem soterrados em relatórios de cobertura de código para testes de unidade executados no ambiente de teste, é importante que recuem e olhem para o panorama geral em todos os ambientes, sejam de responsabilidade deles ou não.

A porcentagem de falhas no staging devido a testes de desempenho pode ser alta e pode ser devido a referências de desempenho incorretas ou código lento. Uma análise comparativa pode mostrar que os pipelines falham mais nos testes de sanidade de integração na produção e seria o suficiente para justificar uma investigação. A causa raiz pode ser bugs reais no produto ou código de teste com bugs, dados de teste imprecisos, configuração de teste incorreta, desentendimentos entre o produto e a engenharia e assim por diante.

Analisar mais a fundo poderia revelar que configurações de teste incorretas estão em alta e você poderia priorizar corrigir esses itens para corrigir falhas de integração frequentes. Além disso, os desenvolvedores que são responsáveis pelo próprio código até a produção também estão de acordo com o paradigma de DevOps.

Índice de estabilidade

Depois de definir os KPIs, é essencial entender se um único KPI tem tendência e se inclina em qualquer direção particular. Caso aconteça, a gente precisa equilibrar esse KPI com outros que colocam o centro de gravidade próximo ao meio. Um desses KPIs é a estabilidade.

Os desenvolvedores medem a estabilidade com FeatureLeadTime, que é o tempo que leva para um recurso ser ativado na produção. Um recurso inclui diversos commits. Assim, uma medida mais granular de FeatureLeadTime é CheckIn2GoLive, que é o tempo que leva para uma verificação ser ativada na produção.

Meça o CheckIn2GoLive por meio de pipelines, uma vez que ele pode ser aproximado pelo tempo que um pipeline leva para promover o código do teste ao staging e à produção. Além disso, o CheckIn2GoLive também reflete defeitos de MTTR (tempo médio para a resolução), uma vez que a correção do bug passa pelo mesmo pipeline do teste ao staging e à produção.

É interessante que, quando perguntei aos funcionários de operações, a velocidade costuma ter uma conotação negativa, já que eles são incentivados a serem avessos a risco. Eles medem o número de defeitos que escaparam para refletir a falha, então definem a estabilidade pelo percentual de defeitos que capturaram pelo pipeline em oposição aos defeitos que escaparam.

As empresas definem estabilidade pela satisfação do cliente ou pelo número de clientes recorrentes. Embora pareça subjetivo, você pode aproximar essa métrica pelo número de defeitos levantados pelos clientes ou com pesquisas de feedback do cliente.

O índice de estabilidade é um exemplo clássico, em que desenvolvimento, operações e negócios têm opiniões da própria perspectiva, porém, o melhor para a organização é criar uma combinação, em vez de confiar em apenas uma. Assim, crie um índice organizacional para estabilidade que seja imparcial.

Índice de qualidade do código

Outro exemplo em que diferentes pontos de vista precisam ser considerados é a qualidade do código. Alguns dizem que a qualidade do código se reflete pela cobertura do código medida por testes de unidade, enquanto outros dizem que é uma complexidade ciclomática. Analisadores estáticos padrão relatam duplicação de código, vulnerabilidades de segurança e possíveis vazamentos de memória em potencial. Todas essas são medidas de qualidade do código e, assim, criam um índice em que todas elas, e possivelmente outras, desempenham um papel.

KPIs de negócio vs. KPIs técnicos

Outro KPI popular que as organizações gostam de acompanhar é o valor entregue em um sprint. Uma prática comum é registrar o número de versões que, por si, não agrega valor. Você poderia mover bits do ponto A para o ponto B sem ter sua empresa em mente, e isso não é bom o bastante. Algumas organizações medem o número de testes recém-adicionados naquele sprint, ou o número total de testes executados, e isso não reflete os resultados de negócio também, apenas o esforço de engenharia. O valor entregue em um sprint precisa ser relevante para os negócios.

Alguns exemplos de KPIs de negócios poderiam ser o número de aquisições de clientes no último trimestre e o número de cliques em anúncios no último mês. Pipelines não influenciam diretamente essas métricas de negócios. O único motivo pelo qual tentamos mapear KPIs de negócios para KPIs técnicos é entender a relação da habilidade técnica com as metas de negócio.

KPIs de negócios, quando mapeados para pipelines, também nos ajudam a calcular o ROI (retorno do investimento) dos pipelines. As equipes de liderança usam essas métricas para entender possíveis áreas de melhoria e planejar o orçamento.

Embarque em uma jornada


Não perca tempo discutindo se a entrega contínua é a escolha certa para você, ou se a integração contínua é suficiente, ou se a implementação contínua é o sétimo céu. Se embarcar nessa jornada, vai abrir novos caminhos de oportunidades para a sua equipe continuar a melhorar! Isso vai ajudar suas equipes a experimentar sem medo e não se esgotar devido às" liberações de óleo à " meia-noite.

Saiba como criar o pipeline de integração, implementação (IC/CD) e entrega contínuas com os tutoriais de IC/CD do DevOps. E mais: o Open DevOps da Atlassian oferece a plataforma aberta de cadeia de ferramentas que permite gerar o pipeline de desenvolvimento baseado em implementação contínua com as ferramentas favoritas da equipe.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.


Compartilhe este artigo

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Ilustração DevOps

Comunidade de DevOps

Ilustração DevOps

Leia o blog

Ilustração do mapa

Comece gratuitamente

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up