Application Lifecycle Management e Automação do desenvolvimento

Como pensar em Entrega Contínua e DevOps, sem pensar em automação do ALM (Application Lifecycle Management)? Como podemos pensar em "Push button deploy" sem termos certeza do que estamos liberando e quando?

Neste artigo, que segue nossa série sobre Continuous Delivery e DevOps, vamos falar um pouco sobre ALM e sua automação, revendo conceitos e apresentando os desafios e soluções existentes.

Application Lifecycle Management

É o processo de governança de aplicações, que envolve: gestão, desenvolvimento e entrega de novas versões de aplicativos, com qualidade.

É claro que a sigla "ALM" se tornou uma "buzzword" e faz parte do nome de vários produtos do Mercado, mas, antes de ser um produto, ALM é uma nova visão de gestão. A Wikipedia BR resumiu bem: "Gerenciamento de Ciclo de Vida de Aplicativos (ALM) é o casamento entre gerência de negócio com engenharia de software".

O ALM engloba as seguintes disciplinas:

• Gestão de requisitos;
• Arquitetura de software;
• Desenvolvimento de software;
• Teste de software;
• Manutenção de software;
• Gestão de mudanças;
• Gestão de projetos;
• Gestão de liberação (ou entrega).

Geralmente, o emprego de gestão ALM impica em automação do desenvolvimento, com o acompanhamento desde os requisitos até a entrega de software. As ferramentas de ALM permitem rastrear tudo, identificando quais requisitos provocaram quais mudanças em quais artefatos do sistema, e em quais versões liberadas foram implantados.

Mas qual é a vantagem disso tudo?

Era uma vez...

Para que você entenda os benefícios que o ALM pode trazer, vamos contar uma história, pois vai ilustrar bem os problemas que vivemos.

A XPTO Software e seu fabuloso fracasso

Era uma vez uma empresa moderna, que desenvolveu um software de gestão financeira muito bem sucedido, conquistando vários clientes. Como era uma "startup", tudo era "lean", e utilizavam métodos ágeis para desenvolver seu software. 

A XPTO não tinha divisórias e todos podiam ver o "Kanban" do Produto, se responsabilizando pelo bom andamento dos lindos papeizinhos "post-it".

Um certo dia...

O sucesso do "GereXPTO" (o software deles) era tão grande, que a empresa pode viver alguns anos sem investir muito em inovação. Com isto, o número de reclamações e de pedidos de melhorias foi aumentando, chegando ao ponto de forçar o Fulano de Tal, o CEO da XPTO, a adotar um plano de reformulação do "GereXPTO", que criaria uma nova versão, mais robusta e com tudo o que os Clientes queriam.

Durante a discussão que se seguiu, a equipe ágil tentou demover o Fulano de Tal de implementar tudo em um só "release", e o convenceram a fazer entregas menores, que dariam maior resultado. Então, resolveram separar as correções das evoluções e começaram a trabalhar.

Marco zero

Os desenvolvedores fizeram "Checkout" do código fonte e se separaram em duplas (XP), para começar a implementar as "Histórias de usuário". Conforme iam concluindo seus testes, faziam "Commit" de modo a não perder as alterações.

Primeira mancada...

Quando já havia um bom número de "Histórias" testadas e "comitadas", o Fulano de Tal reuniu a equipe e disse que precisava entregar alguma coisa... Pelo menos uma versão parcial. Por mais que o Beltrano (o desenvolvedor sênior) reclamasse, não foi possível convencer o Fulano. Então, resolveram "congelar" uma versão e fazer testes de aceitação.

Foi difícil, mas conseguiram recuperar o que estava no "trunk" do software de SCM, e voltaram algumas versões de alguns artefatos atrás, pois suas alterações não estavam concluídas. Fizeram "merge", com a versão de alguns artefatos que estavam na máquina do Cicrano, que conseguiu compilar uma versão funcional do "GereXPTO 2.0". 

Rodaram alguns testes que havia na máquina do Cicrano, e também alguns que estavam na máquina do Beltrano. Embora tenham tido alguns problemas, o Beltrano resolveu seguir porque os testes eram de novas versões, que não estariam incluídas neste pacote a ser liberado.

Chamaram alguns clientes e fizeram um teste de aceitação, conduzido pelo Beltrano. Tudo passou sem problemas e os clientes elogiaram a rapidez com que a XPTO implementou as alterações.

