Em um recente artigo, Maxence Modelin discute de maneira bem detalhada, como a OCTO Technology, criou um fluxo de implantação (Deployment Pipeline), onde com apenas 3 cliques, o deploy de um serviço Windows é feito em 7000 máquinas, de um fornecedor de serviços de hosting, localizado na França.
A solução descrita, cujo foco envolve o deploy de um serviço Windows, desenvolvido em C#, que se comunica via FTPS com um servidor Java.
Uma caracteristica importante da solução, é o uso de uma plataforma de Integração Contínua baseado em ferramentas open-source, bem populares na comunidade Java, ao invés do uso do Team Foundation Server fornecido pela Microsoft.
Entre as tecnologias utilizadas para Integração Contínua, podemos destacar Jenkins como Servidor de Integração Contínua, Maven para gestão do projeto e Nexus para a gestão do repositório.
Para administração do farm de servidores, foi utilizado o software OCS Inventory. Um aplicativo web, responsável por centralizar todas as informações pelos Agentes OCS instalado em cada um servidores do farm. Que por sua vez, através das informações recebidas, efetua o deploy dos pacotes necessários nos servidores, sem a necessidade de uma ação do usuário.
Para monitoração do ambiente, foi utilizado Zabbix.
A cadeia de entrega contínua, se resume a apenas 3 cliques, onde o primeiro deles, começa com a operação de commit no SVN, que inicia o processo de integração contínua orquestrado pelo Jenkins. Que após efetuar o checkout do projeto, executa o script do Maven, que efetua o build, executa os testes, e por fim, armazena os artefatos gerados no Nexus.
O segundo clique, é para criação do pacote OCS, onde um profissional de operações (ops), executa um script shell, que extrai o artifato do Nexus e disponibiliza o pacote pronto para deploy no banco de dados do OCS.
Para o terceiro clique, no contexto da empresa, este último passo é considerado um passo funcional, e não existe razão de ser automático. Quem decide quais máquinas irão receber os pacotes, são os profissionais de operações, através do OCS. Os desenvolvedores tem o mesmo acesso, porém, para fazer o deploy em ambiente de testes.
Para assegurar que tudo ocorreu corretamente, operações utiliza duas ferramentas para feedback, que são o próprio OCS e Zabbix, e um usuário fake. Este usuário fake, é responsável por efetuar o download dos pacotes nas máquinas destino, e verificar se tudo ocorreu conforme o esperado.
A figura a seguir, descreve os softwares e ações realizadas durante o fluxo de implantação.
Um dos fatores imprescendíveis para o sucesso da Implantação Contínua, foi a abordagem DevOps dada ao projeto. Esta abordagem abriu a oportunidade para um compartilhamento das necessidades e visão entre os times de Desenvolvimento e Operações.
Pois com a responsabilidade do deployment a cargo do time de desenvolvimento, ao invés do time de operações, talvez eles nunca teriam a real noção do trabalho realizado.
E você, tem alguma estória de sucesso sobre implementações de Continuous Delivery e DevOps? Comente, discuta, colabore!
Nota: O artigo que o texto destaca é um pouco antigo, mas como esse post era para ser uma notícia na InfoQ Brasil no ano passado, mas como não foi aprovado então resolvi publicar aqui. Espero que curtam! Pois o case foi bem interessante, por se tratar de um case de Continuous Delivery para um aplicativo .NET, utilizando ferramentas open source Java.
Postagens
