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

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 funções novas. 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.

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.

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 funções e correções. Conjuntos específicos de funções podem ser lançados para clientes específicos, ou para um subconjunto de clientes, para garantir que funcionem e sejam dimensionados conforme o planejado. As funções podem ser testadas e desenvolvidas, mas deixadas 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.

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 economize. Com base na sua visão, separe uma quantia adequada de fundos para garantir que a execução seja ininterrupta. Gere e, então, escale um MVP (produto mínimo viável) de pipeline de entrega contínua em toda a 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 novas funções 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 funções 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!

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 uma função priorizada pelos negócios, de testes para essa função 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 essa função 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.

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 uma função ser ativada na produção. Uma função 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