Esses dias participei de uma discussão se ALM estaria morrendo e DevOps seria o futuro… foram levantadas perguntas do tipo “DevOps é o novo ALM?” “O ALM vai morrer e só teremos DevOps?” “DevOps é a evolução do ALM?” “DevOps é o ALM 2.0” e etc.
Esse tipo de discussão é muito comum quando alguma novidade, que na verdade não é mais novidade, começa a ser divulgada pelo mesmo grupo de pessoas que divulgava outro conceito. Mas a bem da verdade esses conceitos não são substitutos um do outro, nem evolução.

ALM

Application Lifecycle Management, ou seu acrônimo ALM, pode ser dividido em três áreas distintas: governança, desenvolvimento e operações. É muito comum que ALM seja mais conhecido no time de desenvolvimento e, portanto, é tido muitas vezes como automação de build, ou simplesmente como gestão de código. Mas é muito mais abrangente que a parte técnica de build e seus periféricos. ALM já existe no início de um projeto, quando somente a área de negócios, ou a direção, ou ainda na criação da visão da presidência.

Na figura acima temos três linhas horizontais representando essas áreas, e três verticais representando os principais marcos: ideia, implantação e fim de vida. A ideia começa com um insight, ela é trabalhada e finalizada, e neste momento o desenvolvimento é iniciado; é planejado uma release e a primeira implantação é feita. O último evento é o fim de vida da aplicação, quando desligamos os servidores e o ciclo se encerra.

O primeiro trabalho é na área de Governança, a ideia é o primeiro artefato que iremos gerar, neste momento nem sabemos se precisaremos de um sistema ou não, mas para implantar uma ideia, por exemplo, que só exigisse uma mudança de processo, temos que catalogá-la, trabalhar nela, e aí o ALM já começa a atuar, na rastreabilidade dos artefatos. E será constante, até o fim do ciclo, já que sempre teremos requisitos de mudança, pedidos de manutenção, entre outros.

Quando essa ideia gera uma aplicação o Desenvolvimento começa a trabalhar logo depois da ideia aprimorada. E o ciclo do Desenvolvimento pode ter pausas. Ou seja, não necessariamente teremos desenvolvimento constante na aplicação.
Principalmente se o processo de desenvolvimento é suportado por um método ágil, o ideal é entregarmos algo menor para validação do usuário ou habilitar o negócio o mais rápido possível…, mas isso é assunto para outro post! E até o fim do ciclo existirão mudanças, extensões, manutenções, nessa aplicação.

Um pouco antes do fim da primeira release a ser entregue pelo desenvolvimento é necessário envolver Operações no processo, já que suportar essa aplicação em produção será responsabilidade deles, portanto eles devem trabalhar com Desenvolvimento antes de colocá-lo em produção para garantir que a aplicação será instalada e entrará em produção da melhor forma possível.

O último evento é fácil… é só desligar a máquina e tudo cessa!  🙂

Mas e DevOps? O que ele substitui? Nada… Quer dizer…

DevOps

DevOps é um movimento ou uma prática, que surgiu por volta de 2008, ou teve sua formalização com esse nome, já que é possível que empresas a praticassem antes. E o seu objetivo é diminuir o atrito entre as áreas de Desenvolvimento e Operações! Ou seja, da mesma maneira que SDLC continua existindo dentro de ALM, pois é de competência específica de Desenvolvimento; DevOps existe em paralelo com ALM, e não substituindo.
Existem vários cenários, eu posso ter DevOps sem ter um processo formal ou um ferramental completo de ALM, por exemplo, eu não tenho gestão de requisitos, ou rastreabilidade total entre as ferramentas de requisitos, mas posso ter DevOps que diminui o meu atrito em colocar novas releases em produção. Logicamente, que se o processo de ALM for bem maduro, se ele é trabalhado constantemente, inspeção e adaptação, lembra-se?; você irá ganhar um DevOps de brinde, que também terá que amadurecer, ser trabalhado, etc., mas será muito mais fácil propor a soma das forças entre Desenvolvimento e Operações.
Portanto DevOps passa a ser mais uma ferramenta para ALM melhorar o processo de produção de uma aplicação, na busca de mais agilidade, confiabilidade e segurança do processo.

Emmanuel Brandão