I've put a lot of thought into this because I'm working on designing
continuous delivery with Maven, Hudson, and Nexus. Our criteria is this:
- We want to have continuous integration of stable versioned components.
- We don't want to have noise in the SCM logs.
- We want builds to be repeatable and traceable.
- We want it to be easy for developers to work on features without having to
deal with dependency versions.
- We want the system to be simple.
- We want to know what changed between different deployable versions of the
system.
- We want to avoid needing to build the same revision of a component twice.
- We want it to be easy to debug locally against any specific integration
pipeline build's versions.
This is what I'm thinking:
Maven:
- The pom.xml has a SNAPSHOT version and version ranges for its
dependencies. In a multi-module project, only the parent pom should have
the version ranges, and the sub-modules inherit them.
- For complicated projects, a dependency-management pom.xml should be used
which all projects import. It only has specific versions (not version
ranges) in its dependencyManagement section. Each project pom.xml imports
it using a version range.
- Use the maven-buildmetadata-plugin to capture the SCM revision and URL in
each built artifact.
Component Pipeline (e.g. Hudson):
- The component pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}". The BUILD_NUMBER makes each build
unique, and the SCM_REVISION is optional but can add traceability. This
even works for Git where the revision numbers are not incremental. This is
NOT committed to SCM.
- The component pipeline resolves all of the version ranges. This is NOT
committed to SCM.
- The component pipeline runs "mvn clean install"
- The component pipeline deploys the artifacts to a special "integration"
Nexus repo only used by the integration pipeline (not component pipelines).
- The component pipeline triggers the integration pipeline.
Integration Pipeline (e.g. Hudson)
- The CI server picks component versions (from mvn
versions:display-property-updates) to try to integrate and triggers an
integration run for each combination of versions.
- If using a dependency-management pom, the integration pipeline publishes a
version of it to the special "integration" Nexus repo.
- The integration pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}".
- The integration pipeline resolves all of the version ranges.
- The integration pipeline assembles and packages the deployable artifacts
using a dedicated maven project using the specified versions as command-line
version property overrides (e.g. -Dcomponent1.version=1.5.1032212).
- The integration pipeline deploys to a testing server.
- The integration pipeline runs acceptance tests.
- Upon success, the integration pipeline promotes all of the artifacts:
- It marks the integration build as promoted.
- It promotes original component pipeline CI build (e.g. using Hudson's
Build Promotion Plugin)
- It publishes the artifacts to the main nexus repository.
- It creates a tag with the integration build number in the component's
SCM.
- It updates the dependency-management pom with the component versions
used and commits it to SCM along with a tag with the integration pipeline
build number.
- Promotes any deployable artifacts.
This setup prevents version leakages since all published artifacts have
specific versions for every dependency.
This setup allows for developers to develop on trunk and automatically be
using the latest stable versions of all dependencies.
It enforces that changes are backward compatible at least relative to the
promoted downstream usage of the last promoted version of that component.
I think enhancing the versions-maven-plugin to support replacing "-SNAPSHOT"
with a given string would be helpful. I am currently using a Scala script
for this. Maybe the new goal should also resolve the version ranges, but
it's not necessary since that is already available as a goal.
I welcome any and all feedback.
Eric Pabst
Yanko, Curtis wrote:
>
> I though the idea we talked about was to re-write the POM that get's
> packaged with the actual version used from a version range?
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3406688.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
