Processo de Entrega de Soluções

{{>toc}}

h1. 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

h2. 3.1.1. Fases do Pipeline

h2. *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]] .

h3. *Fase II: Compilação e Build*

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

h4. 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)

<pre>

mvn clean package

</pre>

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

<pre>

npm install

bower install

</pre>

h2. *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.  

h4. 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]].

h4. 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]]. 

h4. 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.

h2. *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:

<pre>

 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

</pre>

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:

<pre>

   sistema-abc

      sistema-abc-frontend

      sistema-abc-backend

      sistema-abc-banco

</pre>

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

h3. *Fase V: Ambiente do Usuário*

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

h4. 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.

h4. 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]]. 

h2. 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*

!site_em_construcao.jpg!