I don't use CI or CD, so you can take my opinions with a grain of salt
My understanding that an application that gets to a CD stage, is ready
for testing by human beings.
In order to test an application, people need to know what the system is
supposed to do.
If a person tests a search function at the CD stage and it always
returns "John Smith" regardless of criteria, this would be flagged as an
error.
At this point, I would expect that any behaviour that does not meet the
spec would require the creation of a trouble ticket.
My understanding is that CI will work very well with SNAPSHOTS.
However, a SNAPSHOT will pass all of its tests even though it may only
offer stub functions and be tested with mock data.
A SNAPSHOT passes to a "Release Candidate" when the functionality meets
the specification and it is ready to be tested with real data and will
interact with the rest of the system according to the specifications.
It makes no sense to me to allow a SNAPSHOT through a CI stage to a CD
stage.
This would create chaos in the testing group as they would be generating
all kinds of trouble tickets for nothing.
In my opinion, the use of SNAPSHOTs is essential to an organization
using CD simply to prevent the CD stage from kicking in as long as there
is a SNAPSHOT in the CI process. If you do allow SNAPSHOTs into the CD
stage, this should be a big red flag to the QA team that trouble tickets
should not be raised and that testing should be closely coordinated with
the development team to avoid wasting time and pissing off team members.
Ron
On 09/11/2010 6:16 AM, Kief wrote:
Thiessen, Todd (Todd) wrote:
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.
I don't think it's necessary for the local developer builds to be pinned to
specific versions of dependencies; pinning only needs to happen on commit,
probably as part of the CI. So the CI would pull together the latest version
of each dependency at that point in time, and make sure the information is
included in the artefact.
Thiessen, Todd (Todd) wrote:
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.
Reading through this thread, I see two unreconcilable processes for managing
the build -> release cycle. One involves running builds through CI with no
intention of releasing them to production. Call it "progressive delivery",
since you're progressively building your code to the point where you're
ready to release it. The other approach involves assuming that any build
that passes CI will be promoted to the next stage, and may eventually reach
production, i.e. "continuous delivery".
Although the two approaches are essentially unreconcilable for a given
project, I don't see any reason why Maven can't support both. The main
obstacle seems to be resistance to the validity of alternative processes.
I don't think continuous delivery requires massaging snapshots; personally I
think Maven's snapshot concept isn't useful for CD. Each CI build needs to
be treated as a release, and dependencies from other teams should only be
pulled from builds that have passed CI. Promotion of a build through the
pipeline shouldn't involve fiddling with the artefact, but should be managed
externally by whatever toolset you're using to manage the pipeline.
CD may or may not require modification to Maven and/or plugins to inject the
information (at CI) needed to rebuild it. It sounds to me that if the build
and its dependencies are all treated as releases rather than snapshots, the
information is probably in there.
Does anyone have a reason why Maven snapshots would be useful or necessary
to a project following CD?
Kief
-----Original Message-----
From: stug23 [mailto:[email protected]]
Sent: Sunday, November 07, 2010 12:17 PM
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
