Aqui você encontrará os detalhes do funcionamento do processo do deploy de novas relases do Empodera.

...

Comunicar instabilidade no horário do deploy

...

Completar todos os Pull Requests abertos

Acessar o Dashboard da Azure e verificar como estão os PRs em aberto, é importante que os PRs com pipelines de testes não sejam completos no dia do deploy, porém pode acontecer e por isso acabam ficando em aberto, sendo necessário acompanhamento junto aos devs responsáveis para finalizar a movimentação no Azure.

Pull Request Dashboard

Link da Automação de Notificações dos PRs Abertos

Avaliar branches apartadas

...

Completar repositórios de bibliotecas

...

Criação de Pull Requests para a Main

...

Nessa etapa é importante atenção às alterações que estão subindo, pois em muitos momentos tivemos códigos que não deveriam subir que foram notados nessa etapa. Ex: Código de homologação que foi completado em alguma branch, código de branch apartada que não deveria estar subindo ainda e mexidas não autorizadas na configuração de infraestrutura dos repositórios, como no docker, pipeline e até mesmo main.ts ou app.module.ts.

...

Criar sala Meet

...

Link Branches

Link da Automação

...

Aqui realmente é onde inicia o processo de deploy, ao completar os PRs abertos para a main/master, automaticamente os processos da pipeline e release serão ativados conforme ordem de chegada da fila, por isso é recomendado iniciar sempre pelos repositórios de API e APP, pois os dois são ligados diretamente aos workers que iniciam às 19h.

...

Criar as tags das branches main/master

...

Link da Automação

...

// exemplo levando em conta o repositório empodera_nestjs
// atualizando a branch principal
cd empodera_nestjs
git checkout main
git pull

// [TODO: Remover quando subir ajustes de nginx]
// atualizando a branch intermediárias de homolog
git checkout feature/cetei-8139/nginx-empodera-config
git pull
git merge main
git push

// recriando a branch local de homolog
git branch -D homolog
git checkout -b homolog

// [TODO: Remover quando subir ajustes de nginx]
// remover o arquivo lock das dependências
rm -rf yarn.lock

// [TODO: Remover quando subir ajustes de nginx]
// reinstalando as dependências
yarn --ignore-engines

// [TODO: Remover quando subir ajustes de nginx]
// realizando o commit do novo arquivo
git add yarn.lock
git commit -m "CETEI-XXXX update lock file"

// atualizando o remote para iniciar a pipeline
git push origin homolog --force

Travar branches

...

Link da Automação

...

Mensagem do discord

...

**Deploy realizado com Sucesso**
Atualizem suas branchs.
Deletem a branch de homolog local.

**Branchs - Procedimentos**
Atualizar todas as branchs.
Todas tarefas devem ser iniciadas a partir da branch master

PRs
Back e Front Vue:           v1.xx
Back V2:                    v0.xx
Models:                     v1.0.xx
Angular:                    v0.xx
Auth:                       v0.xx
Email:                      v0.xx

**Hotfix**
Caso aconteça de necessitar de hotfix criaremos a branch no momento.**PRs abertos**
Atualizem as targets para a nova versão

@everyone

Complementar

Pull Requests

• Na criação dos pull requests, é necessário sempre atualizar o package.json com as versões atualizadas, seja do pacote atual ou dependências (empodera-models…), para termos observabilidade das atualizações. Nesse momento ao atualizar o package.json, é importante já avaliar o gerenciador de pacotes, seja npm ou yarn, validar se o package-lock ou yarn.lock foram atualizados corretamente, lembrando que apenas o npm reflete alteração na tag de versão no package-lock, o yarn somente atualiza o lock quando atualiza suas dependências.
• Para completar os PRs, é importante já ir encaminhando os links ou avisar o desenvolvedor que estará acompanhando para que seja possível adiantar os processos.
• Existe um cenário possível durante a etapa de criação de PRs que seria completar algum PR de release ou branch apartada na release, caso isso seja feito depois das 18h será necessário completar o PR com apenas 1 aprovador, com o método de “bypass” disponibilizado na tela de Pull Request, considerando que PRs abertos para target de release são obrigatórios 2 aprovadores, já a main apenas 1.

...

• Ao atualizar as versões dos repositórios, deve-se ter atenção ao número de pontos de versão, pois é necessário possuir 3 itens de versão para que o npm considere a versão válida. Ex: Ao subir a versão para 1.134 no package.json deve estar como 1.134.0.
• [TODO: Remover quando atualizar a versão do lock] Atualmente os repositórios estão todos na versão 16 LTS do Node, porém com a exceção do “empodera_app” e “empodera_api” que utiliza a 14 LTS. Obs: O empodera_api precisa ser instalado com a 14 mas ao commitar é necessário atualizar para a 16 devido a um conflito com o eslint.

...