Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • F fluxoages
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • oldfluxo
  • fluxoages
  • Wiki
  • entregacontinua

Last edited by André Botelho May 16, 2017
Page history

entregacontinua

|Home|Pedagógico|Gestão de Projetos|Interdisciplinar|Infraestrutura|FluxoAGES |---|---|---|---|---|---|---|

|Infraestrutura Física| Servidores Virtuais | Ambientes | Ferramentas|Entrega contínua |---|---|---|---|---|---|

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.

CICLO_DEV

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).
  3. 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.
  4. 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.

DEV_HOMO

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:

HOMO_PREPROD
Clone repository
  • ambientes
  • configProjAges
  • configProjApi
  • configuracao
  • entregacontinua
  • ferramentas
  • fluxoages
  • fluxoapipython
  • fluxoapp
  • geral
  • Home
  • infraAges
  • infraestrutura
  • infrafisica
  • instalacao
View All Pages