5.1 Introdução

Nós capítulos anteriores o foco foi na demonstração da implantação do ambiente de produção considerando a tecnologia Docker. Desse modo, demonstramos como usar contêineres para colocar no ar uma aplicação funcional. Basicamente fizemos uso de três servidores para isso: um Servidor de Banco de Dados (MySQL), um Servidor de Aplicação (Tomcat), e um Servidor de Monitoramento (Nagios).

Observa-se que, para isso, não falamos sobre o processo de construção do arquivo lojavirtualdevops.war que foi utilizado para se efetuar o deploy no Servidor de Aplicação.

Neste capítulo e no próximo abordaremos especificamente a questão da construção do arquivo lojavirtualdevops.war , em outras palavras, retomando a figura abaixo, apresentada anteriormente no Capítulo 1.2, atacaremos as etapas 1, 3 e 4. O foco será no uso de Docker e outras tecnologias nas etapas de Desenvolvimento e Integração Contínua (Continuous Integration) (Capítulo 5) e Entrega Contínua (Continuous Deployment) (Capítulo 6).

Fluxo de trabalho genérico e para o ciclo de vida do aplicativo em contêineres do Docker (extraída de Torre (2020))

Conforme ressalta Sato (2018), a essência do DevOps é exatamente a cooperação entre as equipes de desenvolvimento e operações em prol de construir e disponibilizar uma aplicação de qualidade para os usuários finais utilizando o máximo possível de automatização nesse processo. Para isso, escrever código para a aplicação e para a infraestrutura é fundamental.

Considerando essa forma moderna de desenvolvimento de software o que se pretende é que, a cada alteração realizada no código da aplicação que seja confirmada (commit), siga-se um fluxo (pipeline) que permita a compilação, teste e geração do pacote da aplicação para entrega ao ambiente de produção se for o caso.

Isso é decorrente da introdução dos métodos ágeis propostos nos anos 90 e que hoje são utilizados total ou parcialmente por grande parte das empresas desenvolvedoras de software (Beck e Andres (2005)). Dentre as práticas ágeis preconizadas pela eXtreme Programing (XP), por exemplo, estão: refatoração, Test Driven Development (TDD), propriedade coletiva de código, projeto incremental, programação em pares, padrões de código e integração contínua. Obviamente, nem todas são universalmente aceitas mas algumas, tais como a responsabilidade pelo código e a integração contínua passaram a ser um padrão de fato no desenvolvimento de software atual.

A responsabilidade pelo código acabou fazendo com que o desenvolvedor, ao se responsabilizar pelo código que escreve, passasse a adotar teste unitário como prática comum. Desse modo, ele não entrega mais apenas o código operacional da aplicação mas também um conjunto de testes unitários que demonstram que o que ele desenvolveu funciona corretamente.

Já a integração contínua faz com que, a cada mudança confirmada no código, todo ou parte do sistema seja reconstruída e testada rapidamente e a equipe de desenvolvimento passa a ter um rápido retorno se algo deu errado com as últimas mudanças introduzidas. Para esse ponto, recomendo a leitura do artigo de Feitelson et al. (2013) intitulado "Development and Deployment at Facebook". É bem interessante. Apesar de apresentar o relato de desenvolvimento em uma empresa particular, as práticas adotadas e descritas são empregadas hoje por uma vasta gama de empresas.

Espero que estejam animados para essas últimas etapas de aprendizado sobre Intergração e Entrega Continuas.