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.

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:

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.

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?

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.

After the import was done, developers were able to create projects and streams very easily. It did take a little while for everyone to get used to the concept of projects and streams.  I had used ClearCase UCM in the past.  So, I had no problem relating to these concepts.  For the rest of the development team, the concepts of projects and streams was very easy to get used to and made a lot of sense to them.   There was a slight learning curve for the developers with using some of the AccuRev utilities like the Version Tree Browser which looked different than the one that they were used to in ClearCase.  There were some concerns about using the AccuRev Merge Tool.  However, I attributed that to the fact that the developers may not have completely mastered the concept of merging in ClearCase, since to me it appeared to me much easier to merge source code in AccuRev than in ClearCase. The ability of the development team to quickly grasp the concepts of AccuRev saved a lot of time that would have been spent training them.  I literally was able to sit with new people on the development team and within a half hour, they were up and running with AccuRev.

Overall, I think that our use of AccuRev made our source code management much easier.  The ability to use the Graphical User Interface for most of our work was very beneficial to us. It was great to be able to create streams (or even projects) based off of a particular stream and to be able to literally see that being done on the screen, for example.  The snapshot concept also worked well for us.  It was also very easy to find the differences between build snapshots.  This helped us produce metrics for management very quickly.  We also had no issues implementing AccuRev commands into our build scripts which made our job easier.  Before we used AccuRev, we would run the builds and access CVS databases in the Austin office.  The builds had to be run at night because the builds took so long copying the code over the WAN from Austin to Andover.  After switching over to AccuRev, the fact that we could access the the AccuRev repositories in Austin directly over the WAN allowed the builds to complete much quicker than when we were doing them using CVS.  We never figured out why the copy of the CVS code took so long, but I can tell you that after switching to AccuRev, the build performance improved at least 25 to 30 percent. We could even run them during the daytime when needed, which was very beneficial to our development team.

As I mentioned above,  AccuRev Technical Support was very helpful with any questions or concerns that we had and I can never say enough good things about them.  AccuRev Tech Support always answered their phone quickly and followed up with us on anything we worked with them on.  Based on my 3 years of experience of using AccuRev, I would highly recommend it to development teams that are deciding on a Source Code Management tool.

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.

Yesterday, just for fun, I counted the number of times that I logged into a computer or website. Once to login to my PC. Once more to connect to the company network. Three times for the 3 different UNIX boxes I needed to work with. And (if you promise not to tell my boss) once to login to a popular online shopping site to cancel a book order that apparently was lost in shipping. That’s six times in a day – and a slow day at that.

All this logging in got me thinking about security, authentication and of course, software configuration management (SCM) systems. Most SCM users, unless they are in the computer security business or are otherwise paranoid, don’t think about what goes on when they type in their user name and password and press Enter. In this post, we’ll peel back the covers a bit and show how you can use LDAP as the authentication mechanism for the AccuRev SCM system.

Starting with version 4.6, AccuRev introduced the notion of a ‘custom’ authentication mechanism. If you boil it all down, there are only three things that you need to do in order to use LDAP authentication with AccuRev:

1. Tell the AccuRev server that you want to use custom authentication

2. Create users in AccuRev and in LDAP

3. Write a special AccuRev trigger that authenticates the users against an LDAP server

Let’s look at each of these in turn. First, a word of caution. As with any change to a shared production system, it is best to practice this in a safe environment. If you don’t have a spare AccuRev server laying around, you can always download the free 30 day, 5-user evaluation kit and use it to fine tune your new authentication process.

Now to the details. To tell the AccuRev server that you want to bypass the built-in authentication mechanism and use a custom method, execute the following command:

accurev authmethod custom

Next, you’ll need to create some AccuRev users. In this example, we’ll assume that you’re already using LDAP for other applications, and therefore user entries already exist in the LDAP server. A typical user in an LDAP server might look like this in LDIF format:

dn: cn=James T. Kirk,o=engineering,dc=enterprise,dc=com
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: organizationalPerson
cn: James T. Kirk
sn: jtkirk
mail: jtkirk@enterprise.com
userPassword: jtkirk

