Posts Tagged ‘configuration management’

Use Case: I went from ClearCase to AccuRev

March 5th, 2009

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

AccuRev is a 2009 Jolt Award Finalist

January 22nd, 2009

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.

Take Back Control: Using LDAP for SCM Authentication

May 15th, 2008

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.

Continuous Integration: Methods of getting change

May 14th, 2008

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?

Globally Distributed Developers, Under a Single Roof

May 7th, 2008

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 ;-)

Agile – The Soft Hum of Many Well-Intentioned Voices

April 23rd, 2008

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.

Pattern for Continuous Builds

March 5th, 2008

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. Managing CI Builds with AccuRevAs 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

Team of One Pattern

February 22nd, 2008

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.

Stream Structure for Team of One Development in AccuRev SCM

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

GNU Bash plugin for AccuRev 4.6

February 8th, 2008

I’m happy to announce the latest release of the GNU Bash programmable completion for AccuRev 4.6!

For those AccuRev users out there that know the true power of the GNU Bash shell, life just got even better.

This GNU Bash plugin has its own site at www.bash4accurev.com for downloads, announcements, documentation and user feedback (ala blog style). You can download the plugin from the download page.

The plugin requires GNU Bash 2.05+ and supports AccuRev 4.6.x. It was developed and tested using linux (Ubuntu 7.10) and GNU Bash 3.2.25.

Important note: While the plugin was developed by an AccuRev employee (me) and GNU Bash user for 10+ years, it is considered a third-party open-source plugin and is not officially supported by the folks @ AccuRev support. That being said, I’m proud of the plugin and welcome feedback and enhancement requests for the next release. You’ll find my contact information on the plugin website.

/happy tabbing/ – dave

Build your own custom interface to AccuRev issue tracking

January 30th, 2008

If I had to guess, I’d say that roughly one third of our customers are using AccuRev’s built-in issue tracking system, called AccuWork. Another third are using one of any number of 3rd party systems, and the last third aren’t linking to issue tracking at all. Those not using issue tracking I feel are missing out on one of the key advantages of software development using an Enterprise class SCM system like AccuRev, but that’s a post for another day. And those using a third party system have that tool’s interface to work with if they want to set up any customizations. So I want to focus on the group using AccuWork.

What many people aren’t aware of is that not only does AccuRev have a full featured command-line interface for SCM operations, it also has CLI operations for the issue tracking as well. Additionally, it has the flexibility of using XML and all the inherent benefits of that language. So an example of what some organizations might want to do is set up an intranet web page where various, non-SCM users can submit issue records without having to go through a specific client application. This can be a very straightforward effort using the AccuWork CLI.

Step one would be to design your web page and forms. Simple for any experienced web developer. Any desired validations and logic would be built into this web page. Step two is to merely grab the form data, translate it into the appropriate XML format, and submit it to AccuRev. Here is a sample xml structure to create an AccuWork issue record (your schema may vary):

<newIssue issueDB="Support">
  <issue>
    <status fid="3">New</status>
    <shortDescription fid="4">We want to have another issue</shortDescription>
    <productType fid="6">Receiver</productType>
    <type fid="7">enhancement</type>
    <submittedBy fid="10">3</submittedBy>
    <assignedTo fid="14">1</assignedTo>
    <foundInRelease fid="20">TP_3.5</foundInRelease>
    <dateSubmitted fid="11">1083606275</dateSubmitted>
  </issue>
</newIssue>

Lastly, you would send this xml to AccuRev using the standard CLI:

“accurev xml -l issueFromWeb.xml”

Bingo, you now have an AccuWork record created! That’s a basic example, but since AccuRev also gives you the ability to query issues and modify existing issues via XML CLI, you can start to imagine the flexibility you have for customization and specialty access.

I’m interested in hearing from development organizations about their issue tracking usage. Do you typically have a wider audience for the issue tracking side than the actual coding side? Does the previous information sound like it’s something you could make use of?