Posts Tagged ‘change 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.

From Merge Hell to Merge Master

March 23rd, 2011 by jsherwood

Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

  1. Denial: It’s never going to work (in a timely manner).
  2. Anger: Why do I have to do the merge?
  3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
  4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
  5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.

AccuRev is a 2009 Jolt Award Finalist

January 22nd, 2009 by AccuRev

AccuRev is once again pleased to inform everyone that its flagship product, AccuRev, has been selected as a Jolt Award Finalist for Dr. Dobb’s 19th Annual Jolt Product Excellence Awards in the Change and Configuration Management category. 

For the past 18 years, the Jolt Product Excellence Awards have been presented annually to showcase products that have “jolted” the industry with their significance and made the task of creating software faster, easier, and more efficient. The awards presentation is sponsored by JOLT, the fabled soft drink quaffed by software developers for sustenance during project development marathons.

“The Jolt judges have selected these finalists from the nearly 300 qualified nominations that were submitted online. The submissions represent the many innovative tools available for every phase of the software development lifecycle,” said Amber Ankerholz, Jolt Award Project Manager. “This year’s finalist round was extremely competitive and we appreciate the effort all of the participants put into showcasing their products’ features for the judges.”

In the next round of the Jolt Award process, the judges will examine the finalists according to the standard criteria of audience suitability, productivity, innovation, quality, ROI, risk, and flexibility. They focus on products that are ahead of the curve, universally useful, rich in functionality or that were solutions to problems in their product space.

Winners are announced during the Jolt Awards ceremony that takes place on March 11 at SD West 2009 Conference & Expo at the Santa Clara Convention Center.