Well, typical if they happen to be the captain of the most famous starship ever! But I digress.

In AccuRev, we need to decide how this user will be represented. In this example, we’ll use the LDAP ‘commonName’ attribute, which is shown above as ‘cn’, as the AccuRev username. Here’s the command we’ll use to create that user in AccuRev:

accurev mkuser “James T. Kirk”

At this point, we have a user represented in LDAP, and that same user represented in AccuRev. All we need to do is to tell the AccuRev server how to authenticate this user via LDAP. We do this via an AccuRev trigger known as the ‘server_auth_trig’. Here is some sample code for a server_auth_trig that does just that:

use Net::LDAP;
use Net::LDAP::Util qw(ldap_error_text);
use Net::LDAP::Constant qw(LDAP_SUCCESS
            LDAP_CONNECT_ERROR
         );

use XML::Simple;
use strict 'vars';

# Server info for contacting LDAP
my $LDAP_HOST = "localhost" ;
my $LDAP_PORT = "389" ;

# We explicitly list the subtree DN to use when rewriting the incoming username as an LDAP Bind DN.
my $ldap_baseDN = "o=engineering,dc=enterprise,dc=com" ;

# Default attribute name for binding.  This attribute is concatenated
# with the incoming username and the ldap_baseDN above to form
# a Bind DN.
my $ldap_bind_attribute = "cn" ;

sub main
{
    my ($xmlinput);
    my ($command, $ip );
    my ($username, $password );
    my ($result);

    # populate array using XML::Simple routine, reading from stdin
    $xmlinput = XMLin('-', forcearray => 1, suppressempty => '');

    # set variables
    $command = $$xmlinput{'command'}[0];
    $ip = $$xmlinput{'ip'}[0];
    $username = $$xmlinput{'username'}[0];
    $password = $$xmlinput{'password'}[0];

    # First, establish a connection to the LDAP server
    my $LDAP = Net::LDAP->new($LDAP_HOST, port => $LDAP_PORT) ;
    unless ($LDAP) {
                print "Unable to connect to LDAP server on host $LDAP_HOST at port $LDAP_PORT.\n" ;
                return LDAP_CONNECT_ERROR;
    }

    # Now that we are connected, rewrite the username as a DN and attempt to bind to the server
    my $ldap_bindDN = $ldap_bind_attribute . "=" .$username . "," . $ldap_baseDN;
    print "Attempting to bind as: $ldap_bindDN\n" ;

    my $mesg = $LDAP->bind($ldap_bindDN, password => $password) ;

    # 'code' method contains any error code from the bind call
    # including success, so we return it to the caller
    my $return_code = $mesg->code;
    print "LDAP_BIND returned: $return_code\n";

    # Now unbind to free the connection
    $LDAP->unbind;

    # return the auth code to the AccuRev server
    exit ($return_code);

}

# run main routine
&main();

The main trick is to ‘rewrite’ the incoming user name in the form of an LDAP Distinguished Name, or DN, and then to use that DN and the incoming password to bind to the LDAP server. Binding is a fancy word for logging into the server. Typically this is done by providing a DN (to uniquely identify the user) and credentials (in this case, a password).

As we said earlier, we’re using a convention in this example that the incoming user name represents the ‘commonName’, or cn, attribute of the user’s LDAP entry. We then construct a string by concatenating the cn with a hard-coded base DN, the latter representing the subtree within the LDAP server where the users exist. The resulting DN in this example is:

cn=James T. Kirk,o=engineering,dc=enterprise,dc=com

which is represented in the example as the perl variable $ldap_bindDN. If the bind is successful, the trigger returns a 0, and the user is logged into AccuRev. If the bind fails, the trigger returns a non-zero code, and the user login is rejected.

There you have it. A few simple steps and you can use the industry standard LDAP mechanism to provide authentication for your AccuRev users. LDAP is used in all sorts of enterprises, from education to technology companies to government, and so is AccuRev, so we’re glad to provide a way for our customers to use this powerful and ubiquitous authentication mechanism.

