Garantir com o time de QAs que o comunicado de indisponibilidade, disponível no UserGuiding.
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.
Link da Automação de Notificações dos PRs Abertos
No geral os desenvolvedores irão sempre utilizar a release correta como target nos Pull Requests abertos durante a sprint. Em alguns casos existem atividades que estão sendo feitas paralelamente em branches apartadas, ou casos onde foram completos em branches de hotfix, porém não houve o hotfix, e em último caso, pull requests completos em release ou qualquer outro target incorreto.
Nesse caso é importante sempre analisar todos os "pull requests" abertos na sprint anterior para cada repositório e avaliar se todos foram completados corretamente.
Para quando houver desenvolvimentos que não estão na release e deveriam subir no deploy, abrir os PRs necessários apontando para a target release do deploy, e completar antes de iniciar o deploy.
No caso de repositórios de bibliotecas, como o empodera-models e empodera-rules-engine, é necessária realizar o deploy para a main antes do deploy de fato, pois como o deploy desses repositórios não ativam nenhuma rotina nas máquinas de release, e também por serem dependências dos outros repositórios, é o ideal já executar com antecedência para ajustes e criações dos demais pull requests até o horário do deploy.
Após completar os repositórios de bibliotecas, é possível iniciar a criação e atualização dos demais repositórios. Criando sempre apontando a release para a main/master e validando se todos os itens atualizados fazem sentido com a subida a ser realizada.
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.
|
|
Avaliar se todas as orientações do canal de deploy já estão prontas, e solicitar aos desenvolvedores que revisem as informações fornecidas. Nesse momento devemos acessar a máquina de produção e ajustar variáveis de ambiente que foram passadas.
Criar sala no Google Meet e convidar as pessoas necessárias para a realização e acompanhamento do Deploy + Testes.
Antes de completar cada repositório, é necessário acessar a página de branches do Azure de cada repositório, e desbloquear (unlock) a branch main/master, para liberar o PR para completar.
Sugestão de início às 17h45.
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.
Importante frisar que o deploy não ultrapasse 18h45 pois começa a ficar arriscado atrasar ou impactar a execução dos workers que iniciam às 19h, em caráter de exceção é permitido pausar os workers quando der algum erro no processo de deploy, mas a melhor orientação é que caso dê algum problema que não possa ser solucionado rapidamente e não possua expectativa da possível solução, é sugerido o interrompimento do processo de deploy e acionar os gestores da equipe.
Para acompanhar os processos das releases, acessar o link: Releases Azure
Acessar página de tags de cada repositório de criar tag com o nome da versão que foi realizada o deploy usando como base a branch main/master. Ex: Deploy da release/v1.134 deve ser criado a tag com o nome v1.134, com a descrição “Deploy realizado DD/MM/YYYY”.
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:
// 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 |
Após completar os PRs, travar novamente as branches main/master de cada repositório.
Criar novas releases com a versão acrescentada conforme numeração da última sprint.
Também vale realizar nesta etapa o travamento das branches de release da sprint anterior para evitar que algum PR seja completado erroneamente.
Opcional: De vez em quando é interessante remover algumas branches antigas que já foram validadas em produção e não teria mais necessidade de algum revert ou uso de código.
Link da Automação para Criação de Branchs
Após finalizado Publicar ao final do processo de testes a mensagem no grupo de deploy informando a finalização com sucesso, ou não, do Deploy. A automação anterior já enviará a mensagem automaticamente então, caso queira realizar o envio manual, desabilite o node Discord no fluxo do n8n.
Template da mensagem:
**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 |
git commit -m "CETEI-XXXX update package version¨ |