I would add the following bits of reality.
We don't use CI and a lot of the discussion makes me very happy about that.
SNAPSHOTs are important. They should be installed in the repo very
carefully.
Each SNAPSHOT release should have a functional description (verbal or
written) and some sort of warranty about its usability.
Lets say you have 2 people working on getting a portlet built and one
is building the view and the other is building the Controller and Model,
as often is the case.
There is a spec that determines the actions that the MC guy needs to
implement.
The V guy needs a SNAPSHOT from the MC guy that gives him mock data for
testing. The MC guy makes a SNAPSHOT of the MC that supports the actions
that they have agreed are needed(hopefully all of them will be mocked
but sometimes only an initial set). This SNAPSHOT is deployed.
The V guy now has a stable test environment with a known set of
functionality.
The MC guy continues his development and will codes additional real and
mock functions.
From time to time, the V and MC guy will agree to a deployment of the
MC SNAPSHOT that changes the behaviour of the V guy's tests.
MC SNAPSHOTS that do not come with a warranty or provide unannounced
changes in functionality will cause problems for the V guy.
The V guy may also deploy interim SNAPSHOTs to allow the portlet to be
incorporated into the portal for testing at that level.
The portlet integration team wants to know what the portlet is supposed
to do and not supposed to do.
Perhaps it is alright for every customer search to return "Jones
Plumbing Supplies" regardless of search criteria entered.
It completely violates the final functional specification but for the
moment it means that the SNAPSHOTs are all working as intended.
The portal team can carry on its work on navigation and page layouts
with the SNAPSHOTS but they need to know what the state of the portlet
is, since later SNAPSHOTS and the FINAL release may require a lot more
real estate than the initial SNAPSHOT of the V.
They also need to know when a new V SNAPSHOT is released, specially if
changes the size.
Uncontrolled deployment of SNAPSHOTS can not be a good thing in a
project with more than 1 person.
Identifying a particular SNAPSHOT version as a dependency is often a
good thing to allow your project to have some stability and not be
forced to incorporate a newer SNAPSHOT dependency before your code is
ready for it.
Maven is a great tool for supporting orderly and effective development
if it is used properly.
Ron
On 12/11/2010 8:24 PM, Graham Leggett wrote:
On 13 Nov 2010, at 2:37 AM, Christopher Hunt wrote:
Please correct me if I do not have this right, but in effect the
requirement is to take a snapshot release, the developer do their
testing and then, if satisfied, release it in effect by renaming the
artifact to drop the "-SNAPSHOT"? My apologies if this is an over
simplification, but if it is indeed the case then I think there is a
flaw. Just because the developer has done their testing doesn't mean
that everyone in the team has done their testing.
One of the things that needs to be kept in mind also is that SNAPSHOT
means the following:
"All bets are off. This was probably created from someone's
non-checked-in working copy. The build is definitely not repeatable,
don't even try think it is, as if you do you're fooling yourself".
Dropping the -SNAPSHOT just means mayhem.
I think the cleanest way for maven to do CD is to create a plugin that
slots in where you would normally use maven-release-plugin, and when
invoked does this:
- Checks out a pristine copy of the latest trunk or branch (or
optionally a user specified revision).
- Checks all files are checked in as maven-release-plugin does now,
fail if not.
- Sets the version number of the pom to match the revision number in
scm, taking out the SNAPSHOT.
- Runs the build.
- Runs the tests.
- Runs "mvn site"
- Runs "mvn deploy" and "mvn site-deploy"
Regards,
Graham
--
---------------------------------------------------------------------
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]
