This sounds promising ________________________________
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time, 600 times a day > -----Original Message----- > From: epabst [mailto:epa...@gmail.com] > Sent: Wednesday, March 02, 2011 10:25 AM > To: users@maven.apache.org > Subject: RE: Continuous Delivery and Maven > > 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 > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