Do you remember the last time you were excited to go somewhere? Were you like a kid saying, “Are we there yet? Are we there yet?”

More likely you were the one getting ‘them’ there. I’m sure it got pretty annoying to keep hearing everyone in the car moaning, wanting some sort of distraction until they got there. Maybe you even had DVD players or some other distraction so you didn’t have to hear the questions.

Now think about how you use Continuous Integration (CI) . Do you have polling of your software configuration management (SCM) tool setup? What about your other process tools, do they poll your SCM as well? Guess what, it’s the same difficult trip. You have tools burdening your working SCM (who slaves away everyday to provide for these other tools!). Every hour/minute/seconds some tool is asking your SCM tool “Are we there yet?”. Doesn’t make a lot of sense does it? Think about how many tools you have running daily. You might have multiple CI machines setup, multiple reporting machines, deployment machines all asking the same question over and over.

Quite a burden.

Now think about what your users are doing during this time. They are looking for the same distractions you might have given the kids. They are off emailing their buddies about the latest game, or watching AccuRev on Youtube (OK, maybe something even more enjoyable on YouTube). Doesn’t sound very productive, yet these automation tools were meant to do just that, increase productivity.

So what do you do? Well, a lot of tools allow you to flip the model. Push your information, don’t pull it.

If you have a large enough development group this won’t be enough. Maybe there really are code changes going into the system every minute. If you also increase the granularity of the information going to your CI and reporting tools, these tools can then decide the correct time to be a burden.

You can also reduce the frequency that you give out the same information. If you have several tools (or stages in a tool) depending on the same answer, they can get the answer from a secondary source that gets populated once.

You also want to be diligent about your monitoring. If you see a periodic load on your tools, justify the load. If it looks strange that Kevin is checking the history of a stream every minute, it probably is. If instead you saw CIMonitor as the user it would be more explicit. And it would be obvious that this should change.

And really, changes like these apply to any tool you are using. Do you really need updated reports everytime a bug is fixed? What about every day instead? If you reduce the burden on your tools to a ‘necessary’ level, then they can be further used to answer other questions.

Are we there yet?

One of the most common and problematic challenges that exists in today’s software development environments is how best to support a Globally Distributed Development organization. In ye olden days, you had the entire team co-located in the proverbial cube farm under a single monolithic roof. If Brad wanted you to review the code he just wrote, he would literally turn around in his chair, ask you to come in and look over his shoulder.

Times have definitely changed. Now, your team might be headquartered in Boston, separate R&D sites in California and London, with some specialized groups in Bangalore and Shanghai. But that’s not necessarily the hard part. Where it gets complicated is when all these developers are trying to work on the same source code at the same time. Mastership issues questions, latency, mismatched process across sites; communication problems, lack of project visibility; these things all lead to significant decrease in productivity, not to mention the chaos for those trying to manage the effort.

Enter AccuRev. Uniquely architected to support remote and geographically distributed development (GDD), there are several key built-in capabilities that make the challenges of the past disappear. Consider the following graphic:

• AccuRev’s Stream Browser presents a dynamic visual representation of the software development process that is both fundamentally tied to the source code itself as well as being flexible and enforceable. At a single glance, *anyone* working on the project anywhere knows exactly what the process in place is. (See example AccuRev annotated screen shot here from the Alaska Airlines success story).
• Geography has zero impact on your position in the process; a developer in the UK can happily use a Workspace on the same parent stream as a developer in the United States. For low bandwidth locations, AccuReplica can provide LAN-quality access without introducing the traditional mastership and latency problems of other replication solutions.
• The private nature of the Workspace means that these remote developers can “share” code while still determining when to deliver their changes publicly.

Here’s the scenario: Developer ibergman works out of London, while jtalbott works in Boston. However, they are both part of a virtual team working on ComponentC. With AccuRev, the normal boundaries and limitations of time and space – not to mention being constrained by an inadequate SCM tool – no longer apply. Okay, I took some verbal liberties with the “time and space” bit, but it’s actually not too far from the truth.

