Use Case: Fixing the Broken Build

by Rob Mohr, AccuRev

In one of many travels and customer visits, I came across a very cool way that AccuRev was helping to improve the way development teams do their work. To be more specific, this group was using Change Packages integrated with the JIRA Issue Tracking system to manage changes across their various product releases. They also used CruiseControl for continuous integration that would kick off nightly builds and notify the team with the results of the build.

From what they told me, the success of builds has significantly improved since they started using AccuRev because of the ability for the developers to work in their own private workspaces where they can integrate and unit test before promoting their changes for the rest of the team. Although broken builds are, for the most part, a thing of the past, they will still occur once in a while and need to be fixed ASAP.

Here is how they do it with AccuRev

The stream structure below is a simpler view of their overall software development process, but will be sufficient to show the use case.

Promoting to the Integration Stream

To start, the 4 developers below have made changes in their workspaces that will be promoted and associated to 4 different issues.

As you can see below, the integration stream (EntSoft_Client_Int) is “aware” of which issues are active in the stream. These are the new “change packages” introduced in the stream to be included in the next nightly build.

Build Fails in the Integration Stream

The next morning, the team is notified that last nights build failed via an email notification from CruiseControl. They have also scripted CruiseControl to automatically enable a time based stream called the “Temp_Fix_Build” stream and assign the appropriate transaction number to rollback the change packages from last night.

Assign the Developer to Fix the Build

One of the developers creates a workspace on the Temp_Fix_Build and “change palettes” over each change package one at a time.  This gives them the ability to mix and match change packages together to determine which one of them is the problem.

Problem Solved

After the culprit is fixed, the repaired change package(s) are promoted back into the integration stream for all to share.

Agile Requirements Traceability with AccuRev and Rally

Today, AccuRev and Rally announced our technology partnership. You can read the press release here. Since I was part of the engineering team that did the initial proof-of-concept integration between AccuRev and Rally, I thought I’d spend few moments writing about the integration and how it helps customers connect requirements managed in Rally with code changes managed in AccuRev.

First, for those of you who prefer the movie to the book, you can view a short video demonstration that I recorded here. It highlights the main functionality of the integration.

Now to the details. Rally provides agile project management, including story and defect tracking, to assist customers in managing the rapidly changing flow of requirements and issues that are common in Agile development processes. AccuRev provides innovative stream-based SCM and integrated issue tracking to enable software process automation within the SCM tool. The integration ties AccuRev and Rally together to tighten the loop between requirements and defects, and the code changes that developers perform in order to satisfy those requirements or fix the defects.

The integration, written in Ruby and Perl, consists of three parts.

1. The integration queries AccuWork, the integrated issue tracking system that is available with AccuRev, for all ‘New’ defects. It then transfers these defects into Rally, and makes an annotation in a custom Rally field called ‘AccuWork’. This field stores the AccuWork issue ID number.

2. When developers working in AccuRev make a code change, they will promote that code to an AccuWork issue, and place the ID of the Rally defect (created in the first part of the integration) in the promote comment. The AccuRev server_post_promote trigger (written in Perl) then fires and executes another piece of Ruby code that parses the promote transaction and sends relevant information about the code change to the Rally defect specified in the promote comment. This information is entered into Rally automaticaly and shows up as a ‘Discussion’ entry on the defect. Currently the integration posts the names and version identifiers of the AccuRev files that changed, the user id of the developer who did the change, and the timestamp of the change.

3. Finally, when a developer or Product Owner using Rally sees the code change, they can set the status of the defect to ‘Fixed’. Ruby code can then be run automatically that looks for all ‘Fixed’ issues in Rally, and changes their status to ‘Fixed’ in AccuWork. It does this by looking for the custom field ‘AccuWork’ created in the first part of the integration, extracting the issue ID number, and formulating an update XML message to AccuWork instructing AccuWork to update the specified issue.

