• Índice
• 3.1 - Pipeline de Entrega
  • 3.1.1. Fases do Pipeline
  • Fase I: Checkout do repositório
    • Fase II: Compilação e Build
      • II-a) Empacotamento e Publicação
  • Fase III: Análise de qualidade
    • • III-a) Teste de unidade/unitário
      • III-b) Teste de Integração
      • III-c) Análise estática de código
  • Fase IV: Build da Infraestrutura (Imagens Docker)
    • Fase V: Ambiente do Usuário
      • V-a) Deploy no Playground do Usuário
      • V-b) Teste de Fumaça
  • 3.1.2. Ferramentas Necessárias/Sugeridas

3.1 - Pipeline de Entrega¶

A Integração Contínua deste Ministério tem por padrão as seguintes fases:

• I. Checkout do código-fonte
• II. Compilação e Build
• III. Análise de qualidade
• VI. Build da Infraestrutura (Imagens Docker)
• V. Ambiente do Usuário

3.1.1. Fases do Pipeline¶

Fase I: Checkout do repositório¶

Neste passo é feito o checkout do código-fonte da aplicação a partir da escolha de uma branch ou tag gerada contendo uma versão da aplicação.

• Para cada entrega de Sprint deve-se adicionar uma tag no repositório Git conforme orientações na página 2.5.1.2 - Commits, pushes, tags e branches temporárias .

Fase II: Compilação e Build¶

Essa fase é dividida em dois passos: Empacotamento e Geração da Imagem Docker.

II-a) Empacotamento e Publicação¶

Neste passo executamos a parte de 'build' da aplicação no qual são chamados os comandos necessários para a geração do pacote binário (executável da aplicação), como por exemplo, um pacote jar, ou war quando falamos de aplicações Java.

Espera-se também que o processo automatizado seja capaz de publicar os itens gerados pelo build no repositório padrão de Gerenciamento de Componente de Software deste Ministério, que é o Nexus para os casos em que o artefato gerado, seja reutilizável por outros componentes e/ou aplicações.

Saiba mais em 2.4.3 - Scripts de Build, Exemplo:

• Maven (Aplicações Java)
  

  mvn clean package
  

• Npm (Aplicações NodeJs, Angular, etc...)
  

  npm install
  
  bower install
  

Fase III: Análise de qualidade¶

Essa fase é dividida em três passos: Teste de unidade; Análise estática de código e Teste de Integração.

III-a) Teste de unidade/unitário¶

Para este passo, espera-se que o processo de entrega automatizada seja capaz de executar os testes unitários sem acionar liquibase, teste de integração ou testes de interface. Os testes de unidade não devem acessar recursos fora da sua fronteira.
Saiba mais em 2.4.2 - Testes.

III-b) Teste de Integração¶

Para este passo, espera-se que o processo de entrega automatizada seja capaz de executar os testes de integração sem acionar os testes de interface. Os testes de integração devem acessar recursos fora da sua fronteira, e utilizar alguma ferramenta que gere o relatório de cobertura dos testes para que possa ser publicado no Sonarqube ou que gere relatório html navegável. Saiba mais em 2.4.2 - Testes.

III-c) Análise estática de código¶

Para este passo, espera-se que o processo de entrega automatizada faça a chamada ao SonarQube para realizar a análise da qualidade do código, gerando uma página de projeto contendo as métricas de qualidade assim como o resultado da cobertura de testes unitários e de integração executados nos passos anteriores.

É recomendado que neste passo, o processo de entrega automatizado seja interrompido caso a aplicação não esteja atendendo os critérios esperados de qualidade.

A depender da arquitetura da aplicação, passos como o III-b) Teste de Integração podem ter seu tempo de execução muito longos, neste caso é possível paralelizar sua execução, separando este passo em outra tarefa (Job) para que a entrega não fique demasiadamente onerosa, sendo o resultado analisado em outro momento.

Fase IV: Build da Infraestrutura (Imagens Docker)¶

Para este passo, é esperado que o repositório git possua as receitas de todos os containers necessários (frontend, backend, banco, etc...) organizados em pastas dentro da pasta docker que fica na raiz do repositório git, exemplo:

 codigo-fonte/

 docker/

    frontend/

       Dockerfile

    backend/

       Dockerfile

    banco/

       Dockerfile

    .

    docker-compose.yml //Docker-compose de referência que demonstra como os vários containers conversam entre si

Nesta fase são executados os comandos de docker build para a criação das imagens necessárias para o funcionamento da aplicação, esta imagens devem ser enviadas obrigatoriamente para o Registry privado do MP.

É recomendada a criação de vários Job's para a aplicação, quando a mesma possuir diversos containers que não precisam ser atualizados sempre no mesmo momento, Exemplo de hierarquia de Job's:

   sistema-abc

      sistema-abc-frontend

      sistema-abc-backend

      sistema-abc-banco

Saiba mais em 3.3 - Conteinerização das aplicações

Fase V: Ambiente do Usuário¶

Essa fase é dividida em dois passos: Deploy no Playground do Usuário e Teste de Fumaça.

V-a) Deploy no Playground do Usuário¶

Nesta fase o processo de entrega deve atualizar um ambiente de DTH (Desenvolvimento, Teste, Homologação) com a nova versão gerada, de modo que o usuário já possa utilizar a aplicação em seguida.
É recomendado que esta atualização seja parametrizada, permitindo escolher o ambiente a ser atualizado ou ainda, não atualizar o ambiente.

V-b) Teste de Fumaça¶

Para este passo, espera-se que o processo de entrega automatizada seja capaz de executar os testes de interface, fazendo assim uma validação básica de integridade da nova versão implantada.
Saiba mais em 2.4.2 - Testes.

3.1.2. Ferramentas Necessárias/Sugeridas¶

Para que a Integração Contínua possa funcionar da forma esperada no MP, as ferramentas abaixo são utilizadas atualmente:

• Jenkins
• GitLab
• Registry Docker Privado
• SonarQube
• Nexus
• Rancher