Posts Tagged ‘merging’

Configuration Management & Customer Specials Shouldn’t Be Difficult

May 12th, 2011 by jtalbott

In the world of software development, or any product, for that matter, one of the things you may frequently be asked to do is to create a “special version” for a specific consumer.  This version might be almost identical to something you have already created, but with a few minor tweaks, or it might need to share some of the same core characteristics but have critical deviations in certain areas.

For software development – and the correspondingly essential Configuration Management of that software – I’ve seen how this can be one of the more challenging aspects of the job.  It’s not actually the creation of the “customer-special” that’s difficult though; in fact this is usually fairly trivial.  Traditional software configuration management, or SCM, systems use the branch-per-variant approach typically, and everyone knows that branching is easy.  The hard part comes when you need to manage that customer release in an ongoing fashion.  How do you upgrade them to a newer release of your product?  They probably won’t want to remain on their baseline version forever.  They’ll want to take advantage of new features and fixes, while still retaining their unique aspects.  So this brings you to… oh yeah, the actual _merge_ part!  That’s where it gets hard.  Reliably merging changes from one variant to another is a manual, error-prone, labor-intensive process.  Now I remember!  That’s why we try to limit branching.

Configuration Management with Customer Specials

Well, all of that messy, cumbersome, and problematic stuff in traditional configuration management systems utilizes a traditional architecture of branches.  Fortunately, you use AccuRev, which completely removes this obstruction and makes the management of customer specials not only easy, but elegant as well.  Let’s consider the following purely mythical scenario.  A company called ‘Stadiums’ that makes Ballparks for general use released Stadiums_Ballpark_2.0 a while back.  Stadiums had a customer who wanted a custom version of the Ballpark that had some significant differences.  For example, they had special contours to the outfield, a truly unique left-field wall, and a good old fashioned mechanical scoreboard.  Those were the changes that needed to be made which deviated from the core Ballpark.  So Stadiums made these changes in a dedicated stream, associated their work with issue records using AccuRev Change Packages, and cut the Stadiums_Ballpark_Fenway_1911 snapshot:

customer image1 Configuration Management & Customer Specials Shouldnt Be Difficult

customer image2 Configuration Management & Customer Specials Shouldnt Be Difficult

Fast forward a few years.  It’s been a while and there have been numerous advances in Stadiums’ technology.  Ballpark_4.0 has been released.  The Fenway people don’t want to purchase a brand new product, but they do want to upgrade. This is where it would get really complicated in a different configuration management tool. To boil it down, Stadiums would have to figure out what changes were made for Fenway back then, what changes have happened in their ongoing development, and intelligently merge these together.  They’d probably still want to maintain traceability and reproducibility of the “older” version of Fenway.  Some of the other tools out there make this near impossible, some slighly less onerous, but none of them make it simple.

Enter AccuRev.  Here’s what you do.  Drag the Stadiums_Ballpark_Fenway stream and drop it onto Stadiums_Ballpark_4.0.  That’s it, you’re almost done!  Because of Inheritance capabilities in AccuRev streams, all the content of Stadiums_Ballpark_4.0 will flow down into the _Fenway stream… except items that are in conflict.  Those items will be identified by AccuRev both visually and with status flags, and you will be able to deal with them quickly and appropriately.

customer image3 Configuration Management & Customer Specials Shouldnt Be Difficult

In our example, Stadiums developer llucchino has worked on the greenMonster.wall file and replaced class Netting with class monsterSeats.  So this file automatically becomes (overlap) in the _Fenway stream and can be merged.  There are more teams in the league so the scoreboard.mechanical file has been updated to change various properties.  This also is in (overlap) status.  But the contours of the outfield haven’t been updated at all, so despite that file being a custom modification for _Fenway, AccuRev intelligently knows that it doesn’t even need to be merged.  All other new content was automatically inherited by the stream, and so literally nothing needs to be done by the development team.

It’s that simple.  You’re done, go ahead and release Stadiums_Ballpark_Fenway_2011.  Another happy customer and it didn’t set you back many man months.  Can your configuration management tool do this?

Agile and SCM: Avoiding Agile Merge Disaster

February 22nd, 2011 by clucca

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate, and test those changes. Each team needs to be able to work on their own schedule, and if multiple teams want to work on different sized iterations, they can. In addition, they can deliver changes as necessary and on a regular basis, independent of other teams.

The problem? With a traditional SCM system, you have to merge these code changes daily for them to be of any use. You also need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, people use a single baseline or “trunk” methodology for this configuration, where changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you do not use this methodology:

  1. Delivering 2 weeks worth of changes only causes isolation among teams
  2. It’s too hard to pick out each user story as it completes from our codebase
  3. Figuring out the dependencies of those user stories is complex
  4. Being able to identify what changes came from each branch becomes impossible

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. An Agile SCM system supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.