| ... | ... | @@ -5,3 +5,39 @@ |
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
# Entrega contínua
|
|
|
|
|
|
|
|
O processo de entrega contínua consiste numa série de automatizações que garante uma entrega de software mais rápida, fácil e segura. Esse processo, como já citado anteriormente, é gerenciado pelo Jenkins, e o mesmo é dividido em duas etapas.
|
|
|
|
|
|
|
|
## CICLO DE DESENVOLVIMENTO
|
|
|
|
|
|
|
|
O ciclo de desenvolvimento consiste no processo de desenvolvimento do projeto. O mesmo tem como padrão as seguintes etapas:
|
|
|
|
1. O desenvolvedor faz um pull (ou clone, se for a primeira vez) do repositório do projeto no Gitlab.
|
|
|
|
2. Após isso, o desenvolvedor faz as suas contribuições para o projeto e realiza um commit (local) das mesmas.
|
|
|
|
3. Então, o desenvolvedor realiza um push desses commits, enviando suas contribuições para o Gitlab
|
|
|
|
4. O Gitlab identifica que teve um novo push no repositório e sinaliza o Jenkins;
|
|
|
|
5. O Jenkins, faz um pull do repositório, realiza um build e roda os testes unitários desse projeto para então mandar um e-mail para o desenvolvedor notificando-o sobre os resultados dos testes unitários.
|
|
|
|
|
|
|
|
Segue abaixo uma ilustração desse ciclo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## INTEGRAÇÃO DESENVOLVIMENTO-HOMOLOGAÇÃO
|
|
|
|
|
|
|
|
A integração entre o ambiente de desenvolvimento e o ambiente de homologação é feita exclusivamente pelo integrador. E esse processo consiste nos seguintes passos:
|
|
|
|
1. O integrador realiza o merge das branches (pode haver mais de uma) de dev para a branch de homo.
|
|
|
|
2. Manualmente, o integrador deve localizar no Jenkns a view de homo do seu respectivo projeto. Nela, ele encontrará instruções de como realizar o build e o deploy do mesmo. Em geral, ele deverá apenas clicar na job de build se o projeto não tiver Liquibase. E, em caso contrário, clicar na job de sql. 3. As demais jobs são chamadas automaticamente (qualquer exceção estará escrita na descrição da view).
|
|
|
|
4. A partir disso, o Jenkins realizará um pull da branch de homo, realizará um build e aplicará os testes unitários. Caso não haja falha nos passos anteriores, ele realizará o deploy da aplicação no Gates e, se houver o Liquibase no projeto, realizará o deploy do banco de dados no Turing.
|
|
|
|
5. Ao final de tudo, é enviado um e-mail ao Integrador com o resultado do build e dos testes unitários.
|
|
|
|
|
|
|
|
Segue abaixo, ilustração dos passos descritos acima.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.2.2 INTEGRAÇÃO HOMOLOGAÇÃO-PRÉ-PRODUÇÃO
|
|
|
|
A integração consiste na migração do build de um projeto que se encontra em homologação para o ambiente de pré-produção. Esse é um detalhe muito importante desta etapa, pois nela não é feito o build do projeto, apenas um novo deploy no ambiente de pré-produção conforme os passos abaixo:
|
|
|
|
1. O Integrador deve manualmente buscar a view de pré-produção do projeto, e seguir as instruções descritas. Em via de regra, se o projeto tiver Liquibase, é preciso apenas clicar na job de sql e, se não tiver ou você quiser apenas fazer o deploy sem rodar o Liquibase, é só clicar na job de deploy.
|
|
|
|
2. Após isso, o Jenkins automaticamente faz o deploy do último build realizado com sucesso no servidor Jobs. Se o usuário optar pelo Liquibase, ele realizará o deploy desses scripts de banco de dados no Tesla.
|
|
|
|
|
|
|
|
Segue imagem do respectivo processo:
|
|
|
|
|
|
|
|
 |
|
|
\ No newline at end of file |
