AccuRev CTO, Damon Poole, is the featured speaker for Nashua Scrum Club’s November meeting on the topic “Scrum and Kanban: Chocolate and Peanut Butter?” The Scrum Club is a professional organization where people can learn and apply Agile project management and advanced technical practices while giving back to the community. This event provides a great opportunity for networking and the discussion of Agile software development best practices.

Date: Thursday, November 19, 2009

Time: 6:00 PM – 8:30 PM EDT, Including a complimentary pizza dinner

Location: Nashua, NH

Topic: Scrum and Kanban: Chocolate and Peanut Butter?

By now you’ve probably heard of Kanban, the newest Agile methodology on the block. Much as Scrum and XP play well together, so do Scrum and Kanban.  In fact, all three work well together.

This session will introduce Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances. This will include: decoupling once-per iteration activities from the iteration, work-in-progress limits, and the concept of “pull.”

For more information, visit: http://nashua.scrumclub.org/

AccuRev joins with Coverity, BigVisible, Electric Cloud and VersionOne in bringing the Agile Journal Seminar Series to Waltham, MA and Newark, NJ on November 10 and 11, 2009. These seminars provide a great opportunity for attendees to learn more about Agile best practices and explore industry-leading software tools in a local forum.

The agenda includes a keynote presentation from Brian Bozzuto, BigVisible, on “Agile is More than Better, Cheaper, Faster,” as well as expert presentations on a wide variety of Agile-related topics including “Automating Agile Software Development Processes” and “The New Face of Project Management.”

For additional details and registration information on these seminars:

• Waltham, Massachusetts, November 10, 2009- http://www.accurev.com/seminar/boston20091110-7
• Newark, New Jersey, November 11, 2009 – http://www.accurev.com/seminar/newark20091111-7

AccuRev will be joining with Coverity, Electric Cloud, Enthiosys and Rally Software in bringing the upcoming Agile Journal Live Seminar to Santa Clara, CA on Thursday, November 5, 2009. This event provides a unique opportunity for participants to learn more about Agile software development best practices and explore industry-leading software tools in a local forum free of charge.

The seminar agenda includes expert presentations on a wide variety of Agile-related topics such as “Automating Agile software development processes” and “Managing Software Quality in Agile Environments.” There will also be a technology showcase featuring live demonstrations of Agile project management, build and release, change management and test solutions.

A keynote presentation from Rich Mironov, Enthiosys, on “Mitigating Risk with Agile Development” will kickoff the seminar. An attendee of a recent seminar in Fairfax, VA where this address was given said, “I came to the seminar primarily to hear Rich Mironov’s keynote address. I have read his incredibly insightful book which summarizes many years of experience in the form of colorful short stories. These “parables” serve as great teaching tools for people like me who are in a different line of business, but find the information useful nonetheless. Anyone who listens to Mr. Mironov knows that he has a special way of distilling his vast experience with fledgling companies into understandable suggestions that we all can apply,” Ken Rock, Senior Project Manager, ICF International.

For more information and registration details visit:  http://www.accurev.com/seminar/santaclara20091105-7

AccuRev will be participating in the next seminar of the Agile Journal Live Seminar Series being held in Raleigh, NC on October 28, 2009. AccuRev joins with other leading providers of Agile software development solutions including Coverity, Electric Cloud, and Rally Software in sponsoring this event which focuses on promoting Agile tools and techniques to optimize the software development process.

The agenda for the event includes expert presentations on a wide variety of Agile-related topics such as SCM best practices for Agile development and the ROI impact of Agile methods and tools. The event will also include a technology showcase featuring live demonstrations of Agile project management, build and release, change management and test solutions.

The seminar is a unique opportunity for participants to learn more about Agile best practices and explore industry-leading software tools in a local forum free of charge. For more information and registration details visit: http://www.accurev.com/seminar/raleigh20091028-7

The Agile Journal Seminar Series will be coming to the cities of Santa Clara, Boston, Newark, and Austin in the upcoming months. Stay tuned for more details.

AccuRev has announced it is now shipping the HP Quality Center 10.0 integration. With this integration, developers and quality assurance professionals can leverage AccuRev software configuration management (SCM) capabilities while optimizing their existing investment in the quality management functionality of HP Quality Center 10.0. The integration offers a solution that improves the traceability of development work and enables better application lifecycle management (ALM).

