Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! You need to trust me on this one, SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases
• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy
• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system. Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

• Merge early and often
• Enforce a workflow for development teams to follow
• Record and have full visibility into all of the changes that were made
• Write build and compiler scripts
• Automate builds, deploys and tests
• Understand the dependencies between projects and code
• Maintain the development environment for a team
• Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At it’s core, SCM answers the question “Somebody did something, how can one reproduce it?” In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!

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.

As an AccuRev blog reader, you’re welcome to attend our upcoming free webinar that will discuss the intersection of Agile development and governance:

Attend this Webinar and learn:

How Agile processes and compliance can coexist in harmony

What pragmatic ALM is and how it can help you solve today’s business challenges

How to manage multiple processes dependent on project requirements (Waterfall, Agile, etc.)

Best practices for optimizing tools and processes for both software development and release management.

When: Thursday, December 4 at 1:00 PM EST

Register: The Business Case for Pragmatic ALM: Agility with Governance

First, for all of you English majors out there, yes, the title is a deliberate play on words. My initial inclination was to use ‘wither’ instead of ‘whither’, to imply that SCM systems that still used branches were dried up and rotting legacies of a less enlightened past. But since this post is a response to a blog I read about the limits of branches, I though ‘whither’ was more appropriate, as I am really talking about the overall disposition of branches and how they should be used.

The author of “Is branching the answer?” poses several interesting and important observations about the limitations of branching as a means to push source code through a development process. My goal in this post is to show the reader how AccuRev addresses those issues.

To begin with, the author correctly notes that branches are often used to identify stages in a development process, and that merges are then used to ‘promote’ code through these branches as the code evolves. My first comment is on private branches, which AccuRev replaces with private developer workspaces. Private workspaces are essentially full SCM environments on a developer desktop, as opposed to the copies that private branches in, say, Subversion are. The practical difference is then when you promote from an AccuRev workspace, merges are required only for those changes that are in conflict with existing changes in the parent stream. The general case is that promotes are clean and do not require merges at all.

The author then lists four problems with the approach of using branches to ‘automate sharing of code changes within a team’. For most file and branch based systems, I tend to agree with the author, so my comments are on how AccuRev addresses these issues:

1. It encodes the team’s process into the file history of code making it difficult to quickly adjust the process as team conditions change.

With standard branches, that is true. With AccuRev, streams represent how code flows through the system. File histories reflect the individual ancestry of files. Since streams can be easily reparented, there is nothing difficult about changing the process.

2. Using a merge to promote changes introduces the possibiliy of an incomplete or bad merge that hides its effect, namely that the code isn’t promoted, or worse additional code is injected that doesn’t belong.

Promotion is a fundamental operation in AccuRev. Code changes are designed to be pushed up the stream hierarchy, from developers, to QA, all the way up to release. The only required merges are those that arise naturally from conflicts, and AccuRev’s merge tools make it straightforward to assure that merges when required are performed accurately. There are absolutely no ‘merges that are simply code promotions’. Also, it is impossible in AccuRev for anything ‘incomplete’ to get promoted. AccuRev uses atomic transactions for all operations, so success or failure is binary.

3. It clouds the history of file changes with multiple merges that make it difficult to understand if changes have correctly been merged and makes it hard to understand what is in a build of the software.

See previous response. One additional comment – there is no magic bullet for merges. AccuRev helps you identify when a merge is required, but to my knowledge there are no tools that help you decide whether changes have been correctly merged from a semantic point of view. Put another way, AccuRev can tell you that lines 3 and 4 are in conflict and require a merge, but only a human being can know how to properly resolve the conflict. That’s why they pay us the big bucks! As for what is in a given build, atomic transactions in AccuRev and the TimeSafe architecture assure that the contents of a given stream are unambiguous at any point in time.

4. It makes it hard to promote code to software teams that don’t have a close common branch. For example, you want to merge a fix from one project to another but the only common branch is the main line and merging there will hit production before you want to.

Streams make it easy to isolate lines of development from each other, especially for this common case. There is no need for a ‘common branch’ in order to do this. You simply place the changes of interest on the change palette and select the destination stream.

As to the author’s final point about Telelogic Synergy and change set routing, I will just say that AccuRev change packages provide a logical grouping of changes that can be promoted, reverted and routed in a similar fashion.

Overall, this was a very interesting post and I congratulate the author on identifying and commenting on the problems with branches in release management.

Build management is a long-overlooked area of software development. As is often the case with underserved areas, the open source community has several good solutions. Maven is among the most interesting and functional solutions for Java developers. I had the chance to take the AccuRev-Maven m2eclipse integration out for a test drive recently. This is a recently announced integration (read the press release here if you are interested, and see my video demo here).

The integration follows the pattern of other software configuration management (SCM) integrations with m2eclipse. A backend provider interface was written to support AccuRev, and the provider was integrated into the m2eclipse environment via the SCMHandler mechanism. I used m2eclipse in conjunction with AccuBridge for Eclipse (the AccuRev-provided Team plugin) to materialize Maven projects into a new AccuRev workspace from within Eclipse, and then did some basic Maven build and AccuRev SCM operations.

To get started, I needed to install m2eclipse from Sonatype. I used the Eclipse Update Manager to do this, by creating a new remote site in Update Manager for Sonatype (http://eclipse.org/m2e/). I already had the AccuBridge for Eclipse plugin installed, also obtained via Update Manager (http://www.accurev.com/download/eclipseupdate). After restarting Eclipse, I was ready to test.

In my test environment, I had an AccuRev stream called maven_int that I had pre-loaded with (of all things) the source and test code for the Maven integration itself. My goal was to create a new AccuRev workspace based on this stream from within Eclipse that was Maven- and AccuRev-aware. To do this, I used the Eclipse Import functionality and selected the “Checkout Maven Projects from SCM” option. Since I was using AccuRev, I chose the AccuRev provider from the drop down list box. Like other integrations with Maven, AccuRev supports a URL format for specifying where to obtain code. The URL lets you specify the AccuRev user and login credentials, as well as the exact depot and stream from which to import the code. I also chose the make workspace checkout option, which tells the plugin to create an actual AccuRev workspace in a specified location.

After pressing the Finish button on the Import wizard, m2eclipse called out to AccuRev, created a new AccuRev workspace, and created new Eclipse projects (based on whatever Maven POM files were found in the maven_int stream) containing the source code. I then associated the Eclipse projects with AccuRev using the Team Share option so that I would have full access to AccuRev functionality.

Since the projects were all Maven-based, building was done by right clicking on the POM file and selecting one of the build options. To convince myself that the AccuRev functionality worked, I did some edits to a few files, saved the changes, and then used the AccuRev promote option to version that file in the AccuRev repository.

Overall, the integration worked as I expected. The installation of the plugins was fast, it was easy to materialize Maven-based projects from AccuRev, and all of the important Maven and AccuRev functionality was available in the respective plugins. If you are an AccuRev user and want to use Maven, then the combination of m2eclipse and AccuRev integrated inside of the Eclipse environment is a practical desktop tool for managing your local builds.

by Damon Poole

I think of this practice as a major guiding principle of software development. If every practice is done as though it is part of the final act of releasing the product, then you will automatically have fewer practices. Fewer practices means less chance of problems falling through the cracks until the last minute and a higher level of maturity for things that have been done multiple times.

For instance, instead of having one process for developers to build during development and another build process for release, use exactly the same one. That way, when it comes time to release, the path is well worn and the chances are better that you will be able to completely reproduce the release if and when the time comes.