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


bot release fwflex



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