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
Enviar mensagem no discord lembrando os devs de que devem publicar no canal de deploy do Discord os detalhes para implantação de suas issues, como por exemplo execução de scripts e criação de envs.
Link da Automação da Verificação do Canal de Deploy
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.
Pipelines de criação de Pull Requests das Libs
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.
Pipelines de criação de Pull Requests
|
|
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.