Sounds like something WealthFront would be doing. :)
-----Original Message----- From: epabst [mailto:epa...@gmail.com] Sent: Wed 3/2/2011 7: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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org