maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "E. Pregzt" <>
Subject Re: Maven2/CI Best Practices for Distributed Development
Date Tue, 16 Feb 2010 08:52:17 GMT
Hi Stephen,

Just a quick note. We do have CI for each parallel stream. I think I
explained that in the initial message to the list. There is one Hudson
build that runs for trunk and each team has its own Hudson build that
runs all the team branched from trunk and also all the net new stuff
they developed.

R. Pregzt

On Tue, Feb 16, 2010 at 8:33 AM, Stephen Connolly
<> wrote:
> On 16 February 2010 08:26, E. Pregzt <> wrote:
>> Hi Ron,
>> The merging is not a issue or I should say this is well managed issue
>> :) And yes we are using Subversion. The teams that are about to start
>> their iterations/sprints branch the code from trunk. During two week
>> cycle they develop in their branches. There is a schedule of merges
>> agreed among the team leaders, so merges are sequential. Wen it comes
>> to merge each team pulls everything up from trunk to branch and
>> stabilize on the branch (now including all the changes) and then merge
>> it down to trunk. Next team does the same, so we have a guarantee that
>> we are moving in small steps and 'absorbing' relatively small change
>> sets. Wen last time finishes the trunk Hudson kicks in and performs
>> tests, if green we release software.
> What I don't like about that technique is you do not have CI tests
> running on the branches...
> We do things somewhat differently...
> we do not deploy -SNAPSHOTs at all!
> we have a couple of hudson builds, one for each group, and then a
> final hudson build that aggregates all the trunks and pre-run's
> "versions:update-properties -DallowSnaphots=true" so that we are
> integrating the latest -SNAPSHOT versions of everything.  All our
> hudson builds just run the goal "verify"... that also ensures that
> when it comes time to release with the release plugin, our releases
> just work.
> if you always build with "install" then you can hide issues where
> people have a project which cannot be released with "release:prepare
> release:perform"
>> This is somehow off the main topic, because my main concern is not
>> merging, but how to get the best from the Maven to support the
>> distributed development.
>> Cheers,
>> E. Pregzt
>> On Mon, Feb 15, 2010 at 10:28 PM, Ron Wheeler
>> <> wrote:
>>> 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
>>>> <> 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
>>>>> make much difference provided everyone follows the rules.
>>>>> I am a little unclear on the need to separate SNAPSHOT repositories.
>>>>> 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
>>>>> 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
>>>>>> working on the same code base.
>>>>>> Let me flash out the structure of the teams and the structure of
>>>>>> code
>>>>>> base that I've been dealing with. The code base is organized in such
>>>>>> way
>>>>>> there is a common platform that consists several artifacts and there
>>>>>> specific products that use the platform components, but also add
>>>>>> 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
>>>>>> streams
>>>>>> and four teams T1 and T2 working on product P1 and the Platform and
>>>>>> and
>>>>>> T4 working on product P2 and the Platform as well.
>>>>>> Teams are following SCRUM method and are working in 2 weeks sprints.
>>>>>> each sprint period each team branches of the code and just before
>>>>>> and
>>>>>> of
>>>>>> the sprint there is a merge of changes to the trunk. It is important
>>>>>> 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
>>>>>> 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
>>>>>> 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:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message