Trevor -
My organization is facing this exact same concern. We are primarily
an application platform / hosted-solution company, meaning we don't
"shrinkwrap" and support multiple versions of our systems - only one
version is in production at a time. Of course, multiple branches are
undergoing testing in parallel, each with different release
timeframes, etc, and normal branch merging / management occurs at the
SCM level. Separate systems, however, have their own release schedules.
SystemA = Dev team A
-War AWar1, depends on AJar1
-War AWar2
-Jar AJar1, depends on SSJar1
SharedStuff
- Jar SSJar1
SystemB = Dev team B
- Jar Bjar1, depends on SSJar1
- Jar Bjar2, depends on AJar1 **note: cross-system dependency
- War Bwar1
- Ear Bear1
etc. Organizationally speaking, we have dev teams responsible for one
system. Shared stuff is just that, shared - no particular team as
owners / maintainers.
Our current solution we're incubating is based around a "floating
snapshot" concept. We use the version "current-SNAPSHOT" in all our
trunk POMs. So far, we like it. I reiterate the fact that we don't
really care about version numbers - once a branch goes to production,
the previous branch is retired. Period. And we want to keep our
systems relatively up-to-date in the in-house code they share.
- Our CI server (CruiseControl at present) runs a 30 minute build
loop. All projects - jars and wars alike - are mavenized (m2). Souce
retrieved is tip/trunk at all times, to ensure trunk integrity.
- Our "build server" runs builds on-demand, and retrieves only
"promoted" source from our SCM. We think of these as release
candidate builds, and we create them often.
The ant scripting surrounding our mvn invocations basically mimics the
release plugin. The scripts run by our "build server" check out the
pom, inserts the CC build number, checks in a pom revision in SCM.
The CI build scripting checks back out and re-inserts "current-
SNAPSHOT" into the tip revision when triggered.
The result is that whenever CI builds run, they build trunk of
everything against trunk (current-SNAPSHOT) builds of all
dependencies, creating an early warning system. Whenever "build
server" builds run, the packaging of resultant builds include the
latest "blessed" (promoted) builds of in-house code. If large amounts
of time go between RC builds, then that project's dependencies can get
"out of date" so to speak. We're still struggling with that to be
honest.
I welcome your thoughts. I think this is a discussion that is central
to large-scale adoption of maven in the enterprise. If we need to
take this off-list I am fine with that as well.
-Scott Heaberlin
Columbia, SC
On Mar 25, 2009, at 3:10 PM, Trevor Harmon wrote:
Consider this scenario:
Alice and Bob are working independently on two different
applications, AppA and AppB. Both applications depend on an in-house
shared library, Foo, that Alice and Bob are working on together.
They have both checked out Foo's trunk and are regularly committing
changes to it.
Because Foo is undergoing heavy development, AppA and AppB depend on
Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's
AppA needs some of the features scheduled for Foo 2.2, so she
decides to perform a release of Foo 2.1 and does the usual release
procedure:
1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into
the trunk
2) Deploys Foo 2.1 to the company's internal repository
3) Tags the Foo trunk as the 2.1 release branch
4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into
the trunk
5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT
But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his
AppB. If he updates his working copy of Foo's source code, any
changes he makes to Foo will be built as a 2.2-SNAPSHOT release,
since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem
because his AppB has a dependency on 2.1-SNAPSHOT, so the next time
he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring
any changes Bob makes in Foo. He will probably waste a lot of time
debugging, at least until he happens to notice that Foo's version
has changed.
What can be done to prevent Bob's problem?
Trevor
---------------------------------------------------------------------
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]
