Apresentação

 

1. Introdução

 

           A integração contínua é uma prática na engenharia de software bastante conhecida em metodologias ágeis e envolve o desenvolvimento de software e operações de TI atuando em conjunto (DevOps). Basicamente consiste em manter alterações do código em um repositório central, executar testes automaticamente, e lançar a versão do software automaticamente. 

A principal vantagem oferecida pela integração contínua é reduzir o fluxo complexo e repetitivo de: compilação (Build), disponibilização (Deploy) e testes unitários no processo de desenvolvimento de software, agilizando o lançamento de novas versões. Desta forma, a disponibilização de novas funcionalidades a medida que são desenvolvidas antecipa a detecção de erros, gerando desse modo um aumento na qualidade do processo de desenvolvimento de software.

A solução proposta permite que tanto a gerência de configurações quanto a gerência de projetos sejam beneficiados, de forma que as atividades unificadas garantam agilidade e coesão das entregas.

Para que o projeto faça parte do processo de Integração Contínua é necessário a instalação e configuração de ferramentas, além do entendimento do processo para que se obtenha melhor resultado.

 

    O vídeo abaixo pode auxiliar o entendimento do projeto:

                 www.youtube.com/watch?v=XsXZkprM0ew&t=4s

 

  

2. Restrições e Requisitos da Integração Contínua

 

 

Deve ser levado em consideração um conjunto de restrições e requisitos, que irão ser tratados com cautela para que todo o processo possa ser contemplado e trazer benefícios ao projeto.

 

  1. Atualmente, o projeto deve ser desenvolvido em Java, integrado ao Maven. As demais linguagens de programação precisam ser estudadas junto com a equipe da GAS - Gestão de Arquitetura de Sistemas, para que a demanda seja analisada com cautela.

  2. O servidor de homologação da aplicação deve ser, preferencialmente, Linux Ubuntu versão 14.04 ou 16.04;

  3. Os servidores de homologação da aplicação e banco de dados devem estar configurados antes mesmo da solicitação de implantação do processo de Integração Contínua;

  4. Para atingir o nível de maturidade desejado é preciso seguir as direções encontradas no seguinte link: Configurações da Integração Contínua.

 

Após o encerramento da solicitação no CsATI a unidade USG (Unidade de Sistemas de Gestão de Governo) irá avaliar as necessidades do projeto junto ao solicitante.

 

 

  

3. Glossário

 

A seguir segue uma breve descrição das ferramentas utilizadas no Processo de Integração Contínua:

 

Ferramenta

Descrição

Redmine

Ferramenta de gerenciamento de Projetos, com ela é possível visualizar as atividades através de gráficos de Gantt, acompanhar o progresso das atividades bem como seus deadlines.

Git

Sistema de Controle de Versão, usado para acompanhar mudanças em arquivos de computador e coordenar o trabalho entre uma equipe usando os mesmo arquivos. Git ATI: https://www.git.pe.gov.br/

Jenkins

Ferramenta de  integração contínua e automatização do processo. Atua como o orquestrador da integração continua, executando uma lista de passos pré definidos.

SonarQube

Ferramenta para verificação da qualidade do software. Verifica código duplicado, testes unitários, cobertura do código, complexidade do código, comentários, bugs, segurança e vulnerabilidades. https://www.SonarQube.org/

 

JUnit

Framework que facilita a criação de código para automação de testes unitários.

Selenium

Framework de Teste de Software automatizado para aplicações Web.  Provê testes de funcionalidades da aplicação web e testes de compatibilidades entre browser e plataformas diferentes.

JFrog

Armazena e gerencia o código binário, permite que os desenvolvedores tenham controle sobre a liberação de software. (https://www.jfrog.com/artifactory/)

 

Flyway

Ferramenta de migração de Banco de Dados (https://flywaydb.org/)

Docker

Ferramenta que pode empacotar uma aplicação e suas dependências em um container virtual que executa somente servidor Linux

 

 

 

4. Níveis de Maturidade do Processo de Integração Contínua da ATI

 

O Processo de Integração Contínua pode ser aplicado de forma simplificada ou em sua totalidade. O nível de maturidade em que cada projeto pode ser inserido depende dos artefatos trabalhados e das ferramentas que podem ser utilizadas.

Os níveis de maturidade da Integração Contínua podem ser melhor entendida através da figura abaixo:

 

Níveis de Maturidade da Integração Contínua

 

  • No Nível 0 os envolvidos desejam apenas armazenar o código fonte em um repositório (GIT) e o Gerente de Projeto deve utilizar o Redmine como ferramenta de controle de solicitações. Configurando essas duas ferramentas é possível rastrear as alterações realizadas no código-fonte de acordo com as tarefas do Redmine;

        Estas são as únicas atividades que são realizadas nos ambientes de homologação e produção,   os  demais níveis de maturidade trabalham apenas no ambiente de homologação; 

  • No Nível 1,  as atividades do nível 0 são garantidas e o Gerente de Projetos não necessita realizar as atividades de compilar código-fonte e realizar o deploy (Jenkins) manualmente. O Jenkins é configurado para fazer o download do código no GIT e verificar as dependências de bibliotecas, armazenadas no Jfrog, então o próprio Jenkins compila e gera o arquivo binário da versão e antes de publicar a nova versão de homologação, verifica se scripts de banco de dados a serem executados, se sim, solicita a execução ao  Flyway; 

  • O Nível 2 exige a utilização da ferramenta de verificação da qualidade do código fonte (SonarQube). Desta forma, é feita uma verificação estática do código-fonte, a qual não impede a publicação do código através do Jenkins. A ferramenta gera um relatório de qualidade do código;

  • No Nível 3, os scripts de teste estão disponibilizados no projeto (GIT). O JUnit poderá executar os testes unitários (implementados no JUnit) e também testes de integração implementados através da ferramenta Selenium. Neste nível de maturidade os scripts de teste são executados antes da publicação do código, pretendendo aumentar a qualidade do produto entregue e diminuir riscos de entrega de versões instáveis. Se houver erros no código que o tornem suscetível a falhas a versão não é publicada.

 

Para se definir o nível de maturidade de cada projeto uma equipe especializada da ATI irá avaliar cada caso separadamente.

O fluxo de atividades de cada nível de maturidade é melhor detalhado no Processo de Integração Contínua