With AccuBridge for HP Quality Center 10.0 users can manage all software development assets within the same tool and maintain their HP Quality Center configuration across the integration. This new integration is easier to use with simpler setup and installation procedures and is able to synchronize customized fields eliminating the need to switch between applications.

AccuRev’s Agile SCM and software process optimization capabilities in combination with HP Quality Center offer users an effective collaborative environment that provides a firm foundation for ALM based on strong auditing, transactional, and compliance features of both systems.  For more information, contact your local AccuRev sales representative t 1-800-383-8170.

AccuRev CTO, Damon Poole, is the featured speaker for the upcoming Boston SPIN (Software Process Improvement Network) meeting on the topic “Is Agile Software Development Really any Better?” This will be an evening of Agile discussions and pizza and provides an excellent opportunity for networking and the exchange of Agile process improvement experiences.

Date: Tuesday October 20, 2009

Time: 6:00 PM – 8:00 PM EST, Including a complimentary pizza dinner

Location: Bedford, MA

Topic: Is Agile Any Better?

When considering Agile development, there are three approaches you can use: believe the hype and hope for the best, look for documented ROI studies, or find people that you trust at a company with similar circumstances that have done it successfully and learn from them. But there is another way.

This session will examine traditional and Agile development from an architectural and algorithmic perspective to show exactly how and why they work and contrast their differences and similarities. At the end of this session you will have everything you need to draw your own conclusions about the algorithms and architectures of Agile development versus traditional development.

If you are already an Agile proponent, this session will give you more material to draw on when discussing the merits of Agile with those that have not yet discovered its benefits.

For more information, visit: http://www.boston-spin.org/annual.html

AccuRev will be exhibiting in the Application Lifecycle Management Conference and Exposition, ALM Expo 2009, on Thursday, October 15. This free, virtual conference and technology showcase put on by CM Crossroads, Agile Journal and CMC Media will feature Agile best practices and ALM solutions in the current economic climate. Visitors can explore product information, view demos, and engage in live discussions with product developers online from the comforts of their home or office.

The ALM Expo 2009 agenda includes presentations from industry leaders on a wide variety of Agile and ALM-oriented processes and a keynote roundtable discussion on ALM of the new economy. Attendees will also be able to visit interactive virtual exhibit booths to explore new products and services.

Visitors to the AccuRev exhibit booth will have the opportunity to learn more about AccuRev’s SCM solution for Agile development processes as well as view demos and engage in live discussions with any questions. For more information and registration details, visit: http://www.almexpo.com

I’ve encountered a number of use cases in the field where people enjoy the use of  ‘floating’ labels.  Implemented correctly, floating labels are a good example of convention-over-configuration  usually eliminating repetitive, manual build system updates.   Implemented incorrectly, they can be a traceability curse.   In this writeup I’ll show two examples of how to implement a floating label pattern in AccuRev.

Deprecated Concept? If you’re used to using floating labels as ‘markers’ on a branch [in another CM system] for stable code or feature complete state, you’ll find that the AccuRev stream hierarchy and associated workflow is a much better solution – in some cases, eliminating the need for floating labels altogether.  In my experience, floating labels have been used because the traditional CM system didn’t support process – so you had to roll your own – ultimately leading to lots of scripting and a solution that doesn’t scale.

Stories of Misuse. Every now and then I hear stories about how an urgent quick fix or missing doc change -needed- to be included in the “release-4.0.1″ that just got labeled in source control a few days prior. In some traditional CM systems, you have the ability to commit new file changes, un-label the old version and re-label the new version. As easy as this sounds, this anti-pattern instantly breaks traceability [do your labels maintain history?] and can quickly lead to confusion as “release 4.0.1″ has multiple meanings depending on when the label was pulled, either before or after the re-label. Example. I once asked someone why they routinely re-label individual files and their answer was – “because creating a new full label takes about 30 minutes.”  Why so long? Because most CM systems label the individual files (or references) in a given configuration; the more files you have, the longer it will take to label the entire configuration.  I’ve even heard stories about creating labels (and branches!) that take upwards of an hour each run.  Unless you are using a time/txn-based CM system, labeling build events is required if you need to track and compare changes between builds over time.  If you are waiting 30-min per label, forget about the agile “10-minute” build – you haven’t even gotten to the compile step yet!