In London at noon, ibergman wraps up a section of code she’s been working on and performs a Keep, which in AccuRev is a private check-in. The change is versioned yet stays within the confines of the Workspace, not yet ready for public consumption. But ibergman wants some validation, and asks jtalbott to review her code. Using instant messaging (IM), she pings him and catches him as he’s having his first sip of coffee, probably a colombian supremo. In other tools, how would someone review a private change that was just committed on the other side of the ocean? Would they even have private commits in the first place? In AccuRev, the moment ibergman performed that Keep in London, a visual identifier is available to anyone viewing the StreamBrowser, such as to jtalbott in Boston. So jtalbott clicks on the icon, and now has immediate access to operations like View, to see the file, and Diff, to compare against any previous revision of this file:

Did I mention that jtalbott’s access to these operations is instantaneous, as soon as ibergman performs the Keep? He can even take her version and send it into his own workspace if he finds it interesting enough to want to do additional development on.

So the previously mentioned problems of mastership, latency, visibility, communication, and most importantly Process, have all gone away. No more waiting on a 24-hour turnaround to get that Shanghai code copied into the branch. No more working in the dark not knowing exactly where your piece of code fits into the puzzle. Each team can regain the responsibility of merging in their efforts into common integration points, using a well-defined process implemented with streams.

It’s a remarkably simple and elegant solution to a complex and challenging problem. Of course, it’s still not going to solve the amusing problem of both the London and Boston developers feeling like they are superior to each other, but at least now they can actually review each other’s code real-time to help figure that one out

If you listen closely, you can almost hear the soft hum of thousands of well-intended voices all intoning the mystical phrase “Agile Development” like a magical mantra that will make everything faster, better and appear more attractive.  This buzz word is coming from managers and their bosses, from PMs and VPs and CMs (Configuration Managers) and other folks with 2-letter title abbreviations, from developers and testers and even the customers.   “We must be Agile!”– so they say.

As you may have noticed, if you repeat any word or phrase long enough, it tends to lose all meaning.  Unfortunately this seems to be the case with concept of Agile Development. 

I once attended a meeting wherein a VP announced that we were going to do agile development “as of today.” There was a lot of cheering and a lot of smiling and a few hands were shaken.  And at the very back of the room, there were a few of us that sat there quietly trying mightily to conceal our shock/disbelief/cynicism and sheer apprehension at the thought of what was about to happen to us. 

You see – Agile development is more than just throwing smaller chunks of code into Production faster.  It takes planning, involvement, a solid architecture, good supporting tools – in short, A WHOLE LOT OF WORK – to make agile processes really work for you.  You can’t reap the reward without doing the work first– and if you try, all you’re going to wind up with is a great, big mess. (Not to mention a staff with their updated resumes out on DICE)

While this post is written a bit tongue-in-cheek, the message is serious.  If you want to be agile, make an investment in the process:

1)      Know your code architecture:  Having all 73,000 files in version control is not the same as KNOWING the architecture of your code. You can’t be truly agile if you don’t know the inter-dependencies of your own code. 

2)      Know your end-users wants vs. needs: Actively involve the end-users in the release scope.  This is A LOT harder than it sounds.  It takes a good relationship with the end users to separate out their desires from their actual needs, and balance the content of the releases across the two.  Building this relationship is a fundamental component of agility.

3)      Implement Tools that support Agile methods:  There is nothing agile about merging branches of code all over kingdom-come.  There is nothing agile about having to manually determine what files changed since last Friday at noon, or depending on checksum to figure it out.  Choose your tools wisely, implement them appropriately for your individual situation, and enforce the process globally across all groups, management levels and situations…and do so knowing that everything is subject to change without notice.

I highly recommend AccuRev to support agile development methodologies.  It provides a level of flexibility that I’ve never encountered in any other tool, while still enforcing process through an indelible history of every event, and user defined process criteria.

