Posts Tagged ‘issue tracking’

Something’s A-Twitter in My Backing Stream

June 22nd, 2010 by amonty

One of the cornerstones of any successful organization is communication. On Agile teams, we often meet to share information, update one another on progress, to reflect on that progress and discuss how the process can be improved. These interactions, be they stand-up or retrospective meetings, provide this information at regular intervals. But what if you need “real-time”  information sharing?

Consider the concept of “one piece flow”, often treated as the holy grail of engineering process purists. Lean/Kanban fan boys live to talk about this at conferences, and in the isle outside my cube. The idea is that a single “workpiece” at a time moves through the workflow. In the software development process, this is rarely limited to a single item, but instead is throttled by WIP limits to minimize the bottlenecks in the process. For example, the number of items worked on by developers is limited so that the count of items designated “ready for test” is kept at a manageable level. As a tester on an agile team, I’d like to know as soon as an item is moved from the “wip/development” phase to the “test/validation” phase.

Consider the following basic stream structure -

Simple Stream Structure

In an ideal model, testers would be notified as soon as an issue is promoted from the WIP stream to the Validation stream. This model assumes that the project is utilizing AccuRev change packages to track work items as issues. Having a distinct stream for validation purposes simplifies the job of the tester. All issues that exist in this stream have been unit tested by developers, passed basic regression tests, and are ready to be explored, validated, and promoted to the next stage in the workflow.

So, how can this level of communication be achieved? AccuRev triggers! The rest of this post will demonstrate how the server post-promote trigger could be used to provide updates using arguably the king of “What’s Happening?” – Twitter.

Why use Twitter in your Backing Stream?

Why not? Sure, you could use e-mail. But who wants more e-mail? Tweet it, and let them aggregate the information for you. Team members can follow the account, or not. Pointy-haired managers that dream of pie charts and love visibility can subscribe to an RSS feed, that you don’t have to manage. Lastly, if you’re an agilista, you’re already hip and trendy, (and let’s face it, you probably  already tweeted about the awesome presentation on Lean that you saw at the latest Agile conference).

The Server Post-Promote Trigger

I am not going to go into the gory details of the AccuRev trigger system. Here’s what you need to know.

  1. The trigger can be written in whatever language you like. In this example, I use Ruby.
  2. The trigger needs to be registered with the AccuRev server, and associated with the depot for your software project.

For this exercise, I wrote a quick script called tweet_post_promote.rb. The first step is to register this script with AccuRev.

>accurev mktrig -p SoftwareProject server-post-promote-trig ~/dev/ruby/tweet_post_promote.rb

Once registered, the trigger will now fire for all promotes in the SoftwareProject depot. Let’s take a look at the contents of the script.

#!/usr/bin/env ruby

require ‘rubygems’

require ‘crack’

require ‘twitter’

ACCUREV_DIR = “/sandbox/amonty/accurev/”

ACCUREV_STORAGE = “#{ACCUREV_DIR}storage/”

ACCUREV_SITE_SLICE = “#{ACCUREV_STORAGE}site_slice/”

USER = ‘ValidationBot’

PASS = ‘password’


def load_trigger_data(file)

xml = ”

File.open(“#{ACCUREV_SITE_SLICE}#{file}”) do |f|

xml = f.read

end

Crack::XML.parse(xml)

end


def twitter_get_auth(user, pass)

httpauth = Twitter::HTTPAuth.new(user, pass)

Twitter::Base.new(httpauth)

end


def main()

hash = load_trigger_data ARGV[1]

if hash["triggerInput"]["stream1"] == “Validation” then

changePackageIssue = hash["triggerInput"]["changePackages"]["changePackageID"]

update_string = “Issue #{changePackageIssue} just promoted to stream #{hash["triggerInput"]["stream1"]}”

twitter = twitter_get_auth(USER, PASS)

twitter.update update_string

end

end

main if __FILE__ == $0

This script is very simple. It makes use of the Ruby gems crack and Twitter. Essentially, the script takes the XML trigger file (provided as ARGV[1]) and loads it into a hash. Then the script checks to see if the stream being promoted to is our Validation stream. If so, it uses the twitter gem to update the status on our ValidationBot account.

Something's a-Twitter in my backing stream

A more useful example is to provide a link to the AccuRev Web UI Issue screen.

Something's a-Twitter in My Backing Stream

This way, anyone subscribing to the feed can click on the link and open the issue in the AccuRev Web UI.

Something's A-Twitter in My Backing Stream

This is a small example of how AccuRev triggers can be used to increase communication on your team. Testers can follow the ValidationBot account and be notified via their favorite Twitter client whenever an issue is promoted to the validation stream and they need to begin work on it. This could obviously be extended to include additional information (actual file changes, for example). That is, of course, if you can fit it into 140 characters. :)

For more information on AccuRev triggers, please see the Administrator’s Guide.

Use Case: Fixing the Broken Build

November 4th, 2008 by rmohr

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.

b1 Use Case: Fixing the Broken Build

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.

2 show issues Use Case: Fixing the Broken 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.

b31 Use Case: Fixing the Broken Build

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.

b4 Use Case: Fixing the Broken Build

Problem Solved

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

b5 Use Case: Fixing the Broken Build

Agile Requirements Traceability with AccuRev and Rally

June 11th, 2008 by matthew d. laudato

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.