git, maven e jenkins - versionamento, desenvolvimento e lançamento constroem fluxo de trabalho

Qual é a maneira preferida de fazer o seguinte com git, maven e jenkins:

Estou desenvolvendo um aplicativo que gostaria de manter os ramos "dev" e "release". Eu gostaria que Jenkins construísse os dois. Pode ser que os artefatos de release tenham versões como 1.5.2 e os dev-builds sejam apenas 0.0.1-SNAPSHOTs. Eu gostaria de não ter que ter 2 arquivos pom.xml diferentes.

Examinei os perfis, mas eles não parecem capazes de alterar as versões de artefatos. Uma maneira que eu olhei poderia ser adicionar um 'qualificador' às construções de teste. É claro que eu poderia renomear o arquivo, porque as informações reais sobre artefatos sobre isso não são importantes, porque o aplicativo é independente.

Qual seria a maneira preferida de fazer isso? Ou como você faria isso?

Eu imaginaria que deveria haver um relacionamento inerente entre esses ramos que deveria resolver o problema dos números de versão.

Liberando

Eu imaginaria que você poderia fazer algo como mesclar código pronto para produção do ramo de desenvolvimento para o ramo de lançamento e depois executar um lançamento do Maven (via Jenkins ou manualmente). Isso rola automaticamente os números de versão para a próxima compilação. Portanto, você mescla o código 1.4.7-SNAPSHOT a essa ramificação, executa a versão 1.4.7 e o Maven rola automaticamente sua cópia de trabalho para 1.4.8-SNAPSHOT.

Atualização da linha de base (opcional)

Se você ainda não estiver usando seu tronco (ou ramificação da linha de base, etc.) como um local para suas liberações, atualize o tronco assim que concluir uma liberação. Isso significa que seus números de versão também estão sendo atualizados. Esta etapa pode ser discutível se você considerar apenas o ramo de lançamento como a linha de base.

Mesclagem da linha de base para a ramificação do desenvolvedor

É essencial que seu ramo de desenvolvimento fique atualizado com o código de produção real . Você precisa mesclar o código da linha de base (ou ramo de lançamento, dependendo da implementação) até o ramo de desenvolvimento. Isso é importante no seu caso, porque significa que as alterações de pom que ocorreram durante o processo de lançamento, que alteraram a versão para 1.4.8-SNAPSHOT, são trazidas para esse ramo.

Com base nas leituras que eu fiz (assim como nos processos da minha organização), esse parece ser um uso bastante padrão e eficaz dos releases e snapshots do Maven e, em vez de manter números de versão completamente desconectados em diferentes ramificações, é fácil dizer que qualquer compilação do 1.4.7-SNAPSHOT era de fato um antecessor imediato da versão 1.4.7. Eles são parentes. Eu diria até mesmo que, se você não estiver mesclando entre esses ramos, você está fazendo a versão errada do SCM e do Maven e corre o risco de desenvolver um código que não corresponde à produção , reintroduz bugs na produção etc.

Repensar sua abordagem.

É muito comum usar, por exemplo, o 1.4.2 para uma versão de lançamento e o 1.4.3-SNAPSHOT para o desenvolvimento para o próximo.

Quando você precisar manter a liberação 1.4.2 THEN, ramifique-a da confirmação que originou seu artefato 1.4.2.

Em seguida, você diz ao Jenkins a localização do seu repositório e o nome da ramificação, resultando em um check-out de um conjunto de arquivos, e então diz ao Jenkins para usar o maven em seu projeto para construí-lo.

Nota: Descobri que é muito benéfico usar um único pom.xml para criar o artefato real e outro pom.xml para criar os bits reais a serem enviados ao cliente.