Valid Cases. In practice there are  cases where having a floating label makes sense, typically related to your build system.  Most cases have to do with marking transient build configurations.  For example, when doing nightly or continual integration builds, let the build script or CI server simply pull/poll a single label and let the developers or build engineer determine what content is bound to the label. This way, the build server can be “dumb” and just get whatever the developer or build engineer say it should have.  This eliminates the need to configure your build system with each-and-every new build label – especially painful for those build systems requiring manual edits of config xml files – ugh.

The Pattern.   Two examples are presented below showing how floating labels can be used to support continuous integration with streams.

Static Floating Label.  In this example, continuous builds are performed on the single stream App_Integration.  No need to change your CI configuration. New builds are kicked off whenever changes are  promoted [by team leads, etc] from the child project streams.

The CI/build tool is configured to monitor the single App_Integration stream.  As the configuration changes, the name of the build stream remains unchanged – hence, the App_Integration stream is the ‘floating label’.

When doing very-frequent builds (e.g. per-promote or even nightly) this pattern works well as long as you have the discipline to immediately fix any broken configurations.

Dynamic Floating Label.

In this example, individual build configurations for App_Integration are marked with snapshots.  New snapshots are created whenever changes are promoted [by team leads, etc] from child project  streams, or on schedule (e.g. Nightly).

The stream Int_Good_Build is dynamically reparented to either the latest snapshot (e.g. latest build) or reparented to an alternate (e.g. prior) snapshot representing the last known good build.  The ability to move this stream, on-demand and as needed, represents a dynamic ‘floating label’ pattern.  Simply reparent the stream, update the attached workspace and the files on disk will mirror the current release snapshot configuration.  The same pattern can be applied to production releases where internal snapshots capture detailed per-configuration changes, but the reparented floating label can represent the latest public release.

Summary. In all, I’m a big fan of creating snapshots for each build, and removing old[er] ones along the way.  There are two camps on the subject, and this will be left for another blog.  Thus, I like the visibility of knowning which snapshots have been created (implying a purpose), and having a ‘marker’ stream as a floating label (e.g. context) to identify the current build being tested and/or delivered to an Int or Test machine.   Lastly, having recent snapshots immediately available assist with debugging why the latest build is broken – diff by snapshot.  sweet.

/Happy Coding/ dave

By Wayne Blair, Senior Consulting Release Engineer and Development Facilitator

Introduction

This article describes a method to use a perl debugger on trigger scripts without advanced interprocess debugging tools.

Using a perl debugger with a V4.x server side trigger launched by the server is very difficult and encounters two known obstacles:

1. The server will fire the trigger and the debugger will run in a thread of the detached server process; the debugger will start but will probably not communicate with you. However, if you manually started the server via a shell command then the perl debugger will start, accept input from the keyboard, then you will loose contact with the debugger; it does not have exclusive access to the keyboard because it is running in the context of the detached server process. The next command you type will go to the shell, not the debugger.  It gets messy from there.
2. Debugging on your live server means another AccuRev command could launch the same trigger in debug mode and the AccuRev client that issued the command will appear to be “hung” because the server thread for that command has called the debugger.  Also, if you started the server from the shell command, you will now have two debuggers trying to communicate with you. Running two different triggers in debug mode will create madness for you and get your users very upset!

Summary

• Trigger parameter files facilitate communication between the server process and triggers.
• The AccuRev server does not provide a mechanism to preserve trigger parameter files; they are temporary and removed.
• XML is used for most trigger parameter files but some still use flat files. Study the original trigger to know how to process the format.
• Modify the trigger file to capture and preserver the trigger parameter files. There can be many parameter files per transaction. Compose the file name based upon the trigger name, sequence number, and epoch second.
• Practice continuous process improvement! Use a semaphore file to activate and deactivate the feature to capture the parameter data to a file. You will enable the feature for a few minutes to collect samples then disable it.  The semaphore allows you to reuse the feature without editing the trigger script.
• Once you have enabled the facility and have collected a few trigger parameter dump files, choose an interesting one and make a copy; the copy step is important because the trigger you are debugging will reinitialize the trigger parameter file to return data back to the server. NOTE: Some triggers expect both an XML and flat parameter files. Study the trigger to determine the correct calling arguments.
• Use the copy of the parameter file and pass it as a command line parameter to the trigger you run with a Perl debugger.
• You can now single step through your trigger.
• You must make a new copy of the original parameter file before restarting the debugging session because the file you passed into your trigger was reinitialized. You do not need to exit the debugger, just make a new copy of the trigger file before you issue the debugger “R” (restart) command.

