Posts Tagged ‘configuration management’

Change and Configuration Management: Is Your SCM Up to the Job?

July 14th, 2011 by clucca

One question I hear a lot is “what’s so important about change and configuration management systems? Isn’t that just another layer of software that can clog up the software development process?” The fact is, a majority of software projects fail because of poor change and configuration management and improper use of SCM systems.

So what seems to be the problem? Well, efficient software development is often muddied by the increased use of outsourced development teams spread out over a variety of geographic locations, using a mix of Agile and waterfall modeling processes, and working on parallel projects. Choosing the wrong SCM system can reduce development efficiency, lock engineers into inappropriate processes, and cause defects to ship that can cost a boatload to fix and adversely affect overall product quality and, ultimately, customer satisfaction.

The right SCM tool, however,

  • enables flexible processes for easier change and configuration management
  • stands up to demanding frequent build, test, and release cycles
  • helps improve quality while reducing the cost of the shipped product

In other words, the right SCM system, properly implemented and used, will make the entire software build, test, and release process faster, easier, and more successful. And isn’t that the whole idea?

Any good, comprehensive SCM system consists of four basic elements:

  1. Version control, which tracks changes to a file over time
  2. Build management, which enables developers to track a build’s progress and what goes into it
  3. Release management, which handles the transition from initial build to shipped product
  4. Process control, which ties it all together

The right mix of these four components will depend on the project size – more complex projects might require more build management, frequently-updated products might need more release management.

Size matters.
One of the most important aspects of efficient and effective SCM is right-sizing – making sure your SCM system is scalable to meet the size and scope of your development projects. Too often, organizations struggle with a one-size-fits-all SCM system that is simply inappropriate for the project at hand. Likewise, use scalable best practices; for example, don’t waste precious time and resources collective extensive project metrics for one-off projects – save the thorough data collecting for more complex builds, potential version updates, and product line extensions.

Managing change and configuration
All development processes, waterfall or Agile, need to handle branching, merging, and refactoring as efficiently as possible. Code often needs to be modified or revised for maintenance purposes or to facilitate emergency releases associated with defect repairs. Your SCM system needs to be able to handle branching, merging, and refactoring effectively to ensure that any fixes carry forward from maintenance releases to major future releases so that any errors or bugs don’t perpetually pop up as ongoing problems after their initial fix.

SCM Best Practices to improve your software development processes
To help you implement the ideal SCM system or improve your current one, here are eleven SCM Best Practices to aid process improvement and make your SCM as efficient and effective as possible:

  • Forget one-size-fits-all SCM
  • Design scalable Best Practices
  • Plan your SCM environment carefully
  • Ensure absolute reproducibility for all artifacts
  • Require change requests and change packages
  • Maintain private developer workspaces
  • Create and work from appropriate baselines
  • Leverage metrics for process improvement
  • Create reusable components
  • Merge and integrate as often as possible
  • Structure for distributed development

The proper SCM system, implemented well and thoroughly embraced by your development teams, can make the difference between having a wildly successful product or an error-prone disaster that sucks up time, money, and resources in ever-increasing amounts.

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?

Use Case: I went from ClearCase to AccuRev

March 5th, 2009 by AccuRev

In May of 2005, the company I worked for, Polycom, decided to switch our Software Configuration Management tool from ClearCase to AccuRev. Initially, this decision was not taken well by the developers in my business unit since they had been using Base ClearCase for several years.  However, after seeing how much easier AccuRev was to use and that it did everything that we needed for our development tasks, we became firm believers that AccuRev really is a “Best of breed” Configuration Management tool.

We evaluated a couple of CM tools before settling on AccuRev.  Among the tools we looked at were IBM Rational ClearCase UCM (which I was very familiar with), CVS, and Accurev.  CVS was being used by development teams in both offices and it was determined to be a tool that would not scale well for us.  After evaluating ClearCase UCM and AccuRev, it was decided that AccuRev was the way to go, for several reasons.  One reason Clearcase UCM did not do well was that we could not even get it to work at one of our offices that was using Linux for development (they were using 9 different types of Linux at the time).  AccuRev positively shined during this part of the evaluation by the fact that it was very easy to setup and use in a Linux environment.  Another reason and a huge advantage for AccuRev was the fact that it was very easy to use over a WAN between multiple sites (i.e., Austin TX and Andover, MA) without a mechanism like MultiSite.  The AccuRev servers that the development team in Andover used were located in Austin, TX.  For the 3 years that that I worked with our team using AccuRev, I never had any major issues using it over the network.  A third big reason was that we also did not have to pay for ClearCase MultiSite licenses which meant a big cost savings for the company.  This last reason was major factor in management choosing AccuRev over ClearCase UCM.

After selecting AccuRev as our new CM tool, we had to migrate the current source code that was in ClearCase. At the time that we were doing this, there was no migration tool to take source code in ClearCase and move it over to AccuRev. We decided to archive the existing ClearCase Version Object Bases (VOBs) and leave them as is on their current servers in the Andover, MA office.  This was determined by our management team to be the best way to start off using AccuRev.  Most of this legacy code was for really old products that had been “End of Lifed”.  So, we were not really losing much by doing this.  We then imported the latest code from the VOBs that we cared about.  The import of this source code was just brought in as flat files.   This worked out well for us and for those who wanted to keep legacy history around.

The training for using AccuRev was very short.  AccuRev sent a trainer to our office in Andover and we had 2 groups of developers (about 15 each), attend a training session that was less than 3 hours long.  One half day of training for the developers.  It was that simple.  After this training, I was available to help the user community with any questions that they had.  I do have to say, I did not spend much time at all helping fix issues related to AccuRev.  For any issues that did come up and I couldn’t help out with immediately, AccuRev Technical Support was always there to help.  For the record, I did not attend any special AccuRev Administrators Training.  AccuRev does have AccuRev Certified Engineer Training available and that was something I wanted to take.  Actually, whatever administration was needed for AccuRev took place in the Austin, TX office.  The person who did that did it a part time basis.  This is also much different than ClearCase.  I have been a full time ClearCase Administrator at several companies and that is a full time job.  When I was working with ClearCase, at least 20 and up to 30 percent of my time was spent on administrative tasks related to ClearCase.  So, I was able to devote that extra time to work on other types of things, like the install kits for our products using InstallShield.  We had been considering hiring a consultant to do that work and we ended up saving the money that we would have spent on that.

» Read more: Use Case: I went from ClearCase to AccuRev