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.