That’s pretty much it. Working in Ruby and using Rally’s Ruby REST API was very straight-forward, as was working with the AccuRev XML API for querying and updating AccuWork. The end result is an early stage integration that provides basic requirements traceability between issues in AccuWork and Rally, and the coding activities of developers. I hope that if anyone is interested they’ll view the video and let us know what other features they’d like to see, so we can add them to our backlog and to future iterations of this integration in engineering.

Why Use AccuRev for Document Management?

Let’s face it, process-centric SCM is not just about the process, code and issue tracking, it’s also about document management. Simply storing documents in a shared network space is no longer sufficient; documents related to a product release need to be versioned and tracked. We’re talking about a wide range of documents here — UML diagrams, meeting notes, functional specifications, wireframe prototypes, product plans, slide decks, planning spreadsheets, and, of course, end-user documentation from release notes to complete online help systems.

AccuRev’s stream-based, process-centric approach makes it easy to manage your product-related documents right alongside your code and issues. Add a couple of folders to your workspace — call them planning, doc, or whatever you like. Add your planning documents to the folders, and promote everything. Now your product documents are part of the stream.

• When you create a child stream for the next release, those planning documents are included automatically because of AccuRev’s built-in inheritance. Just update the documents for the new release and promote. Product managers and others can create their own workspaces where they update those documents as needed.
• Want to track general-purpose planning documents that aren’t related to a specific release? Create your child stream under the root, and store all those documents there. Create child streams and workspaces based on document evolution, not product releases.
• Want to free your product managers and technical writers from using the AccuRev client interface? Now there’s the AccuBridge for Windows Explorer (for AccuRev V4.5.4 and newer), which provides AccuRev functionality from a right-click menu in Windows Explorer, and icon decorations to indicate AccuRev status.

Documents represent knowledge; they are part of the company’s history. They provide records of decisions and the context in which those decisions were made. They show the reasons behind the implementation decisions, the backtracking, the roads not taken, and the plans for the path ahead. When these important documents are not versioned and tracked, information is lost.

Globally Distributed Developers, Under a Single Roof

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

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.

Developer Recipes: AccuRev + JIRA + Eclipse using Mylyn

Related Recipes: AccuRev + Eclipse + Ruby.

In this developer-centric recipe I am going to setup a power-tool trifecta consisting of Eclipse, JIRA, and AccuRev. I’m not talking about installing each independently. No, no, no. This recipe is going to take things one step further and configure full bidirectional integrations for a wickedly powerful, fully integrated development environment where the majority of common day-to-day development tasks can be done right within Eclipse (right picture). Integrations are the crux of setting up a best-of-breed tool strategy and if you use these three tools you definitely want them talking together (left picture). Enough chop, let’s rock.

Install Applications

Let’s start by covering the basics and installing the latest versions of all three tools.

1. Install AccuRev 4.6.x. download. Follow the install wizard. See the quick setup guide to import code and setup streams [Windows page 1 / Linux-page 13].
2. Install Eclipse 3.3.x. download. Follow the install wizard. See documentation if needed.
3. Install JIRA 3.12.x. download. Follow these instructions.

At this point, you have three independent tools installed. Developers can checkin/checkout code from AccuRev, use Eclipse to modify the source code, and track bug/feature development with JIRA. In all, not a bad setup. But toggling between all these tools just takes valuable time away from coding and there is no mashing of logically related meta-data to generate useful reports… such as:

• “Which files/lines fixed issue #1234?”
• “Was bug #5678 fixed in mainline, 2.x, and 1.x codelines?”
• “Release is this Friday. How many issues are unresolved in the QA area and who are we waiting on?”
• “Which fixes went into Release 4.5.101?”
• “If I start working on the 4.x codeline, which known fixes will I be compiling against?”

Integrate Eclipse + AccuRev

Let’s eliminate jumping between Eclipse and the AccuRev CLI or StreamBrowser GUI. Rather, why not just keep/promote/update/merge directly within Eclipse. You can install our native Eclipse plugin via the Eclipse software updater.

1. Help –> Software Updates –> Find/Install
2. Select ‘Seach for new features to install’
3. Create ‘New Remote Site’ named ‘AccuRev’ with URL http://www.accurev.com/download/eclipseupdate/32
4. Checkbox ‘AccuRev’ and select Finish

