Por Fábio Santos

O emergente conceito de Continuous Delivery no desenvolvimento de software tem movimentado a comunidade de desenvolvimento com muitos questionamentos e controversas. Feature Branches, uma das técnicas que suporta a entrega contínua, divide a comunidade e desafia até as equipes mais experientes em desenvolvimento ágil. Mas o assunto suscita uma questão muito importante:

Será que existe necessidade para continuous delivery fora do contexto de produtos para a nuvem e startups?

Para responder esta pergunta é preciso compreender o que está por trás do continuous delivery e por que esta prática é tão controversa. Tecnicamente, continuous delivery refere-se, obviamente, à entrega contínua, ou seja, unificar as linhas de desenvolvimento de forma a permitir que todas as funcionalidades (inclusive as que ainda não estão concluídas) possam ser seguramente colocadas em produção a qualquer momento. Isso implica a entrega de todo o produto continuamente e coloca sob a responsabilidade da equipe (e não das ferramentas usadas por ela) toda a gestão de configuração.

Isto faz muito sentido quando se fala de uma startup que precisa ser muito ágil no desenvolvimento de novas funcionalidades assim como na correção de defeitos. Também faz sentido no desenvolvimento de produtos ou serviços baseados na nuvem, permitindo que as funcionalidades sejam disponibilizadas de forma particionada entre os usuários, por exemplo.

Mas e nas aplicações organizacionais? Aplicações de backoffice de um banco, por exemplo? Faz algum sentido este tipo de abordagem onde o processo de homologação do sistema dependa de questões legais, por exemplo?

Aparentemente a resposta a estas perguntas é um sonoro não! Mas existe ainda um outro ponto de vista a ser analisado:

O que é preciso para uma equipe de desenvolvimento alcançar o continuous delivery?

Ao analisar esta questão sob este ponto de vista, a primeira característica que me vem à mente é a confiança. Aliás, confiança ao extremo. Como a equipe adquire confiança para gerar uma versão estável a cada commit?

Ao olharmos para a história da engenharia de software podemos observar muitos processos que surgiram (gestão de configuração, homologação, testes automatizados, integração, etc) para gerar confiança, mas todas estas ferramentas não conseguem proporcionar a segurança  necessária sem a direta intervenção humana. O continuous delivery implica a ubíquação de algumas destas técnicas de forma a torná-las quase que imperceptíveis. Ou seja, se por um lado a confiança sempre foi necessária e nunca foi alcançada com as ferramentas que temos em mãos, por outro lado, estas ferramentas usadas à exaustão podem enfim garantir a confiança?

Mais uma vez a resposta é não! Isso por que a única forma de garantir que a entrega realizada, mesmo que feita continuamente, é confiável é a sensação que as pessoas têm sobre o produto entregue. Confiança é uma emoção humana e uma ferramenta não pode nos trazer “confiança de forma confiável”. Por exemplo, uma suíte de testes extensa não pode garantir isso, pois precisamos confiar nas pessoas que escreveram esta suíte de testes para confiar na própria suíte. A confiança nas pessoas é que garante a confiança nas ferramentas por elas usadas.

Ou seja, a confiança é da e na equipe, não nas ferramentas. E só existe confiança se a equipe for muito boa tecnicamente e estiver totalmente comprometida. É impossível ou irresponsável ter confiança em uma equipe de baixa qualidade. É impossível ou irresponsável ter confiança em uma equipe que não está comprometida.

Com o continuous delivery, a execução exaustiva do processo de entrega faz com que a equipe tenha que evoluir continuamente para garantir a confiança na qualidade do produto entregue. Afinal, não existe continuous delivery se você não puder implantar uma versão em produção “tomando uma caipirinha na praia” (Jez Humble). E esta confiança deve ser refletida em toda a equipe e não apenas em um grupo de especialistas ou integradores, pois cada commit é um candidato à produção. Cada alteração deve ser auto-suficiente e não pode haver dependências de tarefas e funções dentro da equipe.  Desta forma, a conclusão a que podemos chegar é que o continuous delivery implica a busca pela confiança contínua e uniforme em toda a equipe.

E esta busca implica a necessidade de aumento da qualidade da equipe e do seu comprometimento. Ou seja, o processo de chegar ao continuous delivery é mais importante do que entregar continuamente software em produção.

Enfim, se confiança é palavra-chave no seu negócio, continuous delivery é o processo que pode te levar até ela.