SNAPSHOTs are essential (otherwise developers end up with multiple different versions of platform libs in their local repositories) and you should deploy them automatically if you want to avoid compiling the platform code. @Ron; multiple repositories are needed to distinguish the branched platform versions during the iterations (if the platform branches are not versioned, say platform-1.0-team1-sprint2-SNAPSHOT). However, you'd avoid the merging issues and over-complicating things with multiple snapshot repositories if you could stick with just the trunk version of the platform code and perhaps make one team generally responsible for making the platform changes, other teams acting as customers of the platform team.
In addition to doing what you suggested, you should automate making the releases with the release plugin. It may be a bit painful to start with as it's much more rigid process than just randomly hacking away with no regards to versions but should start paying dividends fairly quickly. I would almost insist that teams generally use only released versions of the platform code, thereby reserving SNAPSHOTs only for those times where a client team and the platform team need to co-ordinate their changes and explore the options to get the API right. If the release process is well automated, the platform team can release platform several times even during the iteration and the client teams can pick up new versions at their own pace. Disable javadocs, source code packaging, dependencies repository discovery reports for release to make it go faster - you want the release to go as fast as possible. The reality in a big software company is seldom as pretty as you'd hope it to be. If the platform code isn't very coherent and it's tightly coupled with a specific product implementation, you often need changes on both sides to make some new feature work. If a specific part of platform is highly specific to a particular product or a a group of product, consider mercilessly refactoring that part into its own common module, out of the core platform so they are not force to evolve together. The teams will selfishly choose the easiest path for them, often adding something to the platform that shouldn't be there if given a choice because they are under a constant pressure to deliver. In the long run it's better if you can resist those kind of changes and have somebody look after the evolution of the platform itself. Each product team will likely complain about the sluggish pace of the platform team (if there's a gatekeeper for the platform - and it doesn't mean they have to write the code, just participate and know what changes go into the platform code) but it's the price you have to pay to keep the platform coherent. Kalle On Mon, Feb 15, 2010 at 7:17 AM, 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]