When you create a new Project, choose to “Checkout from AccuRev.” Now the Eclipse ‘Team’ menu has a sleu of AccuRev commands available for inline use and your file navigator has icons for version control status. Sweet. Note: there is an AccuRev quickstart PDF located in your Eclipse plugin directory (e.g. /opt/eclipse/plugins/com.accurev.eclipse_4.6.1.32/UsingAB4Eclipse.pdf).

Integrate Eclipse + JIRA

Have you heard of the Eclipse Mylyn project? Seriously, it’ll bring a tear to your eye. In short, Mylyn is a generic framework for ‘task management’ within Eclipse and has a number of connectors to tools like JIRA, Bugzilla, and Trac. Guess what? You can interact with JIRA directly within Eclipse. It’s sick! seriously. Once again, you can install directly from the Eclipse software updater. First install the Mylyn framework and then the JIRA connector.

1. Install Mylyn 2.0. Follow this setup guide. Basically, just like the AccuRev plugin above, create a remote updater site with this URL: http://download.eclipse.org/tools/mylyn/update/e3.3
2. Install JIRA Connector. Follow the short setup guide provided by Atlassian.

As a developer, your world just got a whole lot better. Not only can you commit/update file changes directly within AccuRev, now you can open/close/update JIRA issues all without leaving Eclipse. Nuts!

Integrate AccuRev + JIRA

The final piece to the puzzle. Wait? What does hooking AccuRev to JIRA actually mean?!

Lets take a step back. Back in the day, using one of those other traditional branch-based SCM tools, you probably entered your bug #id into the commit comment. Commit 10 files. Enter bug #1234. Commit another 7 files. Enter same bug #1234. Very loose. And you probably had some validation and reporting scripts all stacked on top to keep things (hobbled) together. At the end of the day, this was far from a ‘tight’ integration and a struggle to maintain and enforce. Answering the simple question “which files -and- lines were fixed for bug #1234” was not easy (probably impossible!).

AccuRev Change Packages. AccuRev has an out-of-the-box feature called Change Packages that natively tracks a set of files (as patches) regardless of the number of commits. Change packages are first class citizens in AccuRev. You can promote multiple times to the same change package and even remove files. The trick is to understand that a change package has a 1-to-1 relationship with… an issue! And those issues can come from JIRA. So as you work in your AccuRev workspace coding day-to-day you can promote your changes and assign them to a JIRA issue. Then make more changes and promote to the same issue. Think of it like this: creating a feature or fix may take 1 day or 100 days; 1 commit or 50 commits; Change packages don’t care. They just track the current set of files that you claim are ‘logically’ related as part of a fix or feature. That’s it! I’ll keep this short, but basically, you can now use the change package / issue as a new, first-class currency for promoting further up and/or patching those changes to other codelines! It’s very powerful. See pg 33 of our Concepts Guide for details. But I digress.

Back to the recipe. Hooking up AccuRev and JIRA means that AccuRev receives issues from JIRA and JIRA receives meta-data such as fixed files and versions for each issue. The setup requires our own connector technology called AccuBridge for JIRA. It’s pretty easy to setup and simply requires mapping JIRA fields to AccuRev fields and setting up the data synchronization. There is a well written ‘quick start’ guide to walk you through the entire setup process.

1. Install AccuBridge for JIRA. download (link half-way down). Follow the setup guide located in the download package: doc/ais4jira_quick.pdf. [Note: Additional licensing may be required]
2. Enable Change Packages. See pg 75 of the Admin Guide. Basically, you need to tell AccuRev ‘when’ to prompt users for issues, ‘which’ issues to query for, and which data columns to display in the lists. [Note: AccuRev Enterprise Edition is required]

At this point, developers are promoting file changes to JIRA issues and JIRA can report on ‘who’ fixed ‘which’ files for any given bug/feature/task. Now that’s what I call traceability!

All Together Now!

