A teoria é linda e fofa. O goal release:prepare irá:
- Criar uma tag com o nome da versão
- Mudar todos os seus pom.xml pra versão que vc fará release
- Fazer um "mvn clean install" pra ver se os testes passam todos
- Incrementar o seus pom.xml pra nova versão SNAPSHOT
- Fazer commit&push dessas parada tudo
- Fazer checkout daquela tag
- Fazer OUTRO "mvn clean install" (tipo por que não, né?)
- Fazer "deploy" dos seus binários todos (pro nexus ou qualquer lugar que vc configurou no seu "distributionManagement")
- Gerar javadoc, sources e fazer deploy também
Parece bem legal se você pensar que você terá a tag no seu SCM, e ela bate com o artefato que foi para seu maven remoto, etc. Uma coisa engenhosa e linda.
Para que funcione no seu projeto, a teoria diz que você apenas precisa definir adequadamente a tag "scm" no seu pom.xml.
Além disso, você obviamente precisa configurar para onde as coisas serão deployadas:
Simples, né? Vamos aos detalhes, porque sabemos que "o demônio mora nos detalhes".
- Por padrão, o goal prepare irá pedir para que você confirme a versão nova, a versão a fazer release, o nome da tag. Invocar o maven em batch mode (-B) usará os valores default.
- O release:perform irá criar uns arquivos temporários para que o release:perform seja executado. Isso é, você não pode fazer um prepare em uma máquina e o perform em outra.
- Rollback is a lie. Aceite. Se falhar por QUALQUER motivo, o release:rollback não vai te ajudar, vai te deixar em estágios intermediários que não dá nem pra corrigir e ir pra frente nem voltar pra trás. Váaaarias vezes vc tem que consertar tudo manualmente.
- Você tem a opção de usar "https" ao invés de "ssh" no scm. Mas não faça. O plugin de release vai te pedir para colocar username/password a cada mínima mudança. Faça por ssh.
- Tenha certeza de já ter feito commit, push, pull de toda e qualquer alteração no seu repositório
- Não podem ocorrer commits entre o começo do release e o fim. Isso, manda todo mundo parar de commitar.
- Os "mvn clean install" rodam em uma outra invocação do maven, que não recebe os mesmos argumentos que você passa na linha de comando. Isto é, aqueles "-Dalgumacoisa" que seu build precisa não serão recebidos. Como opção, passe-os dentro do "-Darguments" ou como variáveis de ambiente
- Caso você deseje ardentemente pular todos os testes (por sua conta e risco), utilize "-Darguments='-DskipTests'", e nunca "-Darguments='-Dmaven.test.skip'". O último faria com que os jars de testes não fossem nem gerados, nem deployados.
- Por padrão o perform irá fazer o deploy e deploy-site, além de habilitar o profile "release-profile". Isso é totalmente configurável no plugin, então sinta-se em casa.
Como a documentação é sua melhor amiga, vá lá e sinta-se à vontade.
E claro, nada te impede de fazer release a partir do CI ;) Apenas garanta que o usuário tem permissão de escrita, que não é "shallow clone" (se for um checkout git), e pronto.


Nenhum comentário:
Postar um comentário