On 08/11/2010 9:06 AM, Thiessen, Todd (Todd) wrote:
I think I see two points here.
1. Reproducing a problem on a particular revision.
2. Delivering a CI build to your final customer.
While somewhat related, I think it is important to distinguish these two things
in this dicussion.
The concept of snapshots I think works extremely well. True, you don't want to
be delivering snapshots to a final customer. But this is ok because it really
allows you the flexibility to always be working on the trunk. And it allows you
to do so without changing your pom everytime you build. Your developer build
is the same as your CI with respect to your pom.
Imagine trying to have a CI build while always having enough information in the pom to
point to an exact version of your dependencies? Lets say I get a feature working in my
checkout, and do a build locally before committing. The build would have to point to a
fixed version of all my dependencies. If the dependencies change while I am working,
they would have to change "on the fly".
But of course the formal CI build would also have to ensure it points to the latest fixed
version of all dependencies. It would have to modify the pom "on the fly" and
it could change to point to a more recent version of a dependency since there is time
between when I run the build in my checkout and the time I commit.
It just gets very complicated very quickly. I would rather have all revision
numbers in all jars.
I am against the idea of having an automated process massaging a snapshot and
turning it into a release. You simply run the risk of building something that
you didn't anticipate. If you want to build a release, build a formal release.
This will include ensuring that all of your transtive dependencies are also a
formal release. That way you control exactly what revision of what transitive
dependencies will be built as a release.
It also gives you a place and time to do QC and some sort of management
sign-off.
CI is not supposed to be a technique of throwing shit together and
releasing anything that does not set the server on fire.
There should still be a goal written down somewhere that says "We are
working together to get release x.y.z into production(or to a customer)."
I also prepare a list of the versions of each of the artifacts that will
make up that version. If you are reversioning all of your artifacts then
I would recommend a list of which ones will change and which ones are
not supposed to be changing. This is more common in a project that has
been around for a while where large chunks of functionality will not
change in a maintenance release or a minor enhancement release.
I would go further and pre-specify "It will use the following versions
of these third party tools unless there is an explicit management
agreement to the contrary."
I want an impact statement (verbal or written) about what has to be
tested more intensively, if we change a library. There may be a good
reason to move to the X.Y.Z version of Apache POI but I want everyone to
be aware that this change MIGHT have an impact on functions that
currently not under development so that they now require the same
acceptance tests as if they were being changed since they depend on POI
and have been tested with the old version not the new one.
Ron
Now perhaps we could automate the process of building the formal release of the
project and all of its transtive dependencies. But massaging existing snapshots
into a release I don't think would be wise.
Or maybe there is a completely different kind of architecture here that would
allow you to do this. I just don't think that it fits into the current Maven
architecture; or any other build management system for that matter.
-----Original Message-----
From: stug23 [mailto:pat.poden...@gmail.com]
Sent: Sunday, November 07, 2010 12:17 PM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven
I suspect that there is a reasonable way to adjust the builds in Maven
such
that they robustly support Continuous Delivery. I know that Jason van Zyl
has started looking at CD as well.
On the Google forum
<http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
8440681058f2db8>
Chris Hilton commented:
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.
The current Maven release plugin, as it is, was not designed to handle
the
notion of CD. So it does make sense to tailor this aspect of releasing
Maven
artifacts to better support CD.
Also a quick examination of the Maven versions plugin shows that it has
facilities to handle updating versions of projects and their
dependencies.
So it looks as if it is more a matter of adjustment of Maven build to
produce a result that aligns with CD than a matter of Maven not being
suitable for CD. I think that the main stumbling block is SNAPSHOTS
because
they inherently are not releasable -- part of the process of releasing
with
the current Maven release plugin is to fail when there are SNAPSHOT
dependencies.
Another clear requirement for any changes to Maven or its build behavior
is
that the current behavior must be maintained for the many projects that
haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
Maven build's behavior being altered through configuration (or a switch
of
some sort) to comply with the desired behavior inherent in Continuous
Delivery with respect to the release of artifacts. The major difference
would appear to be with the SNAPSHOT dependencies and the Maven release
process. Other aspects of Maven are for the most part already good as
they
are for CD.
This is an interesting challenge that I am sure is best served by a
thorough
examination by the Maven and CD experts out there.
--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
tp3245370p3254121.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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
