Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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.

Informações
titleAtenção as versões do Node.js
  • API e APP: Node.js v14
  • Demais repositórios: Node.js v16
Informações
titleAtenção aos gerenciadores de pacotes
  • Workers, Email Service, Auth, Angular: Yarn
  • Demais repositórios: NPM

...

Criar sala Meet

Criar sala no Google Meet e convidar as pessoas necessárias para a realização e acompanhamento do Deploy + Testes.

...

Para realizar o tombamento de homologação, é necessário em todos os repositórios, criar uma nova branch de homolog a partir da main/master, e subir para homologação. Isso pode ser feito deletando as branches de homolog direto no Azure ou realizando o git push com a flag –force. Não se esqueça de iniciar pelos repositórios das libs.[TODO: Remover quando subir ajustes de nginx] Por enquanto, em homologação estamos com branches apartadas para alguns ajustes de atualização de infraestrutura e gerenciadores de pacotes, por isso, ao tombar homologação é necessário realizar o merge com as branches: (empodera_api - release/separate-app-and-api) (demais repositórios - feature/cetei-8139/nginx-empodera-config. Após criar a nova branch de homolog nos repositórios de backend (empodera_api, empodera_nestjs e empodera_workers), exclua o arquivo yarn.lock e instale as dependências novamente

Pipelines para tombamento de Homologação

Caso não seja possível executar as pipelines acima, realize os passos abaixo para cada repositório:

Bloco de código
// 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

...

  • Na criação dos pull requests manuais, é 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.


Bloco de código
git commit -m "CETEI-XXXX update package version¨