...

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.

git commit -m "CETEI-XXXX update package version¨