Então, o Fulano autorizou a entrega da nova versão, e, em um fim de semana, já estava tudo entregue. 

Enquanto isso, o desenvolvimento prosseguia e mais "commits" eram feitos... 

Alguns dias depois, vários clientes começaram a reclamar de problemas, dentre eles havia os que participaram dos testes de aceitação! Houve alguma revolta porque a XPTO não tinha como "voltar atrás" as instalações sem perda de dados, e seria necessário redigitar o movimento de três dias. 

Foi necessário recuperar a versão anterior do sistema, só que, como era distribuído "on-line", não havia nenhum "DVD" de instalação disponível, e o link de "download" só mostrava a última versão, exatamente a que deu problema.

Então, a equipe teve que parar o desenvolvimento para tentar recompor uma versão do "GereXPTO" anterior à 2.0. Tentaram recuperar as versões anteriores do "trunk", mas havia alguma confusão de datas e nem todos tinham certeza de quais seriam as versões e datas corretas de todos os artefatos. 

Recorreram às máquinas dos desenvolvedores e descobriram que o "Zé das Couves" estava de férias no início do XPTO 2.0, e, como não havia trabalhado nele, a versão que possuía em sua "workspace" ainda seria a antiga. Então pegaram a versão do "Zé das Couves" e rodaram o máximo de testes que conseguiram encontrar nas máquinas dos desenvolvedores. 

Pelo menos agora tinham uma versão antiga estável. Mas havia o problema dos movimentos dos vários dias, passados desde que os Clientes instalaram a versão 2.0 até a data em que iriam instalar a versão antiga recuperada. 

Então, o  Fulano arcou com as despesas de alguns dos Clientes (os mais importantes) e pagou pessoas para digitarem o movimento e ajudarem a recuperar o movimento e colocá-lo na "nova" versão do software. Quando aos outros clientes, enviou mensagens ensinando o que deveria ser feito para recuperar tudo. 

Segunda mancada...

Houve um grande dano à imagem da XPTO e do seu produto, mas, como o produto era realmente bom, a perda de clientes não foi muito grande. O Fulano, CEO da XPTO, resolveu que só uma versão realmente boa, com muitas funcionalidades novas, resolveria o problema de confiança. Reuniu-se com a equipe e falou sobre sua proposta. Todos reclamaram que era necessário parar e organizar as coisas ANTES de prosseguir com as alterações. 

O Fulano anunciou que a reputação da XPTO e o emprego de todos estava em jogo, então, arranjou mais sete desenvolvedores e os alocou à equipe. 

Com tanta gente nova chegando, o Beltrano, o Cicrano e o Zé das Couves, os membros mais antigos da Equipe, tiveram que se desdobrar em fazer suas manutenções e ajudar aos "novatos". Mais "commits" estavam sendo feitos... 

Depois de muito esforço, as coisas pareciam ir bem, e o Beltrano havia tomado algumas medidas para evitar problemas. Ele e o Cicrano centralizavam as versões diárias, fazendo "backup" diário do "trunk", e executavam os testes que estavam em suas máquinas, de modo que, caso fosse necessário, tinham versões "entregáveis" do "GereXPTO".

Foi então que um importante Cliente detetou um "bug" sério no Software. O Fulano percebeu que isso poderia minar mais ainda a confiança dos clientes e mandou corrigir imediatamente. Foi um pesadelo... O Beltrano e o Cicrano pegaram a última versão que tinham em suas máquinas, corrigiram o erro, testaram e tudo funcionou. Então, o Fulano mandou publicar aquela versão imediatamente. 

Foi ai que "deu ruim"...

A versão possuía código novo, com funcionalidades novas, incompatíveis com a versão antiga. Houve uma mistura de versões e o "GereXPTO" passou a apresentar vários probleminhas pontuais. 

Terceira mancada...

Com tantos problemas acontecendo, o Fulano não sabia mais o que fazer... O custo, o prazo e o risco de qualquer manutenção eram altos demais, e todos os "releases" passaram a dar problemas. 

Então, ele contratou uma nova ferramenta de gestão de ALM, coisa que ouviu falar em um congresso, e mandou usarem imediatamente. 

