Esteira DEV/HML/PRD

Olá,

Pra garantir que o pacote publicado em produção seja o mesmo que foi testado em homologação, o ideal é que o artefato seja gerado apenas uma vez, durante o deploy para HML. Esse artefato (por exemplo, um .jar, .zip ou imagem Docker) é salvo em um repositório de artefatos como Nexus, S3, Artifactory ou GitHub Packages. Quando for a hora de publicar em produção, a esteira simplesmente reutiliza esse mesmo artefato, sem rebuild.

O fluxo geralmente começa com o desenvolvedor subindo as alterações na branch develop. A esteira roda os testes unitários, análise de código com SonarQube e validações automáticas. Quando está tudo certo, se cria uma branch release a partir da develop. A partir dessa branch, a esteira gera o artefato final e faz o deploy em HML. Lá, ocorrem os testes de integração, testes automatizados e manuais. Se estiver tudo validado, o deploy em produção acontece usando exatamente esse mesmo pacote, garantindo rastreabilidade e controle.

Sobre rollback, como os artefatos ficam versionados e salvos, é possível voltar a uma versão anterior apenas fazendo o deploy do artefato correspondente, sem necessidade de reconstruir nada.

Os testes unitários e SonarQube normalmente são feitos na esteira de DEV, já os testes de integração e validações finais ocorrem em HML. Só após o sucesso em produção é que se pode fazer o merge da branch release para a main. Assim, a main sempre reflete o que está de fato em produção. Esse controle evita inconsistências e garante conformidade com processos de auditoria.

Olá @Estudante, primeiramente obrigado pela atenção. Muita coisa que vc citou, é o que já tinha visto conceitualmente com algumas pessoas e na qual estava pensando em utilizar. Mas mesmo assim ainda há dúvidas porque não achei material completo com exemplo real fazendo tudo acontecer. Na minha visão, estava pensando em compilar, executar testes, sonarqube e veracode apenas na esteira de DEV. Mas entendi seu ponto de vista. Isso é um padrão de mercado ou vocês que utilizam desse modo? Outro ponto é como fica a gestão das imagens ? se estiver usando cloud aws, é boa prática utilizar um artifactory ou manter a imagem somente na AWS? Como funciona o expurgo destas imagens? Como a esteira de produção é iniciada? Em caso de rollback em produção, como a esteira irá fazer isso? por mais que exista a imagem na aws ou no artifactory, como é feito esse controle para saber exatamente qual a última imagem publicada em produção válida? Outro ponto crítico e que nunca vi falarem é o fato de em poucos dias a imagem estar obsoleta e com algum apontamento de vulnerabilidade. E se a empresa for rigida com isso, irá pedir para resolver tais problemas que em 99% das vezes são vulnerabilidades na imagem e precisa ficar subindo versão. E para corrigir vulnerabilidades é necessário alterar manualmente o código/versão da imagem docker e compilar novamente sua versão em novo pacote, mesmo que NÃO tenha nenhuma alteração de negócios. Inviável trabalhar desse modo, pois aparecem vulnerabilidades toda semana. Sua resposta ajudou muito a pavimentar o que eu estava imaginando... são apenas pequenos detalhes que são obscuros e quase todo material que encontro é superficial e só tratam o caminho feliz... rodando esteira e publica sem levar em contas diversos ambientes como DEV, HML, PRD, gestão de fontes/branchs e merges e principalmente rollback. E se entrar no assunto de ter mais de um time de desenvolvimento alterando a mesma aplicação simultaneamente, aí dá pano pra manga e a conversa vai longe.