Valor de negócios da entrega contínua

Continuous delivery improves velocity, productivity, and sustainability of development teams.

Juni Mukherjee Juni Mukherjee

Por que entrega contínua?

What emotions does the word "release" trigger in you? Relief? Elation? A fist-pumping sense of accomplishment? When new features are finally out to customers and bugs are fixed, everyone's happy, right? Well, the dark secret in many organizations is that shipping a release takes a huge amount of effort. If your team is still living with manual testing to prepare for releases and manual or semi-scripted deploys to perform them, your feelings may be closer to "dread" and "blinding rage".

Emotional cycle of manual delivery screenshot | Atlassian CI/CD

É por isso que o desenvolvimento de software está avançando na direção da continuidade. No paradigma contínuo, produtos de qualidade são lançados com frequência e de modo previsível aos clientes. Portanto, a cerimônia e o risco em torno do lançamento são reduzidos. Se você estiver contando com seus pipelines diariamente, observará (e resolverá!) suas 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 de seus lançamentos de produto.

The emphasis on continuous integration, continuous testing, constant monitoring, and pipeline analytics all point toward an overall trend in the software industry - increasing your ability to react to market changes. Make no mistake - CD is not the exclusive domain of "unicorn" companies and tech darlings. Every team – from the humblest start-up to the stodgiest enterprise – can and should practice continuous delivery.

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.

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.

First off, velocity

Automated software delivery pipelines help organizations respond to market changes better. The need for speed is of utmost importance to reduce shelf time of new features. With a low Time2Market, organizations have a better chance to outmaneuver their competition and stay in business.

Remember that speed by itself is not a success metric. Without quality, speed is useless. There is no value in having continuous delivery pipelines shoot erroneous code into production at speed.

Bug de segurança

So, in the world of continuous delivery, velocity means responsible speed, and not suicidal speed.

Segundo, 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.

Software Development

Third, sustainability

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.

Top challenges of continuous delivery

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.

There are many problems that organizations face and the following three are the most common pitfalls - budget, people, and priority.

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.

Teams should fearlessly automate themselves out of their jobs, and move on to new projects. If you have people who are apprehensive of automated agents performing tasks they were otherwise doing manually, you are housing the wrong people.

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.

Pipelines are hygiene. If you want to stay in business, ask yourself “Is hygiene important?”. You bet it is!

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 a typical day in a software development team’s life. The team commits a feature that business prioritized, commits tests for that feature, and integrates deployments with the continuous delivery pipeline, so that every change deploys automatically. The team realizes that the application got sluggish after adding this new feature, and commits a fix for the performance issue. The team also adds performance tests to make sure that bad response times would get caught before promoting the application from test to staging.

Pense em cada uma dessas confirmações 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.

Profissional

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!

Like with all transactional data, the sheer volume prevents us from making any sense. That’s why we should aggregate, and perform analytics to glean insights into our organization. Analytics help us see the forest through the trees, and here are three examples how we improved our practices from pipeline analytics and insights.

Out of the hundreds of deployments that happen every week, we learned that the number of deployment failures of application A are thrice as high as those of application B. This discovery led us to investigate application A’s design choices on environment stability and configuration management. We learned that the team used flaky virtual machines in their data center to deploy, while application B was containerized. We prioritized an investment into immutable infrastructure and checked back in a month to make sure the return on that investment was good. Sure enough, it was. What can be measured, can be fixed.

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)

Não podemos contar com opiniões para conduzir a organização na direção certa. Primeiro, precisamos definir KPIs com base no que é o sucesso. Segundo, precisamos 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.

The percentage of failures in staging due to performance tests could be high, and it could be due to incorrect performance benchmarks or sluggish code. A comparative analysis might show that pipelines fail the most on integration smoke tests in production, and that would warrant an investigation. The root cause could be real bugs in the product or could be buggy test code, inaccurate test data, incorrect test configuration, misunderstandings between product and engineering, and the like.

Analisar mais a fundo poderia revelar que configurações de teste incorretas estão em alta, e você poderia priorizar corrigir esses problemas 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 esse paradigma de DevOps.

Índice de estabilidade

Once we define KPIs, it is critical for us to understand if a single KPI has bias and skews heavily in any one particular direction. In case it does, we need to balance it with other KPIs that puts the center of gravity close to the middle. One such KPI is stability.

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

Measure CheckIn2GoLive via pipelines, since this can be approximated by the time a pipeline takes to promote code from test to staging to production. Additionally, CheckIn2GoLive also reflects MTTR (mean time to resolve) defects, since the bug fix travels through the same pipeline from test to staging to production.

É 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.

Business defines stability by customer satisfaction or the number of repeat customers. While this sounds subjective, you can approximate this metric by the number of defects raised by customers or with customer feedback surveys.

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.

Code quality index

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. Agora é a hora de descobrir. Se você se intimidar agora, e depois seu negócio perder vapor, você poderá culpar apenas a si mesmo. Isso não se refere tanto a em que ponto você está nessa jornada. O fato de que você embarcou nessa jornada abrirá novos caminhos de oportunidades para a sua equipe melhorar continuamente! E ampliará os seus horizontes ajudando-o a experimentar sem medo. Se você considerar os seus funcionários que não vão se esgotar devido a lançamentos tarde da noite e pessoas que podem trabalhar em tornar o próprio mundo melhor, em vez de escorarem-se em um build que está constantemente falhando, o valor fica óbvio. Concorda?