Com todos os problemas que vinha enfrentando, e, ainda por cima ter que entender e usar a ferramenta ALM,  o Beltrano se cansou... Saiu da empresa e levou o Cicrano com ele, deixando o Fulano com um monte de desenvolvedores novatos e uma ferramenta de ALM que precisava ser compreendida e implementada. 

Com todos os problemas, a XPTO conseguiu fazer um novo "release" do "GereXPTO", agora com versão mobile também (Android e iOS). O Fulano tinha total confiança que o software de gestão ALM iria resolver os problemas. Na verdade, o que aconteceu foi o contrário! Os problemas se multiplicaram exponencialmente, pois, além dos clientes tradicionais, havia os clientes mobile, com seus problemas desconhecidos para a XPTO.

Resultado: A XPTO perdeu tantos clientes, que foi vendida por uma mixaria e o Fulano teve que arrumar emprego, como subordinado do Beltrano...

Descubra os erros...

Parece com aqueles joguinhos de revistas infantis, não? Se a XPTO era uma "lean startup", e usava métodos ágeis, por que fracassou? Por que os problemas se multiplicaram? Por que a inovação não a salvou? E, finalmente, por que a Ferramenta de ALM não resolveu os problemas?

1) Inovação sem organização leva ao caos

Processo é condição necessária, mas não suficiente para garantir a Qualidade. É necessário investir em duas vertentes: qualidade do processo e qualidade do produto. Na história contada, a XPTO investia muito em processo e enfoque ("lean startup" e "métodos ágeis"), mas pouco em qualidade do seu produto. E qualidade, só se conquista com um mínimo de organização.

Para começar, o produto "GereXPTO" não tinha um "roadmap" definido e divulgado. Algo que balanceasse a necessidade de inovação e de correção da funcionalidade. Ele crescia por "espasmos", conforme podemos constatar nas atitudes do sr Fulano, CEO da XPTO:

• "o Fulano de Tal, o CEO da XPTO, a adotar um plano de reformulação do "GereXPTO", que criaria uma nova versão, mais robusta e com tudo o que os Clientes queriam.";
• "O Fulano, CEO da XPTO, resolveu que só uma versão realmente boa, com muitas funcionalidades novas, resolveria o problema de confiança. ";
• "ele contratou uma nova ferramenta de gestão de ALM, coisa que ouviu falar em um congresso, e mandou usarem imediatamente";
• "novo "release" do "GereXPTO", agora com versão mobile também (Android e iOS)";

Este tipo de atitude, que eu chamo de "Gestão por Espasmo", só leva ao caos. Para evitar isso, é necessário ter um planejamento em vários níveis: curto, médio e longo prazo, separando "Entrega" de "Release", e implementando alguns conceitos oriundos do ITIL, como a gestão de mudanças e de releases.

2) Falta de atenção ao pós-venda leva a perda de confiança

Outro erro da XPTO foi a falta de atenção ao seu "backlog", que é tão importante quanto ter um "roadmap" evolutivo: 

• "Com isto, o número de reclamações e de pedidos de melhorias foi aumentando, chegando ao ponto de forçar o Fulano de Tal, o CEO da XPTO, a adotar um plano de reformulação do "GereXPTO""

Não basta entregar no prazo... Todo software tem problemas e nem todos os Clientes são iguais. Logo, a geração de um "backlog" de incidentes e pedidos de melhoria é inevitável. É necessário ter uma política (mais do que um software) de CRM e balancear os itens de "backlog", planejando releases intermediários para evitar a perda de confiança dos Clientes.

3) Equipe ágil não é desculpa para equipe desorganizada

Eles até utilizam algumas ferramentas, como um software de SCM, porém, de maneira incorreta:

• "Os desenvolvedores fizeram "Checkout" do código fonte e se separaram em duplas (XP), para começar a implementar as "Histórias de usuário". Conforme iam concluindo seus testes, faziam "Commit" de modo a não perder as alterações.";
• "mas conseguiram recuperar o que estava no "trunk" do software de SCM, e voltaram algumas versões de alguns artefatos atrás, pois suas alterações não estavam concluídas. Fizeram "merge", com a versão de alguns artefatos que estavam na máquina do Cicrano";
• "Então, a equipe teve que parar o desenvolvimento para tentar recompor uma versão do "GereXPTO" anterior à 2.0. Tentaram recuperar as versões anteriores do "trunk", mas havia alguma confusão de datas e nem todos tinham certeza de quais seriam as versões e datas corretas de todos os artefatos. ";
• "O Beltrano e o Cicrano pegaram a última versão que tinham em suas máquinas, corrigiram o erro, testaram e tudo funcionou.";

