Estamos lançando um projeto Java com o Maven de uma nova maneira

Todos nós já estamos acostumados ao Maven , ao versionamento que ele oferece e ao gerenciamento de dependências. Maven nasceu quando a montagem diária do projeto foi a mais ousada, quando foi considerado normal ser lançado pelo menos duas vezes por ano, Jenkins se chamava Hudson e as árvores eram grandes ...

As idéias que trouxeram para o mundo do desenvolvimento eram extremamente populares e rapidamente ganharam popularidade: definindo um projeto de fluxo de trabalho padrão, um modelo de diretório padrão e muito mais, que há muito tempo é um dado adquirido.

Como uma das inovações, a maven introduziu um sistema de controle de versão padrão. A versão foi armazenada no arquivo do projeto e alterada sempre que lançamos uma nova versão. Em um mundo em que fazer um ramo e sua merjunt não era uma façanha acessível a todos, essa abordagem era bastante comum.

Tudo isso simplificou muito o desenvolvimento, o início de novos projetos, a introdução de desenvolvedores no projeto, o lançamento da versão e o gerenciamento de dependências.

Mas o mundo não fica parado e, apesar de muitas idéias implementadas pelo maven ainda viverem e passarem de um projeto para outro, a versão do maven se tornou mais um problema do que uma vantagem.

Em seguida, tentaremos mudar o mundo para melhor e simplificar nossas vidas.


Nas realidades modernas, o lançamento de várias versões por semana e até por dia é considerado, se não a norma, o objetivo. E, nessas condições, armazenar a versão no arquivo do projeto gera uma sobrecarga muito grande.

Cada release leva a duas confirmações no repositório e, como resultado, com o desenvolvimento e a liberação ativos do projeto, há mais confirmações técnicas do que úteis. A história do projeto é desarrumada e difícil de entender.
Além disso, essa abordagem leva à duplicação de informações: tornou-se habitual armazenar a versão não apenas no arquivo do projeto, mas também na forma de uma tag de repositório.

Além disso, surgiu a questão da segurança: quando você tem um projeto grande, a máquina de construção precisa acessar apenas a ele. Quando existem muitos projetos, o acesso a muitos projetos é necessário e criamos um superusuário com acesso a todos os projetos com direito de gravar ou temos o ônus adicional de administrar um grande número de usuários com um conjunto restrito de direitos, mas ainda com o direito de gravar no repositório, e frequentemente, e o direito de se comprometer com o mestre sem solicitar pool e revisão.

Ao usar o maven com o plug-in de lançamento, outro recurso interessante aparece: a reconstrução não é executada com o mesmo conjunto de comandos da versão original.

Talvez todos esses problemas pareçam absurdos para alguém, mas com um número mais ou menos grande de projetos, gerenciar e configurar o CI / CD se transforma em um processo extremamente desagradável e confuso.

Agora que o problema está visível, vamos tentar resolvê-lo, para que não alteremos o conjunto de ferramentas, processos e, em geral, ele próprio, de alguma forma.

O que é necessário:

• versão é armazenada uma vez, como uma tag de repositório
• possível a reconstrução de qualquer release, o conjunto de etapas deve ser o mesmo que no caso de um novo release
• não precisa de permissões de gravação no repositório
• ainda usamos o maven como gerente de projetos

Suponha que o CI / CD obtenha uma tag para nós e confira um projeto.

Suponha que a tag para nós seja preenchida com CI / CD na variável de ambiente RELEASE_TAG e, para liberar o release, devemos executar os seguintes comandos:

mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2) 

1 - atualiza versões em arquivos pom do projeto e seus módulos
2 - constrói e, se o projeto estiver configurado corretamente, carrega artefatos no repositório

Não se esqueça de definir o sinalizador -B , caso contrário, o log de execução se transformará em uma abóbora.

Importante: para evitar confusão e mostrar claramente como e de onde vem a montagem, é necessário instalar a versão do projeto em algo abstrato, por exemplo, INSTANTÂNEO DE DESENVOLVIMENTO. Você pode usar o mesmo comando: version: set. A operação é única, porque não armazenamos mais a versão do projeto em um arquivo.

Como resultado das alterações, você pode remover a configuração maven-release-plugin e a configuração do bloco scm do arquivo pom.

»Das desvantagens:
Se você usar as versões do INSTANTÂNEO em algum lugar, poderá haver confusão, agora todas as versões do INSTANTÂNEO terão a mesma aparência. E talvez essa maneira de liberar projetos não seja para você.

Pode parecer que o artefato coletado do mesmo commit, mas com tags diferentes, seja o mesmo, mas, infelizmente, não é assim. Ainda expomos a versão no arquivo e, como resultado, os pacotes coletados serão diferentes.

»Dos profissionais:

• Todos os requisitos são atendidos e ainda mais!
• versão é armazenada apenas na tag do projeto
• a montagem do novo e a reconstrução da versão antiga são executadas pelo mesmo conjunto de comandos que a versão original
• não há necessidade de direitos se comprometerem com o projeto
• a caixa de ferramentas permanece a mesma
• bônus: configuração do projeto simplificada

Então, duas linhas novamente salvaram o mundo.
Só isso, obrigado pela atenção!