Details

I extend AccuRev functionality to support development processes and I create complex triggers that are easier to develop with a Perl debugger; this is especially true when your triggers are manipulating issue tracking data.  The AccuRev CLI manual provides good information about the triggers but you might need subtle details that are beyond the scope of the documentation. Walking through trigger execution with a debugger gives details about the content of the parameter files and what is passed from trigger to trigger.

I am not aware of any special options to allow the AccuRev server to run Perl triggers in debug mode and my attempts to do so create an unworkable environment. Since triggers are driven by parameter files, I’ve added routines to all the triggers to collect their parameter files. Once I have a collection of interesting parameter files I can launch the trigger scripts with my own Perl debugging tool of choice instead of them being launched by the AccuRev server.  I can also inject faulty data via the parameter file for testing.

The AccuRev server creates a temporary parameter file for each trigger it is calling.  The file name will be a relative path to a temporary directory and each filename will be a sequence number. Please note that a trigger can be fired more than once for a transaction. The temporary file name does not indicate the target trigger script; the trigger name and the AccuRev command that fired the script are embedded in the parameter file.

I embrace the concept of continuous improvement so I anticipate trigger debugging will used many times over the years.  I used a semaphore file to enable and disable the parameter dump functionality to eliminate edits to the trigger scripts on the live repository.  I’ve even attached captured parameter files to issue tickets I’ve submitted to AccuRev support.

Capturing Parameter Files

The AccuRev server determines what trigger to launch then creates one or more temporary files in the cache directory of the site slice and passes a relative directory name and file name(s) in the argument list to the trigger. The server process will ensure a unique sequence number when multiple threads launch the same trigger at the same time.

The steps I use are:

1. Set up my environment:
   1. Define the semaphore file name
   2. Define a directory below the accurev root to store the trigger parameter files.
2. Immediately after the trigger has parsed the XML data, call a utility function and pass it the “hook” name and the relative path to the temporary trigger parameter file that was created by the server. The server created file name will be a sequence number.
3. The utility function will look for the semaphore file in the AccuRev root directory and will simply exit when not found. When the semaphore file is found, the function will compose a unique file name based upon
   1. The trigger “hook” name
   2. The  server supplied file name (minus the directory)
   3. The current epoch second
4. The utility function will create the trigger dump directory as needed, create the file name composed in step #3, and write the trigger parameter data to the new file.

Appendix A has an excerpt of my server_admin_trig.pl and trigger utility module. I save off the parameter file immediately after the trigger has digested the XML data.

I strive to write my perl code to be operating system agnostic. I keep my common trigger code in a perl module that resides in the accurev “bin” directory. I like to avoid external environment dependencies so I explicitly state the lib path (in an OS agnostic way) to my trigger utility module.  I do this because the “use” is a compile time directive and is processed before variables are defined.

Debugging the Trigger with the Captured Parameter File

You must make a copy of the captured trigger parameter file before you use it. Triggers re-initialize the parameter file to pass data back to the server so your captured data will be lost.

1. cd $HOME
2. cp $ACCUREV/trigDumpDir/server_admin_trig-0_0-1246634816   test.dat.org

You launch a perl debugger and pass the trigger parameter file into the script as the first command line argument. Debug to your heart’s content.

1. cd $HOME
2. cp $ACCUREV/storage/site_slice/triggers/server_admin_trig.pl    funTime.pl
3. cp test.dat.org test.dat
4. perl -d funTime.pl test.dat

NOTE:  The script will reinitialize the parameter file for output. You must copy “test.dat.org” to “test.dat” before you restart the debugging session.

Appendix A:

Server_admin_trig.pl – You can download this script here

Click to download

Trig_utils.pm – You can download this script here

Click to download

Sample of Captured Trigger Data

Below is the trigger parameter file captured from server_admin_trig.pl for a “mkdepot” command.

This is a simple example. The parameter data gets much more interesting when your objective is to mine transaction or issue tracking details.

Capture file name is: /opt/accurev/ar6060/trigDumpDir/server_admin_trig-0_0-1248023869

<triggerInput>
<depot>test10</depot>
<hook>server_admin_trig</hook>
<command>mkdepot</command>
<principal>ar6060</principal>
<ip>127.0.0.1</ip>
</triggerInput>