Parece que a prática da Entrega Contínua (CD) finalmente entrou no mainstream do desenvolvimento de software. Cada vez mais, empresas como Etsy, Facebook e GitHub estão fazendo vários lançamentos por dia, usando um pipeline totalmente automatizado.

A Entrega Contínua (CD) trabalha com a premissa simples: cada mudança de código é implementada diretamente na produção. Esse requisito aparentemente inocente possui um grande impacto sobre todas as disciplinas envolvidas na construção de produtos de software.

A maioria das pessoas (ou pelo menos a maioria dos desenvolvedores) tende a se concentrar no impacto que a EC tem nas atividades de engenharia. E não há dúvida de que ele é significativo, porque a CD requer um alto grau de confiança no pipeline. O ato de automaticamente construir, testar e implementar o software tem que ser confiável o suficiente para que uma não-conformidade em qualquer uma dessas etapas seja essencialmente um evento Seis Sigma.

E, no entanto, embora o impacto sobre as práticas de engenharia seja significativo, eu diria que a natureza dele é evolutiva para equipes Agile que já praticam a Integração Contínua (Claro, para as equipes que ainda não estão fazendo IC, CD seria revolucionário. Dito isso disse, mover-se diretamente para a CD sem antes fazer CI é, provavelmente, um caminho longo demais).

Por outro lado, o impacto da CD das atividades que não são de engenharia, como garantia de qualidade, desenvolvimento de produtos e gerenciamento de liberação pode ser revolucionário. E é esse impacto que eu quero explorar.

Impacto na Quality Assurance (QA)

O objetivo da Quality Assurance (QA) tradicional é evitar que erros passem para a produção. Obviamente, garantir a qualidade tem trabalho e custos de oportunidade não-triviais. Alguém tem que testar o aplicativo para garantir que ele funcione como o esperado. E, enquanto esse teste está em andamento, os usuários não estão recebendo os benefícios de novas capacidades.

Então, por que gastar tanto tempo e dinheiro em QA? Será que é porque acreditamos que seja possível evitar todos os bugs? Talvez, embora eu não conheça alguém que espera seriamente que um sistema de software de qualquer complexidade esteja livre de bugs.

A motivação mais provável é a suposição de que os bugs são muito mais dispendiosos para consertar quando estão em produção. E, embora seja discutível se essa suposição já tenha sido válida, corrigir bugs de produção certamente tem resultado elevado. Esse resultado vem na forma de qualquer cerimônia que a sua loja requer antes de implementar uma mudança para a produção.

Então, QA passa muito tempo tentando encontrar e corrigir erros antes que o software chegue aos clientes. Temos todos os tipos de atividades divertidas, como congelamentos de código, bugs bashes e testes de regressão manual projetados para evitar que erros aconteçam. E, novamente, essas atividades podem ser demoradas e dispendiosas.

Mas e se o custo de correção de bugs de produção for o mesmo ou menor do que o custo de evitá-los? O que isso faria para a prática de Quality Assurance? Ainda seria relevante? Como isso teria que mudar?

Bem, a CD possui um impacto sobre a economia de bugs. Ele não só torna os piores defeitos potencialmente menos prováveis, mas também faz com que seja possível consertá-los rapidamente. Portanto, a prática de QA deve evoluir para tirar o máximo de proveito que a CD tem a oferecer.

Como Noah Sussman tão eloquentemente apontou em sua palestra sobre a melhoria contínua, o foco tem de mudar de prevenção para descoberta rápida e resolução. Em outras palavras, a coisa mais rentável de fazer em CD é passar o tempo de monitoramento da atividade de produção real para encontrar e corrigir rapidamente os erros.

Outra perspectiva interessante é a de expandir a definição de bugs. Em vez de considerar apenas defeitos reais no código, pense na experiência geral do usuário. O caminho específico através do aplicativo está demorando muito? Que tal um novo botão não sendo usado, apesar de expectativas contrárias?

Um último ponto em relação a QA. De maneira nenhuma estou sugerindo que testes de aplicativos proativos sejam irrelevantes. Pelo contrário, para a Entrega Contínua, é necessário ter um bom conjunto de testes automatizados.

Impacto no Desenvolvimento de Produto

E o desenvolvimento de produtos? A Entrega Contínua causa impacto em pelo menos duas maneiras: redução de loops de feedback e dissociar implementações de produção de releases.

Redução de loops de feedback

Nos processos de agile tradicional, o tempo entre a ideia de uma feature e o seu uso na vida real é medido em semanas, possivelmente meses. Isso é um tempo muito longo para se esperar feedback. Além disso, quão rápido um gerente de produto razoavelmente espera iterar o feedback? Mais uma vez, pense em semanas, não dias.

Então, nós temos todos os tipos de práticas para reduzir a duração desse loop de feedback: sessões de teste de usuário, betas, e assim por diante. Agora, essas atividades podem certamente ser eficazes, mas elas não são, muitas vezes, boas substitutas para o uso no mundo real.

Com a CD, é concebível obter um feedback muito mais rápido, especialmente com técnicas como testes A/B. Então, o que isso significa para o Desenvolvimento de Produtos? Em uma palavra, instrumentação: fazer com que as features sejam um caminho para entender os padrões de uso, utilizar os dados recolhidos para obter insights sobre as necessidades do usuário e fazer modificações com base nesses insights.

Desacoplar os releases da entrega

A Entrega Contínua desacopla os lançamentos de features da entrega de código. Mesmo que cada mudança faça o seu caminho para a produção de imediato, pode não ser visível para o usuário final. O ato de “lançar um recurso” se torna uma questão de apertar um botão (conhecido como flags de configuração, “feature flips”, feature toggles etc.).

Cada história é uma parte de uma característica ou pode ser implementada de forma independente (como é, com frequência, o caso de correções de defeitos). Essa exigência obriga certo nível de disciplina porque as histórias devem ser planejadas com antecedência. Ao mesmo tempo, os gestores de produtos conseguem um novo nível de flexibilidade porque a definição de um “recurso terminada” é completamente fluida e pode ser redefinida conforme o necessário.

Impacto na gestão de releases

Finalmente, considere a gestão de releases. Nas lojas que lançam com pouca frequência, os lançamentos são grandes eventos. E, como em qualquer grande evento, alguém tem a responsabilidade da sua gestão.

Os branches de código devem estar estabilizados, ambientes criados, testes de regressão executados, bugs triados e resolvidos (ou diferidos) e códigos transferidos para a produção. Com tantas peças em movimento e tantos jogadores, alguém precisa assumir o papel de um controlador de tráfego aéreo.

Mas e se nenhum desses rituais e processos for necessário porque tudo é automatizado? Qual o papel do gerenciamento de versão, se é que há algum? Qual o valor que foi adicionado? Uma vez que a liberação de máquinas torna-se de autogestão, o papel de um gerenciador de releases ainda é necessário?

Pensamento final

A adoção da Entrega Contínua irá agir como uma função importante forçando toda a organização de desenvolvimento de produtos. Cada papel é afetado porque muitas dos suposições que orientam as práticas tradicionais podem não ser mais válidas.

***

Texto original disponível em http://tatiyants.com/impact-of-continuous-delivery-beyond-engineering/