A abordagem tradicional de gerenciamento de desenvolvimento de software adia para os momentos finais a verificação se uma funcionalidade está realmente funcionando. Uma funcionalidade realmente pronta deveria atender um conjunto significativo de critérios tais como:

• Operar no ambiente real (ou de homologação) do cliente;
• Operar em uma base de dados real (ou similar) a do cliente;
• Operar de forma integrada com os sistemas legados que ele deve conversar;
• Possui uma suíte de testes de automação para garantir bons testes de regressão nos aspectos funcionais e não-funcionais;
• Não introduzir débito técnico de manutenibilidade no código fonte.

Ao mesmo tempo, defeitos são inerentes no trabalho de se fazer software, que está sujeito a variabilidade do trabalho intelectual humano. E se o critério de pronto não é forte, o software irá acumular defeitos ao longo do seu ciclo de vida. E a consequência é que o % de progresso real é na prática muito menor que o % de progresso declarado em um cronograma desconectado da realidade. Quanto mais robusto o critério de pronto, mais sólido tende a se tornar o produto e maior será a medição real do progresso do produto. Quando times, por imaturidade, preguiça ou falta de ferramentas estabelecem um critério de pronto fraco ou não cumprem o acordo de pronto, haverá trabalho não feito no produto. O trabalho não feito é a diferença entre o trabalho necessário para ir para produção e o trabalho realizado no projeto. Em muitas empresas, o trabalho não feito é tão grande que ele gera um enorme débito técnico no sistema, que se materializa com muitos defeitos em homologação e produção.

A questão que surge é se teremos um sistema ativo que irá expor e resolver os defeitos imediatamente ou se deixaremos que os defeitos permaneçam no sistema e gerem problemas na homologação, ou pior, no ambiente de produção. Times DevOps acreditam na primeira alternativa e para isso estabelecem uma cultura que não apenas reduz a fricção de desenvolvimento, como também garantem a entrega de produtos robustos em produção.

Para isso é necessário que o time estabeleça um critério de pronto sólido para cada funcionalidade. Por exemplo, um critério de pronto sólido poderia estabelecer que uma funcionalidade está realmente pronta se, e somente se, ela:

• foi compilada em um ambiente limpo, diferente da máquina de desenvolvimento onde ela foi codificada;
• foi testada com uma suíte de testes de unidade;
• foi testada com robôs de automação de testes de telas;
• foi testada com robôs para automação de testes de segurança, usabilidade, performance, escalabilidade ou recuperabilidade;
• foi integrada com sucesso no tronco principal;
• gerou um build e um versionamento semântico;
• foi promovida de forma automatizada para um ambiente de homologação;
• foi aprovada para ser colocada em produção após os testes exploratórios e sistêmicos do time de QA.

A cultura DevOps busca apoiar o estabelecimento de critérios sólidos de pronto, através de práticas culturais, práticas técnicas e suporte de ferramentas de automação. O primeiro e mais importante pilar da cultura DevOps está nas pessoas. Se o time não compreender, estudar e se comprometer com a mudança cultural, não haverá sucesso ao introduzirmos uma sofisticada ferramenta de gestão de builds ou gestão de releases. E o critério de pronto é uma importante ferramenta DevOps para estabelecer valor de negócio. Busque isso antes de instalar a configurar a sua primeira ferramenta DevOps.