Real-World Strategies for Continuous Delivery with Maven and Jenkins
Why Stack Overflow recommends it
Stack Overflow users link it when answering how to version and release Maven projects in a continuous delivery pipeline, especially why to avoid snapshots and the maven-release-plugin.
Recommended by 3 people across 3 different months, 2013 to 2019.
What it is
A JavaOne-era Oracle Learning presentation on reconciling Maven's snapshot-and-release model with continuous delivery, where any commit passing quality gates can be a release. It surveys strategies and demonstrates one using Maven, Jenkins, and Git.
What people said
Recommends Mark O'Connor · 2013-08 · Stack Overflow · on “What is the Maven way for automatic project versions when doing continuous delivery?”
I recommend the following presentation that discusses the practical realities of doing continuous delivery with Maven: You tube presentation on CD with Maven [this video] Slides [LINK] The key takeaway is each build is a potential release, so don't use snapshots.
Recommends ams · 2013-10 · Stack Overflow · on “How to use the maven versions plugin to pick the next version number?”
@Henry I am working implementing the strategy describe in this JavaOne video for doing continuous integration with maven [this video] if you watch it it will explain why the release plugin is not a good to use for continuous delivery.
Recommends Sergej Koščejev · 2016-01 · Stack Overflow · on “Jenkins autobuild goes into a loop when github commit triggers the build”
I'd suggest not committing the version update to the master branch but create a separate tag every time. Something like this: v1 v2 v3 / / / --A----B----C (master) I got this approach from Real-World Strategies for Continuous Delivery with Maven and Jenkins [this video] video ( corresponding slides [LINK] ) - it contains other tips on setting up build pipelines with Maven as well.
Cites ccobanoglu · 2014-09 · Stack Overflow · on “Deleting old release branches on build pipeline (Jenkins)”
We are using Jenkins build pipeline plugin. And our continuous delivery strategy is simply like that; Team pushes code, Jenkins initial job triggered.... A new release branch created. if packaging and unit testing are successful. then Push release branch to github otherwise delete locally created branch. Artifacts archived and .... .... My reference : [this video] As it is seen on step 4 every job triggers creates new branch and it causes to occur a branch pollution on our SCM. How can i remove old branches from SCM (Github) i want to keep at least 5 newest branches on github. Note : We do not deploy every build to production.
Cites betodelrio · 2015-07 · Stack Overflow · on “Development workflow with Jenkins + Git + Crucible + Jira?”
Developer team has specific requirements for tools. [I have] [LINK] [read] [LINK] [a lot] [LINK] [about] [LINK] [ideal] [this video] [workflows] [LINK] and came up with something that works like this: Developer creates a change request, hotfix, feature, etc in Jira . That unique item id will be tracked along the work flow. Developer pulls repo from Git , creates a feature-a branch, commit changes locally and pushes to remote git repo. Pushes to master are forbidden. Git hook triggers a Jenkins job which runs a smoke test (compilation and unit tests). If tests pass then creates a revision in Crucible . Unless code review committee approves changes, we have to start from step (1). Crucible triggers
Cites overexchange · 2019-01 · Stack Overflow · on “Principles of continuous delivery”
As mentioned here [this video] , Below are the principles for continuous delivery. Every build is a potential release Eliminate manual bottlenecks Automate wherever possible Have automated tests you can trust In traditional build process, without using continuous delivery approach, We commit the code in master branch, for multiple reasons, mainly for collaboration among developers and testers. With respect to first principle, How can every commit be a potential release?
Critical hfm · 2018-01 · Stack Overflow · on “What is the Maven way for automatic project versions when doing continuous delivery?”
The presenter on the youtube video that you are linking to is actually explicitly saying that you should avoid using the "maven-release-plugin". See here: [this video]