AccuRev is the ideal tool for distributed development teams, with fast remote updates, the option of full or partial updates to the development workspace, and flexible, developer-defined and controlled sharing of in-process work.

I’ve setup a lot of projects using a lot of different software configuration management tools, and AccuRev is by far and away, my favorite choice for a SCM tool – particularly when supporting agile processes.

In closing, here are some words of wisdom from an old-hat Configuration Manager:

1)      If they tell you, “Just load the CM tool on the development server for now.  We’ll find you a permanent server later” – DON’T fall for it.

2)      When a prospective employee describes their environment as “dynamic” just know in advance that’s a euphemism for “chaos.”

3)      There is no such thing as a “Planned Emergency.”

4)      If your manager says, “We’re implementing agile methodologies, and we’re buying ClearCase, because it’s the best,”….well, in that case, I’ll be seeing your updated resume on DICE…

Fran Schmidt is a veteran CM, who’s survived over a decade in the Software Configuration Management field through a combination of good humor, constant education on the newest technologies, and sheer stubbornness.

Continuous integration (CI) is all the rage these days because merging, building, and testing (shared) configurations early-and-often is a good thing. Actually, it’s a great thing! After all, finding problems sooner rather than later benefits everyone. For some, CI means simply testing compilation. (Phew… it works. Ship it! haha). For those investing time in a full test harness, CI may mean frequently executing a suite of tests at various levels (unit, functional, system) to validate functionality and identify regressions. I’ve even seen other levels of CI to include lab testing, flight testing, or even customer acceptance testing for even the smallest of changes. Regardless of how you ‘do’ CI, I’ll show how I use AccuRev for continuous integration. [Keep in mind that this is one interpretation of the subject matter]

