Any more commentary on Continuous Delivery, or is this group gonna come to life?

[podenski]

I recently read the Continuous Delivery book and found it to contain a
lot of very useful information regarding ways to improve on software
delivery. We use Maven and Hudson for continuous integration.

In my read of the book, Maven does have some characteristics that
don't always align with the methods described in the book. For
example, Maven produces snapshots (work in progress) that are
inherently not the released version of software. So I am guessing that
it would probably work to use Maven snapshots through the Commit
Stage, but we would then need to produce a release (using the Maven
release plugin) before advancing software artifacts to the Automated
Acceptance Testing portion of the build pipeline.

If there are any ThoughtWorks or other folks experienced with this
aspect of Continuous Delivery I would welcome your feedback/comments
on what I described above, along with other ideas/suggestions on how
to best use Maven with Continuous Delivery.

[Neil Thorne]

I use maven aswell. We have the following problem with snapshots - 

* generate a snapshot after commit build

* promote snapshot to automated acceptance test env

* if success promote snapshot to manual test env

which then causes a problem. If QA now test the snapshot artefact and you then decide - "it's a good release candidate - let's release" - then strictly speaking if you perform a maven release then you'll create a new artefact which should really be tested all over again.

So at some point in the pipeline you need to switch over to the released version of the artefact.

We use the maven automated release process which is a lot slower than a plain commit build (compile, test and package). It also creates a lot of tags and branches.

So it seems like you'd create a lot of noise in your source control system if you release like this.

I'd be interested in hearing if any other maven users are doing this though. 

We're using Bamboo, but we were going to take Go for a test drive - if anything just to get a better understanding of pipelines and how they work.

[Chris Hilton]

That's something I haven't liked about the Maven release process for a
while now. Some of my thoughts on it:

1. You can choose not to use it. Just use a regular Maven build with a
hard version number. This would be analogous to how you might have
built things with something like Ant before you switched to Maven. You
don't get all the release plugin bells and whistles built in, but you
should be able to do them as you would have before, like a post-build
hook for SCM labeling, as an example. You can use a completely hard
version like "3.0", but I prefer something like "3.0.<build_number>"
or "3.0.<repo_revision>". You should be able to recreate some of the
snapshot functionality by using version ranges this way.

2. Go ahead and use it, but be mindful of what you're doing. The risk,
obviously, is that you will end up with a release artifact that
differs from the snapshot artifact. Maven helps a lot in keeping
builds the same across environments, but you'll have to be extra
careful in your custom configuration. I would also want to automate a
sanity check that would compare the release artifact to the snapshot
artifact and make sure that any differences are accounted for, such as
a different version number in the manifest. This won't work for all
cases, though.

3. In my ideal world, I would probably either extend the release
plugin or write a new one with functionality to take a snapshot
artifact and make it a release artifact, which would still introduce
slight changes but pretty mild ones. I thought I had read a feature
request or wish list about this, but can't find it now.

Hope that gives you some things to think about.

Chris

[podenski]

I was kind of thinking the same thing. Perhaps customizing/modifying
what gets done in the Maven release plugin would align the Maven
release process with the Continuous Delivery approach? Or maybe the
Maven lifecycle should be customized somehow?

I just posted the Maven user forum and referenced this posting so that
the Maven community can chime in on their impressions of how best to
combine Continuous Delivery and Maven:

<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
td3245370.html#a3245370>

[AndrewS]

@podenski:

> Maven produces snapshots (work in progress) that are inherently not the released version of software.

Only if you append "-SNAPSHOT" to the version number in the POM. From
my understanding of Maven, snapshot version numbers aren't meant for
end products, they're for when you are developing a dependency
simultaneously with the product. For example you might have a library
whose POM looks like this:

<project ...>
...
<artifactId>my-library</artifactId>
<version>2.5-SNAPSHOT</version>
...
</project>

And a product that depends on it whose POM looks like this:

<project ...>
...
<artifactId>my-product</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>my-library</artifactId>
<version>2.5-SNAPSHOT</version>
</dependency>
</dependencies>
...
</project>

The benefit of this setup is that developers working on "my-product"
will always be using the most recently deployed version of "my-
library". Whereas if the library had a static version number like
"2.5", Maven would look in its local repo and say "yep, I already have
2.5, so I won't download 2.5 from the remote repo".

However you don't want to release my-product with any snapshot
dependencies in it, otherwise you're never going to know which of
those snapshots was the one that allowed the product to pass
successfully through the deployment pipeline. So I'd suggest that
builds not be allowed to progress into the expensive part of the
pipeline (e.g. anything requiring human testers) until all the
snapshot dependencies have been replaced with released versions.

Another approach would be to avoid snapshots altogether and just
accept that my-library might have a rapidly increasing version number
(because the demands being placed on it by my-product might still be
evolving). In most cases that won't matter, because the customer won't
know or care about dependency versions, whereas product version
numbers can be subject to all sorts of marketing considerations.

Anyway, I'm experimenting with doing CD using Maven and Hudson, and
what I have set up so far is this:
1. Commit Stage: a Hudson job runs "mvn clean install" on each commit
2. Automated Acceptance Test Stage: another Hudson job downstream of
the first runs "mvn verify", which for my test web app sets up an
embedded Jetty server via Cargo, deploys the built WAR file to it,
runs some JWebUnit tests via the application's URLs (using JUnit), and
shuts down Jetty (again, via Cargo)

The bit that's missing now is that the deployment to the automated
test environment is done by Maven rather than by a repeatable
deployment "script" as recommended by the book. For example, the QA
team couldn't use "mvn verify" to pull a new instance for manual QA.
I'm working on that bit next.

I haven't used the Maven release plugin, but I'm leery about using
anything that will modify an artifact that's already passed QA. Since
each commit represents a release candidate, why not just give the
product its final intended version number in the POM (e.g. 1.0) and
identify the various RCs by their VCS revision number (assuming you're
using a VCS like SVN (and not CVS) whose revision numbers are at least
product-wide)?

[Stephen Smith]

Maven is fundamentally incompatible with Continuous Delivery, and as such workarounds are required. I highly recommend Axel Fontaine's approach: http://axelfontaine.com/blog/final-nail.html