SCM é uma mentalidade, uma disciplina de gestão, e não apenas "usar CVS" (ou "Git", ou "SVN")! É necessário criar uma política de separação de alterações, associada à Gestão de mudanças. Pode-se criar "branches" para alterações simultâneas e "TAGs" para marcar versões implantadas. 

É necessário evitar "código da máquina do desenvolvedor", pois todo código fonte deve vir de um e apenas um repositório, onde as versões possam ser relacionadas às Mudanças e aos testes. 

Um processo de integração contínua, com automação de "build" diretamente do repositório SCM, e execução de testes automatizados, poderia ajudar a organizar o ciclo de desenvolvimento da XPTO.

4) Falta de segregação e automação de testes

A única prova de que um software funciona é a disponibilidade de scripts de teste eficazes e idempotentes. Podemos ver que a XPTO não tinha essa cultura:

• "Rodaram alguns testes que havia na máquina do Cicrano, e também alguns que estavam na máquina do Beltrano.";
• "e executavam os testes que estavam em suas máquinas";
• "Chamaram alguns clientes e fizeram um teste de aceitação, conduzido pelo Beltrano. ";

Testes são parte do produto e com ele devem ser mantidos. Além do código fonte, devem ser mantidos no repositório SCM:

• Documentação operacional;
• Scripts de instalação;
• Scripts de teste.

E todos os testes devem ser automatizados, rodando sob um ambiente de Integração Contínua. Além disto, testes de aceitação não podem ser "conduzidos" pelos desenvolvedores. É necessário que existam testes: Unitários, de Integração e Funcionais separados, e, de preferência, automatizados. 

5) Tudo deve ter um "plano B"

O "release" de uma nova versão é uma atividade que envolve riscos, logo, temos que identificá-los e tratá-los adequadamente. Faltou à XPTO exatamente isto: 

• "a XPTO não tinha como "voltar atrás" as instalações sem perda de dados, e seria necessário redigitar o movimento de três dias. ";

Gestão de riscos é sempre uma atividade relegada a segundo plano, tanto por gestores como por desenvolvedores e Clientes.

Como o ALM poderia resolver estes problemas?

Para começar, volto a afirmar que ALM não é uma ferramenta, que você compra, instala e, por mágica, resolve todos os seus problemas. Você é que tem que resolver seus problemas! E deve automatizar seu ciclo de desenvolvimento também.

ALM é uma postura gerencial, antes de ser uma ferramenta. Para alcançar o ALM, é necessário adotar várias disciplinas, que organizam todo o seu ciclo de desenvolvimento. E isso vai requerer uma grande mudança cultural em sua equipe.

Primeiro passo: Organizar a bagunça gerencial

Certa vez, eu trabalhei em uma multinacional de desenvolvimento de software, e fornecíamos um sofftware de automação de venda de passagens (quiosque) para uma empresa aérea. A gerente do projeto era uma pessoa muito organizada, e todos os "releases", sejam corretivos ou evolutivos, eram programados. Nada era feito se não estivesse dentro do "roadmap".

Como o sistema ficava "de frente" para o Cliente, qualquer problema era fatal para a imagem de ambas as empresas, então a gestão de "roadmap" era importantíssima.

Para isto, você deve ter um "roadmap" de evolução e de correção do software, com datas programadas de entrega e "release". É necessário gerir essas duas coisas separadamente:

• Entrega: é o ato no qual o desenvolvedor prova que sua unidade de trabalho (uma alteração em um artefato) está funcionando e está integrado ao resto do software;
• Release: é o ato de liberar uma versão, que pode conter várias "Entregas", para instalação no ambiente do Cliente;

Deve haver gestão de "Release" em separado das Entregas e a decisão de incluir entregas nos "releases" deve ser balanceada entre a prioridade no "backlog", o risco e a disponibilidade dos recursos. 

E, quanto aos riscos, devem ser identificados e tratados, com atitudes e reservas de contingência. 

Não se pode gerenciar um software "por Espasmos", caso contrário, o resultado será muito parecido com o que aconteceu com a XPTO.

