Posts Tagged ‘change packages’

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.

Getting the Most out of AccuRev’s Windows Explorer Integration

March 18th, 2009 by acserpa

As organizations become more advanced in their use of software configuration managment (SCM) they typically expand its use to include more than the software developers.  A common addition is around audibility and compliance of the entire development process which may require them to version more than just the source code, but also any requirements, project plans, design artifacts and documentation.  This enables the labeling of the big picture of who, what, where, why and how the software was developed.

With this expansion there are now more users of the SCM tools, many of whom have never used a version control solution before. A few examples of these new user types may be hardware designers, graphic designers, product managers, or the documentation team. These types of users are working with different types of files, and work in different tools than the traditional software developers and because of that may use version control tools in different ways.  These users may have historically created versions of files using naming convention such as:

ReleaseNotes_v1.doc, ReleaseNotes_v2.doc etc. all on their local computer.

Obviously this can be an error prone process and also a single point of failure if something were to happen to that user’s computer.  Since many of the files they work on are binary (.doc, .pdf, .ai, .dwg, .vsd etc.) they may want to work on these files in a serial mode so they don’t have to try to manually merge them when someone else makes changes to them in parallel.  So instead of the traditional use of AccuRev, taking advantage of our parallel development features, these users may want to work in exclusively locked workspaces or at least have exclusive locks on certain files to protect them.

In order to make this new type of user successful they need to use an interface that is familiar to them. With many source code control tools they may have to write scripts, manage configurations or interact with a command line interface to be able to get their work done. This type of interaction will likely not work well for these types of users, as many of them may not have the technical know how to work in those environments.  AccuRev can make this transition much more fluid and familiar for these users with the AccuBridge for Windows Explorer. This interface gives the user access to the AccuRev commands needed from within the familiarity of Windows Explorer as seen in exhibit 1.

AccuBridge for Windows Explorer

AccuBridge for Windows Explorer

» Read more: Getting the Most out of AccuRev’s Windows Explorer Integration

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