The Pattern. The stream-based nature of AccuRev makes it very natural to define separate areas for development, integration, testing, and release. As seen in my example stream structure, I have an Integration stream as the first point of merging between individual project streams. This Integration stream is a great place to hook up a CI tool [Cruise Control, CC.NET, FinalBuilder, QuickBuild and perform nightly or per-promote builds. I prefer to create a snapshot before doing the build mainly because snapshot creation is atomic and their immutable configurations guarantee reproducibility. After creating the snapshot, I will pull the build from the snapshot name. You could build from the Integration stream directly (similar to the concept of a moving label), but creating snapshots makes it easy to visually identify with the build process and compare good builds from bad builds with simple stream diffs.  [Note: integrating any of the above mentioned CI tools is as simple as telling the build tool to pull code from a stream (by name) and then configure the build tool to execute at some frequency and notify people of the build status]

What about all those snapshots? At first, you may think, “Isn’t this going to create a gazillion snapshots? Won’t that take up a ton of (disk) space and totally clutter the stream browser view?” Well… No.

• Snapshots are cheap. Snapshots are extremely cheap server-side entities consuming ~100bytes regardless of the number of elements they label… so go nuts! Snapshots mark transaction numbers, not elements! I say, always do what you need to solve important problems and answer tough questions even if that means creating a gazillion snapshots; just be sure to organize them.
• Clean up as you go. Your CI build script (build.xml, Makefile, or doBuild.sh) can easily be instructed to remove a snapshot for every snapshot created. I’d recommend keeping around enough snapshots (say 3 to 10) to do valuable work such as comparing builds or serving as temporary baselines for developers who want to reparent. As you can see in the stream structure, AccuRev stores both active and inactive snapshots and it is easy to reactivate any snapshot if necessary (I’ve enabled the stream browser to show both; lower left corner option).
• Group snapshots. I prefer to tuck logically related sets of snapshots behind a locked pass-through stream. The pass-through stream lets me collapse them all as a group and the lock prevents the pass-through stream from being accidentally being reparented.

Tip for very-long build/test cycles. Over the past few years I’ve encountered a few shops with single build/test cycles ranging from hours to days to complete. In this case, the concept of CI is slightly challenging because the notion of frequent builds is constrained. In this case, I’d recommend setting up two distinct test phases; quick and full. The “quick phase” is a quick pass sanity test only performing tasks such as compilation and unit testing — enough to let developers know they can continue on forward progress with little concern. The “full phase” is the full blown cycle, taking hours/days to complete, that completes all levels of testing such as compilation, unit testing, functional testing, system testing, etc. I would execute the quick phase early and often while the full phase may be once per week. As an additional step, I would mark the snapshot used for the full phase with a pass-through stream for the purpose of reporting configuration diffs or letting developers reparent their project streams/workspaces on the latest known good “certified” build.

Interested in continuous integration? Perhaps you’d also be interested in multistage continuous integration…

/happy building/ – dave

We all know that AccuRev is well suited for large enterprises with teams of developers spread across the globe. But what about the crack team of one developer? You know, those of use who go solo because we know we can do it faster, better, and leaner than any contrived dream team.

Can AccuRev really work for small teams including a team of one? … You bet your ASCII it does!

In fact, I use AccuRev for my own personal projects. They happen to be AccuRev integrations, but are software projects nonetheless [Vim Plugin, GNU Bash, etc]. At this point, critics may proclaim, “For one developer, you just need to commit to trunk and label for each release.” Well… that worked OK for the first and second release, but then came the need to maintain multiple versions in parallel with patch releases (due to wholescale refactoring per major release) as well as compatibility between corresponding versions of AccuRev (since these are plugins). The compatibility matrix completely obliterates any suggestion of linear branching/labeling… so fuh-get-abot-it. Time to graduate from the traditional branch-based tools.

click to enlarge

The above picture shows my stream structure containing projects including vim-plugin and bash-completion. I’ll use the bash-completion project as a reference example to discuss my pattern of development. Even as a single developer, I found it critical to maintain a strict develop -> test -> release pattern simply because my development activities change day-to-day and typically turn into “It’s been a month since I looked at this code… time to roll up the sleeves and figure out what the heck I was thinking!” If I was forced to a single commit bucket (branch), I’d go nuts — trying to manage multiple patches, new development, updates to documentation, etc and then being forced to deliver it all because pulling out changes is about as fun as filling sandbags with a pitch fork… I’d rack my brains trying to keep it all straight especially since I have multiple projects going on concurrently!

My development process is as follows (annotated as steps 1-6 on the picture):

1. Develop – After working in my private workspace on a unit of work for days, weeks, months, I promote to the “-test “stream. Then, continue working in the private workspace on the next set of work.
2. Test – After unit testing and performing a clean-room functional test of all changes in my “-test” stream, I deem all changes “release ready” and promote to the top bash-completion stream.
3. Release Candidate — The changes in the base stream represent a configuration that is good-enough to start a new codeline. I do NOT snapshot an official release X.Y (just yet). I first create a “dash-x” line to start the codeline (e.g. bash-completion-3.x for the 3.0, 3.1, 3.2, etc versions).
4. Maintenance — In anticipation for even minor patch work, I proactively create a “-maint” stream to collect any upcoming maintenance changes based on the starting codeline. Initially, this stream will just be empty and identical in configuration to the parent ‘dash-x’ stream.
5. Official Release — At this point, I’ve immediately created the”dash-x” and “-maint” streams in succession so they are all identical in contents – namely, all containing the next release. So NOW I create my first official “dot oh” release (e.g. bash-completion-3.0).
6. Publish – With the official configuration under snapshot, I ‘pop’ the code, archive, and ship to my web server. La commedia e finite!

With the visual nature of the StreamBrowser and the ease of creating streams, managing multiple versions of multiple products with AccuRev is priceless. I use a simple, repeatable development pattern that lets me separate ongoing development work (workspaces) from upcoming changes being tested (-test stream) all separate from previous releases (dash-x) and patch development (-maint). And the best part about all of this is I can (and have, MANY times) come back to any project even months later and quickly ascertain the current state of the union — what’s in development, what’s in test, which releases are published, etc. Sweet.

Lastly, while I use this ‘dot oh’ pattern for my own projects, I even recommend it for large team development. It’s a great pattern and I hope you find it useful for your own stream management.

/happy releasing/ – dave