Segundo passo: Controle seus ativos de software

Código fonte é um ativo da empresa! E pode valer muito dinheiro. Você sabe quanto vale uma Classe Java de um software que você fez? Talvez saiba a importância, mas e quanto ao script de teste? E o de instalação? Geralmente, são considerados "coisas de nerds" e de pouco valor, certo? ERRADO!

Todos os artefatos que compõem seu software são importantes e devem ser guardados, entre eles:

• Código fonte, rotulado por "release", com separação em "branches" diferentes a cada mudança em andamento;
• Scripts de instalação, também rotulados e separados por mudanças;
• Scripts de teste, separados por nível (Unidade, Integração, Funcional ou Carga), e, da mesma maneira, rotulados e separados.

Tem que ser possível recuperar TODOS os artefatos que formam uma versão liberada (um "release" ), de modo a recompô-la sem maiores problemas. 

Por exemplo, imaginemos que os clientes reportaram um problema na versão 2.3.1 do seu software. Como você vai constatar a existência do problema? Como vai saber se ele foi ou não resolvido? É necessário baixar o código fonte (e os outros artefatos) daquela versão, executar os testes e forçar o problema. Então, você pode tentar reproduzir em todas as versões seguintes, de modo a avaliar o impacto para os outros usuários.

Existe um tipo de teste que é chamado de "teste de regressão", que verifica a conformidade retroativa do software aos requisitos. Só é possível executar estes testes se você os mantém em seu repositório SCM, rotulados por "release".

E cada nova mudança, seja manutenção corretiva ou evolutiva, tem que ter o seu próprio "branch" de código fonte. O "trunk", ou a versão corrente, deve espelhar o último "release" e não as mudanças intermediárias. O "merge" de um "branch" no "trunk" só pode ocorrer quando este for liberado, ou seja, quando a versão candidata a "release" for considerada aprovada. 

E é muito importante analisar a qualidade do software que você está criando. Não basta analisar a velocidade de implementação, mas vários outros critérios.

Terceiro passo: Automatizar o ciclo de desenvolvimento

Esse negócio de pegar software da máquina do desenvolvedor é uma indecência! Máquina de desenvolvedor é igual à "Casa da luz vermelha", ou seja: É UMA ZONA! Temos que organizar tudo e termos certeza que vamos compilar nossas versões de software em um ambiente controlado (sala limpa). Isto só é possível com um processo de Integração Contínua implementado. 

Em um processo de IC, temos um ambiente "limpo", composto por um software de "gestão de build", como o Apache Continuum, ou o Jenkis, que repetem continuamente: 

1. Recuperar o código fonte do tag desejado;
2. Compilar os artefatos;
3. Executar testes;
4. Publicar resultados.

Normalmente, usamos um software de "build" como o Apache Maven para isto, que permite criar scripts de compilação e execução de testes JUnit automatizados. 

O ambiente de IC vai executando a Integração de nossa versão de software durante o ciclo de desenvolvimento, reportando os resultados (erros de compilação, resultados de testes e métricas de qualidade de software) de modo que todos possam avaliar os problemas e agir proativamente.

Ainda é possível ter um repositório de artefatos compilados, como o Apache Archiva ou o Nexus, permitindo que os Clientes tenham acesso às várias versões, incluindo "snapshots" ("nightly builds") do seu software. 

Basta isso? 

Depois que tudo estiver organizado (os três passos) você pode pensar em adquirir uma suíte de ALM, pois será mais fácil implantá-la com a bagunça sob controle. Mas, você deve sempre pensar que ALM é uma postura gerencial, e não um software que você compra! Os três passos que descrevi ajudam a você implementar ALM. 

Uma vez com seu ALM e automação do desenvolvimento implementados, você pode começar a pensar nos próximos passos, que são a Entrega Contínua e a adoção de método DevOps. 

Onde posso saber mais?

Bão, tenho que vender meu "peixe", caso queria continuar a postar artigos gratuitamente para vocês, então, lá vai: 

• Software Configuration Management, Integração Contínua e boas práticas: "O Guia de Campo do Bom Programador", editora Brasport, disponível também em e-books e na Amazon Kindle Store e no iTunes Store;
• Métricas, qualidade de software, refatorações etc: "Qualidade de Software na Prática", editora Ciência Moderna;