Produção

A liberação de versões do FWFLEX é realizada através do devbot e ocorre em 3 situações:

HOTFIX: liberado todas às quartas-feiras quando há bugs na hotfix
RELEASE: liberado mensalmente na penúltima quinta-feira do mês
BUG CRÍTICO: liberado sob demanda conforme necessidade

O identificador da versão que será lançada é definida pelo bot e respeita sempre o tipo dos tickets conforme preenchido no changelog.

A liberação de versão é realizada pelo PO do produto e consiste em analisar o merge request, merge da branch para a master, liberação pelo BOT, organização do REDMINE e comunicação da liberação.

Etapas

1. Validação Inicial

A liberação de versão do FWFLEX acontece após os testes de fumaça já realizados pelo PO. A entrega final dos testes de fumaça deve ser validada inicialmente:

• Branch da entrega que será liberada com 1 commit + 1 changelog para cada ticket

  • No caso de um bug crítico, a branch que é mergeada será a própria branch do bug (Conforme gitflow) e deve seguir o mesmo conceito

2. Merge da branch para a branch master

A liberação de uma nova versão é baseada em gerar pacotes baseado no conteúdo que está na branch master, então o conteúdo da branch que será liberada deve ser mergeada para a master.

• Validar se a branch tem commits para trás da master

• Se essa mensagem acima for exibida, é necessário realizar rebase da branch que será liberada com a master:

git checkout master
git up
git checkout $BRANCH
git up
git rebase master
git push -f

• Após rebase, aguardar passar a pipeline e validar que a mensagem não será mais exibida.

• Marcar a branch como READY e mergear para a master

• Aguardar passar as pipelines do merge na master

3. Gerar nova release

• Gerar nova release do fwflex através do BOT no Rochet.Chat

bot release fwflex

• Aguardar passar as pipelines que foram geradas

4. Preparar próxima release

Quando é realizada liberação de hotfix ou release, é necessário criar a nova branch

• Criar a nova branch através da interface do git

  • Branch name: utilizar nomenclatura conforme gitflow (hotfix-v3.xx.x, release-v3.xx.0)

  • Create from: master

• Criar Merge Request para a próxima liberação

  • Utilizar botão que será exibido após criação da branch

• Somente criar merge request sem preencher nenhuma informação

• Apontar MRs de bugs/feats não concluídos para a nova MR de hotfix/release aberta

4. Rebase das branch's existentes

Quando é realizado merge de alguma branch para a master, é necessário fazer rebase de todas as branchs que apontam para a master e estão sob responsabilidade dos PO's:

• Hotfix

• Release

• Features que apontam para a Release

• 
  

5. Ajustar releases Redmine

• Criar próxima versão da hotfix ou release no Redmine

  • Se algum bug ou feature não foi liberado, associar o ticket à nova versão criada

• Alterar todos os tickets que foram liberados para a Situação Released

• Alterar a Situação da versão que foi liberada para Fechado no Redmine

• Editar o filtro do Redmine de Hotfix ou Release e alterar para a nova versão criada