Pronto para produção não é pronto para o usuário

A entrega contínua é o penúltimo objetivo das organizações que adotam o DevOps. Não é o objetivo final, porque isso seria uma implantação contínua.

Muito se fala nos becos do DevOps em relação à capacidade de entregar software pronto para produção inúmeras vezes ao dia.

Muito legal.

A razão pela qual não fico muito animado com isso é que, na maioria das organizações empresariais — mesmo aquelas que adotam o DevOps — a entrega é apenas o primeiro passo na fase de "chegar ao mercado" do ciclo de vida de um aplicativo. Poucos aplicativos estão “prontos” para os usuários após a notificação final de compilação e lançamento. Ele ainda precisa ser implantado na produção, onde uma variedade de procedimentos e políticas garantirão sua entrega adequada aos usuários.

Veja, a implantação contínua é (deveria ser, pode ser, será) o objetivo final das organizações que adotam o DevOps. Mesmo que não seja, a questão maior é que simplesmente entregar para produção não torna um aplicativo “entregue” aos seus constituintes. Isso requer implantação, em produção, juntamente com quaisquer serviços necessários para dimensionar, proteger e acelerar o aplicativo para garantir que ele apresente uma experiência de aplicativo ideal para usuários, tanto corporativos quanto consumidores.

Isso pode significar balanceamento de carga para garantir escala e disponibilidade. Isso quase certamente significa segurança – pelo menos no firewall, espero que na segurança do aplicativo e possivelmente mais. Também pode implicar acesso e identidade. Talvez não para aplicativos voltados ao consumidor, mas os voltados para empresas podem precisar ser incluídos em SSO ou políticas federadas para garantir acesso tranquilo e sem complicações. Velocidade também pode ser necessária em termos de desempenho.

Todas essas coisas precisam acontecer antes que um aplicativo esteja “pronto” para os usuários. E a “produção” sabe disso. Dos 32% dos entrevistados em nosso Estado de Entrega de Aplicativos de 2017 que se enquadraram na categoria “temos de 1 a 10 desses serviços implantados”, a maioria se enquadra na categoria “temos mais de 5”, com 63% indicando de 6 a 10 implantados hoje.

Independentemente dos problemas de “implantação contínua”, esses serviços são essenciais para garantir que os aplicativos estejam “prontos para os usuários” e não apenas “prontos para produção”.

Entregar inúmeras vezes à produção é ótimo, mas entregar com mais frequência ao mercado é o verdadeiro objetivo. Mesmo que o DevOps entre em produção (entre! a água está ótima, sério!) para lidar com o aplicativo e sua infraestrutura imediata, ainda haverá serviços upstream que devem ser provisionados, configurados e testados antes que o aplicativo possa realmente ser considerado "entregue".

Lançar aplicativos para produção com mais frequência não afeta o cronograma de implantação. Há uma razão pela qual os projetos de código aberto têm uma ramificação “estável” e uma opção de “compilação noturna”. Claro, posso obter o mais recente e melhor, mas como usuário, prefiro a opção "estável", porque ter aplicativos quebrando ou travando aleatoriamente não contribui de forma alguma para uma experiência positiva com o aplicativo.

O cronograma de implantação deve ser conduzido pelo negócio e implementado pela TI, e isso significa envolver a TI (todas as quatro operações) para começar a automatizar o máximo possível do processo. Porque um aplicativo não está pronto para o usuário, é protegido e acelerado pelos serviços que o cercam na produção.