With everything hooked up, what do we have? Simple. As a developer you can do just about everything directly within Eclipse. Edit files. Commit and update changes from AccuRev. Create issues and update comments/status/fields in JIRA. And behind the scenes, the JIRA records are being annotated by AccuRev as files are promoted out of Eclipse. Eclipse is your one-stop-shop workbench for developing, tracking changes, and managing task workflow (see picture).

Next we’ll add a build tool to the mix that integrates with AccuRev, JIRA, and Eclipse… But that’s for another day. Sounds great though, doesn’t it!

/happy coding/ – dave

How Much Process is Enough? Just Enough

by Brad Hart

Hi, my name is Brad Hart and I am the Director of Technology at AccuRev, Inc. I’ve been working in the software delevelopment / process space for 10+ years. I’ve designed and supported numerous ClearCase / ClearQuest implementations both while working at IBM/Rational and as a customer at various companies. At AccuRev, I’ve been involved with countless implementations of AccuRev with our customers, everything from small to large, ISVs, Internal IT, and Embedded systems companies.

Over the years, I have seen so many different approaches for software development in all kinds of companies. One area that every company seems to struggle with is defining their process. There are many stakeholders in the development process (Developers, QA, Release Engineers, Admins, Management, etc…), and it is a difficult task to get everyone on the same page to ensure that the defined process meets the needs of everyone. One area of particular contention is the amount of process to use. I’ve worked with small companies with a handful of “cowboy” developers which had absolutely no process, and I’ve also seen the opposite end of the spectrum with so much process at large companies that it gets the nickname “pebble moving.” Neither approach works.

In the no/little process environment, developers just do what they want, where they want, and how they want. This freedom certainly seems nice for the developers. I’ve never met one yet who was yearning for more process… However, this hurts the company (including the developers) in the long run. Release Engineers have a difficult time reliably building and reproducing software, parallel development is held to a minimum, Admins lose control of the assets, Managers cannot track progress and at the end, less software is produced and what is produced is lower quality. The positive side is developers spend 100% of the time coding and 0% on process overhead. The negatives are poor software, slow delivery and regressions.

The opposite end of the spectrum is equally inefficient. Have you ever seen an issue tracking schema with 10+ tabs, 100+ fields, and a state transition workflow that can only be described using 5+ visio diagrams? I have…many times. In an effort to control each step that everyone takes, these companies suffocate their developers with way too much process. So much so that they cannot work at even close to their full efficiency. They may spend as much as 30% – 40 % of their time working within the many steps of the process and not enough time coding. From my experience, developers react to this in 2 ways. (1) They just succumb to it. They simply accept the are not working at full capacity and move on. This of course means the organization is only 60% effective and can only produce 60% as much software as the next company… (2) They rebel. A motivated developer will find a way around the process so they can be more “efficient” and get more code written. Their intentions are good, but the results are bad. This approach almost always results in disaster: broken builds, regressions, lost work, etc…

So what is the answer? Just enough process. Just enough is going to be different for each company and even each group within a company. It also is a moving target based on changes in business requirements, company growth, etc… The right thing to do is to get representatives from each stakeholder group and work together to define what all the end goals and requirements are:

• How many releases do we need to ship per year?
• How many releases at a time will we support?
• What is our patching strategy?
• Do we need to support distributed development?
• Are we working with partners or 3rd party vendors?
• Will we support customer one-offs?
• What are our testing requirements and ship criteria?

Once you have the answers to these questions, you can start working on the process. The goal behind any process design is not to have a beautiful and elegant process. The goal for the process is to facilitate all actors in the process in doing the right thing and putting up just enough guardrails to keep from accidentally doing the wrong thing. Keep each business goal in mind and think about what it will take to make sure every actor has just enough information to accurately complete their task and just enough protection in place to handle common mistakes. That’s it. Don’t go overboard. That is just as bad as not having enough process. Don’t overwhelm people with information or steps to complete a simple goal. Should someone really have to fill in 40 fields to submit a defect? I don’t think so, but I’ve seen it. Keep it simple and straightforward. Just enough process is the key.

