1) O documento descreve fluxos de correções e lançamentos de recursos no GIT para a OCTO Tecnologia, incluindo hotfixes, bugfixes e recursos. 2) Os fluxos incluem ramificações, validações, merges e liberações em diferentes ambientes como master, homolog e develop. 3) As correções são liberadas individualmente ou em conjunto com lançamentos seguindo processos específicos de cada fluxo.

1. Fluxos GIT OCTO Tecnologia e
Consultoria de Softwares

2. HotFix – Correções para publicar antes
do Release
master
homolog
hotfix
1 - Branch a partir
da master
2 - Merge do hotfix com homolog
pra validação
Após Homologação
3 - Merge de master para hotfix
4 - Merge de hotfix para master
NÃO faz merge de homolog com master
Publicação: master, baixa e compila a master para publicar.
SEMPRE publica-se em produção a partir da master e não do 30

3. Descritivo do Fluxo HotFix
1 - Começou a Tarefa da cor Vermelha, faz uma branch (hotfix/hotfix_issue#):
BRANCH: Master > Hotfix
Mover Card do Sprint Backlog para Executando
2 - Depois que termina a Tarefa,
MERGE: Hotfix > Homolog
Mover o Card para Homologação
3.1 – REPROVADA
Corrige na Branch do Hotfix o apontado pela Homologação, volta ao passo 2
3.2 – APROVADA (Terminou de validar e está pronta pra publicar)
MERGE: Master (master-to-merge) > Hotfix (resolvendo todos os conflitos)
MERGE: Hotfix > Master (master-to-merge) e marca para excluir a branch do
hotfix
4 – Solicita publicação ao Responsável.

4. BugFix (homolog) – Correções que
serão publicadas junto com o Release
homolog
homolog
bugfix
1 - Branch a partir
da homolog
2 - Merge do bugfix com homolog
pra validação
Após Homologação
3 – Move o card para Publicação
4 – Só publica após esvaziar
coluna Homlogação
Publicação: Faz merge de homolog com master, baixa e compila a master para publicar.
SEMPRE publica-se em produção a partir da master e não do 30

5. Descritivo do Fluxo BugFix(homolog)
1 – Tarefa em Retrabalho que não é HotFix, faz uma branch (bugfix/bugfix_issue#):
BRANCH: homolog > Bugfix
Mover Card do Retrabalho para Executando
2 - Depois que termina a Tarefa,
MERGE: Homolog > Bugfix – resolve conflitos, compila novamente e testa local.
MERGE: Bugfix > Homolog
Mover o Card para Homologação
3.1 – REPROVADA
Corrige na Branch do Bugfix o apontado pela Homologação, volta ao passo 2
3.2 – APROVADA (Aguardar todas as tarefas em Homologação para publicar)
A tarefa aqui é movida para a coluna Publicação, onde irá aguardar o
restante da homologação, e será publicada em conjunto, ou seja, um Release.

6. Feature/BugFix (develop) – Correções que
serão publicadas junto com o Release
develop
develop
Feature /
bugfix
1 - Branch a partir
da develop
2 - Merge do feature/bugfix com
develop pra validação fechar RC
Após Homologação
3 – Move o card para Publicação
4 – Só publica após esvaziar
coluna Homlogação
Novas RCs: a cada duas semanas (aproximadamente) gera-se um novo Branch de RC
a partir de develop que irá aguardar a validação da homolog já existente.
Homologação de RC: Faz merge de homolog com RC e depois RC com homolog, e
publica no 30 com o Jenkins

7. Descritivo do Fluxo Feature/Bugfix(develop)
1 – Começou uma Tarefa (laranja, azul ou verde), faz uma branch a partir de
develop (laranja: bugfix/bugfix_issue# ou azul/verde: feature/feature_issue#):
BRANCH: develop > bugfix/bugfix_issue# ou feature/feature_issue#
Mover Card do Sprint Backlog para Executando
2 - Depois que termina a Tarefa,
MERGE: develop > bugfix/bugfix_issue# ou feature/feature_issue#
– resolve conflitos, compila novamente e testa local.
MERGE: bugfix/bugfix_issue# ou feature/feature_issue# > develop
Mover o Card para Merged on Develop
OBS: A tarefa aqui é fica aguardando o fechamento do próximo conjunto de
alterações (RC – Release Candidate) na coluna Merged on Develop, e será
homologada em conjunto, ou seja, um novo Release.

8. Finalização de Homologações
Pendentes, liberação para publicação
 1 – SE TODAS as tarefas da coluna Homologação foram validadas e estão em Publicação:
MERGE: master > homolog onde:
 Resolve conflitos
 Compila e testa local
 Propaga alterações/correções que estavam na master pra homolog
MERGE: homolog > master
 Compila e testa local
 Publicação de ASPs a partir do PULL da Master, NÃO publicar a partir do ambiente de homologação
 Publicação de Código Compilado SOMENTE a partir do Jarbas
 2 – Aciona publicação automatizada através do console do Jenkins ou aguarda a publicação
agendada periódica (recomendado).
 3 – Após a publicação, move os cards para Pronto, faz as interações no Chamado e devolve
ao responsável por comunicar ao Cliente.
 4 – Comunica no Canal #release-notes quais tarefas foram publicadas e o que cada uma vai
afetar no funcionamento do sistema.

9. Fechamento de RC COM
Homologações Pendentes
 1 – Cria uma nova Branch a partir de develop:
BRANCH: develop > RC.2020.07.01 onde:
 2020 – ano atual
 07 – mês atual
 01 – número da RC gerada no mês
 2 – Move os cards que estão em Merged On Develop no momento da criação
da Branch para Fechamento RC.
 3 – SOMENTE APÓS a liberação da Homologação para publicação (slide
anterior):
MERGE: homolog > RC.2020.07.01 onde:
 Resolve conflitos
 Compila e testa local
MERGE: RC.2020.07.01 > homolog
 4 – Aguarda o Jarbas (HML) realizar a publicação periódica ou aciona a
publicação no console.

10. Fechamento de RC SEM
Homologações Pendentes
 1 – Faz MERGE de homolog com develop, e develop com homolog:
MERGE: homolog > develop onde:
 Resolve conflitos
 Compila e testa local
 Propaga alterações/correções que estavam na homolog pra develop
MERGE: develop > homolog
 2 – Move os cards que estão em Merged On Develop no momento do
Merge para Homologação.

11. Linhas do Tempo