Release Management: Automatizando implantações no Windows e Linux

O processo de desenvolvimento de software tem mudado cada vez mais no decorrer do tempo e, consequentemente, todos os processos envolvidos foram sofrendo grandes mudanças. Entretanto, as publicações continuaram estacionadas no tempo, sendo executadas, na maioria dos casos, de maneira totalmente manual, e isso já não é mais algo aceitável. Assim, sempre buscamos a maneira mais rápida e segura de realizar os procedimentos (até porque, na nossa área, tudo é sempre para ontem), e nem sempre a maneira mais rápida é a correta. Ocorre que, por muitas vezes ao disponibilizar uma versão para produção, fazemos isso de nossa própria máquina, podendo disponibilizar uma versão incorreta, uma versão em que os testes unitários estão com erros e/ou comentados, e com isso, podemos encontrar diversos problemas, apenas quando nossa aplicação for implantada em produção, ou pior, quando ocorrer um erro gravíssimo e/ou nossa empresa tenha algum tipo de dano devido a esse erro.

Quando temos alterações em banco de dados, também temos os scripts de alteração, que devem ser disponibilizados e executados no ambiente a ser implantado e, se tudo for muito manual, podemos esquecer de algum desses scripts.

Com todo esse procedimento sendo executado manualmente, se faz necessário criarmos um manual sobre como essa implantação deve ser realizada com todos os passos para que a aplicação funcione corretamente. Entretanto, muitas vezes, a pessoa que está realizando a implantação acredita já ter decorado todo o processo e não lê mais o manual, assim, pode-se esquecer e/ou errar algum processo, ou mesmo deixar de ver alguma alteração necessária.

O grande problema dessa execução manual é que caso ocorram falhas durante a implantação, pode ocorrer de o problema ser notado apenas por nossos usuários e isso pode nos causar grandes prejuízos, pois imaginemos que possuímos um e-commerce e quando nosso cliente estiver tentando realizar uma compra, o sistema o direcionar para a base de dados de desenvolvimento (onde os produtos não condizem com a realidade do negócio, por exemplo), ou ainda, o sistema fique com lentidão, pois a base de desenvolvimento está sendo alterada naquele momento. Nós perderemos a venda para aquele cliente e pode ser que este cliente vá para outro e-commerce, pois atualmente, nosso concorrente pode estar na outra aba do navegador.

Isso pode gerar desde um não retorno ao nosso e-commerce, como também gerar uma propaganda negativa sobre nossa empresa, então, temos o prejuízo não só do cliente que deixou de comprar e foi para nosso concorrente, como também a imagem negativa que isso irá produzir para nossa empresa, causando danos muitas das vezes irreparáveis. Esse é um dos motivos pelos quais sempre devemos buscar trabalhos automatizados, pois se programarmos um processo a ser executado pela máquina, sabemos que ele realmente será executado e, caso ocorra algum erro, podemos auditar o mesmo e verificar em que parte do processo ele ocorreu.

Existem ainda algumas empresas, que buscam aqueles selos ISO’s de Qualidade e um dos requisitos para que possam ter esse tipo de selo é a auditoria de execução dos processos e a possibilidade de reproduzir versões do processo de meses atrás. Se realizarmos tudo manualmente, nossa empresa terá um empecilho para conseguir esses selos.

O Mundo dos Sonhos

O mundo ideal para as implantações seria um processo 100% automatizado, como alguns exemplos que vamos ver.

Nossas aplicações, devem estar em um Controle de Versão, como o Team Foundation Server, além de passar por um processo de build automático pelo servidor para disponibilizar as versões, onde podemos configurar um processo que garantiria a execução dos testes, validação de arquitetura, entre outras coisas, antes de criar um pacote para implantação. Esse processo é mais confiável do que executar na máquina do desenvolvedor, pois o mesmo pode, por exemplo, desabilitar as validações na máquina para a aplicação rodar e enviar a implantação, podendo assim enviar uma versão com algum erro de regra de negócio e o mesmo será notado apenas quando o usuário estiver utilizando, ou pior, será notado apenas quando algum problema mais sério ocorrer em decorrência disso.

Quanto ao processo de banco de dados (BOX 1), caso você utilize o SQL Server em seus projetos, o ideal seria trabalhar para desenvolver seus bancos e versioná-los juntamente com sua aplicação, assim, caso seja necessário voltar uma versão da aplicação, a versão do banco também poderá ser voltada, mas a explicação para isso.