Also, make sure the tools you are using support the processes you’ve outlined. They should be able to implement your desired process and be able to adapt to changes in your process requirements.

Adrift in a Sea of Conflicting Priorities and Assignments? Here’s a Life Preserver!

Do you ever feel like things are out of control on your project, that you are adrift in a sea of conflicting priorities and requests? Do you suddenly find out at the last minute that you are the bottleneck and everybody is breathing down your neck asking you what is taking you so long to create the moveStuff() method but you had no idea that anybody even cared about moveStuff() or that you owned it? Do you ever find yourself in the exact opposite position, wondering why Sue and Bob didn’t get their stuff done that you need and then your boss walks by while you are surfing the net waiting for Sue and Bob? And who is Bob anyway?

The solution is simple! All you need to do is get everybody to move to Project. Well, if you have somebody you can spare full-time to keep Project up to date of course. Oh and I almost forgot, you’ll need to start using a requirements tool. But that’s it really, other than integrating them all together over the weekend and of course that’s assuming you’ve already gotten a CRM tool for workflow.

There is a simpler solution. It isn’t perfect, and it doesn’t solve all problems, but it can definitely provide the following benefits:

• reduce the chaos
• increase your vision into where you are and what’s going on
• reduce the number of status and/or project management meetings
• reduce the need to provide the same information over and over again
• simplify collaboration both locally and for distributed teams
• provide a more Agile workflow

The answer is to reduce the amount of rework that you are already doing. Right now you are probably storing defects in a defect tracking system, enhancements (aka RFEs, requirements, etc) in a requirements management tool (usually Excel or Word but sometimes an actual RM tool), and if you are using a project management tool it is probably MS-Project. All three of these product areas evolved to provide different aspects of project management for different groups of people and as a result they have lots of overlap. Considering how hard it is to coordinate three different systems, why not consider standardizing on one system for most of the work? The only question is, which system?

If we are going to try to do most of our project management work in a single tool, we should first decide what the interesting activities are. I believe they are: recording enhancement requests and defects as they are gathered by marketing or reported by users, load balancing, estimated completion calculation, critical path determination, work assignment, workflow, and reporting.

First let’s consider how well suited Project is for doing most or all of these tasks. Project is good at taking a small static collection of large tasks and doing load balancing, estimated completion, and critical path determination. Thus, it is mostly used for the very narrow task of project management of enhancements.

Next let’s consider requirements management. For whatever reason, most people use Excel or Word as their requirements management tool instead of a “real” requirements management tool. Excel and Word are just not appropriate for project management.

Lastly, there is defect tracking. A defect tracking system covers the assignment, tracking, workflow and reporting of defects. There is usually a higher volume of defects than enhancements, and they are usually smaller in scope and have a more complicated and often more time critical workflow. If it works well for defects, it should work equally well for enhancements.

Based on this analysis, it makes sense to extend the project management that you are already doing with a defect tracking system to include enhancements. A generic name for something that is either a requirement, enhancement, or defect is “work item.” By using work items to track all work, it is easy to see where you are and what remains to be done. Now you can use a similar workflow for enhancements as you do for defects, for instance from newly entered, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. You can easily run a query to see which work items have their code written but do not yet have any tests. Similarly, you can see which work items are done from a coding perspective and have tests but have not yet been verified as done by QA. This will give you a much more complete view of your overall project status and progress.

Whatever you are currently using for defect tracking it will be straightforward to start getting the benefits of managing defects and enhancements together. Just add a field that indicates if a work item is a defect or an enhancement. You may need to make a few more changes to accommodate a slightly different workflow for enhancements than you have for defects, but I think you’ll find it is worth the effort. For one example of how this can work, you can take a look at how AccuRev does it using AccuWorkflow.

Build your own custom interface to AccuRev issue tracking

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?

Is Defect Tracking Dead in an Agile World?

by Damon Poole

There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost. The problem of creating a defect inventory is completely orthogonal to the user of a defect tracking system.

A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from an issue tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.