Hi, On 2 March 2011 16:25, epabst <epa...@gmail.com> wrote:Hi > 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.
Avoid version ranges, your build won't be repeatable. If 3rd party breaks backward compatibility between minor versions your build fails. > - 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. You can also create pom type project called bom (bill of materials). Or put all project dependencies in the dependency management section in parent pom of project. http://code.google.com/p/m4enterprise/source/browse/trunk/modular-war/modular-war-parent/pom.xml > - Use the maven-buildmetadata-plugin to capture the SCM revision and URL in > each built artifact. Avoid scm revision for binary to source traceability. Use SCM tags for tracebility, please refer to the Continous Delivery book for more details. Release management with Maven culd be one-click operation, don't worry with hundreds of tags. > > 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. Why you don't want follow Maven versioning scheme? I use shapshot versions only on DEV environment, and due to deployment pipeline after every commit, the latest version is deployed on DEV. I don't need to know which revision, it is always the latest. On QA and PROD only released and tagged versions are deployed. > - 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. Sorry, but I lost a little bit after this section ;-) > > 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 > > Good luck :-) -- Marcin m4enterprise.googlecode.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
