I would rather address the divergence during development with branches
and synchronization than be merging code after everyone has tested their
artifacts and are convinced that they are correct. This makes it hard to
get a release out or even know where you are in the release since
someone's opinion that they have tested code ready to go is not
necessarily true.
With a good SCM such as Subversion, it is easy to tell if your changes
to supporting libraries are in conflict with someone else. You have the
choice to branch the source and build your own snapshots if you do not
want to address the problem up front.
At least you know that you have a problem if 2 branches are moving
forward. With two identically named and versioned objects that may or
may not be the same, you are never sure what your state is or how much
work is required to finish.
Ron
E. Pregzt wrote:
Hi Ron,
The idea with exclusive SNAPSHOT repositories for teams is an answer
to the issue when multiple teams are working on the same version
(SNAPSHOT) of the same artifact. If there'd be one SNAPSHOT repository
teams might start overriding the artifacts in the repo. I saw this in
previous organization I worked for and that led to completely random
unexpected test failures and even compilation errors when API had
changed.
Cheers,
E. Pregzt
On Mon, Feb 15, 2010 at 3:17 PM, Ron Wheeler
<[email protected]> wrote:
You didn't mention a SCM explicitely but it appears that you have one. That
is essential.
We have just started using SNAPSHOTs and Nexus and it is a great idea.
Whether you deploy SNAPSHOTs automatically or manually probably does not
make much difference provided everyone follows the rules.
I am a little unclear on the need to separate SNAPSHOT repositories. I would
try to make sure that the libraries and projects are sufficiently granular
so that
teams can be perfectly clear about who is doing what to each artifact so
that merging is done in the SCM as the code is developed rather than
afterwards once each team completes the testing. Having 2
mysharedartifact-1.8-SNAPSHOT jars and trying to figure out if they are the
same from the repository side is only going to add to the confusion.
If 2 teams are working on the same artifact, they should be synchronizing
frequently or branching so that the status of each library is clear
throughout the process and if one team is using 1.8.1-SNAPSHOT and the other
team is using 1.9-SNAPSHOT, then there is going to be a step after all the
tests are done to get the libraries merged. They can both use the same Nexus
repository.
I hope that this helps.
E. Pregzt wrote:
Hi Everyone,
I was wandering what are the Maven beast practices for distributed teams
working on the same code base.
Let me flash out the structure of the teams and the structure of the code
base that I've been dealing with. The code base is organized in such a way
there is a common platform that consists several artifacts and there are
specific products that use the platform components, but also add domain
specific logic, screens and so on. There is a several teams working
in parallel on both common platform and specific products. For the
simplicity lets assume there is the Platform and products P1 and P2
streams
and four teams T1 and T2 working on product P1 and the Platform and T3 and
T4 working on product P2 and the Platform as well.
Teams are following SCRUM method and are working in 2 weeks sprints. For
each sprint period each team branches of the code and just before the and
of
the sprint there is a merge of changes to the trunk. It is important to
mention there is is a continuous integration server (Hudson) running unit
and integration tests on trunk code base. Each team has also its own CI
server that runs test on the team's branch.
The build process has been developed using Maven 2, but IMHO needs
improvement, because originally there was only single team and no branches
were made, so the development process was sequential. Currently the
biggest
problem is that artifacts are not versioned as SNAPSHOTS for the
development
time and each developer must check out all Platform code base, compile it
locally to be able to compile changes in specific product's code
(artifacts
are not being deployed in the shared company repository at the moment).
The
code of Platform has became big, so build and testing of platform is
expensive process that slows down development within the teams working on
specific products.
Here are the the ideas in regards to the process changes:
1. Introduce the SNAPSHOTS to the artifacts
2. Introduce Nexus as a company repository
3. Make Hudson to deploy artifacts into Nexus once all tests pass
3. Let each team to use its own Nexus snapshot repository
4. Make each team's Hudson to deploy snapshots into the teams private
repository once all test pass
By doing that, each team can work on their own, Hudson protects
the correctness of the artifacts being deployed into
Nexus. Distributed teams can work in parallel without interfering each
other
by for instance overriding snapshots.
Could you please validate the ideas, expand on them or possibly propose
the
alternative approaches?
Cheers,
E. Pregzt
---------------------------------------------------------------------
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]
