maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "E. Pregzt" <pre...@gmail.com>
Subject Re: Maven2/CI Best Practices for Distributed Development
Date Mon, 15 Feb 2010 20:00:30 GMT
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
<rwheeler@artifact-software.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message