Archive for 2008

How We Manage Continuous Integration 2.0

November 11th, 2008 by AccuRev

I work for a large software company, and we’ve used AccuRev to facilitate using a large scale distributed Continuous Integration model.

AccuRev makes this possible with the Stream approach to managing different codebases.  Developers run builds using the same build scripts used by the core team for production builds that ultimately are packaged and shipped out of Engineering.

These build scripts not only build and package and kit the product, they also run thousands of xUnit tests written to run fast and fail fast.  Developers that encounter failures immediately know where to fix the code to pass the tests.  We also use test driven development.

Each day, developers promote their changes to a task stream.  We use Scrum, so a task stream correlates in most cases to a Scrum team.  This team runs automated builds / tests at their task stream level and when stories are done and accepted and passing, promote the appropriate changes to the integration stream.

The integration stream is built every afternoon, and any test failures run during the build are quickly addressed by the team.  Our Continuous Integration software provides a failure email with the modifications made that day with AccuRev user names.  Developers can then go into AccuRev using the StreamBrowser and the Version Browser and determine the root cause.

Fixes are then promoted back to the integration stream, and the full nightly build in most cases runs successfully.  We fail all integration builds on test failure as we believe in Continuous Integration.

Each week our qa level stream is built and we repeat the same process. Developers handle the promotes, the central release team does not promote code for teams.  As code promotes up the hierarchy from task to integration to qa the frequency of broken builds, due to test errors or compilation, decreases.

This Multi-stage Continuous Integration approach is easy with AccuRev due to stream inheritence.  If you used a branch / merge solution you would need to staff a central team just to manage the commits to source control, and manage code that is “done”.

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

Free Webinar on Continuous Integration

October 31st, 2008 by jwaccurev

We had a Webinar covering Continuous Integration Using AccuRev, CruiseControl and VisualStudio.NET. Learn how to take advantage of Continuous Integration using AccuRev with CruiseControl.NET in a VisualStudio.NET environment.

Our own Jack Flynn presented, along with Ryan LaNeve, an AccuRev customer with Audio Visual Innovations, now AVI-SPL.

Ryan shows off some great stuff with users checking in code that automatically kicks off a build and even updates the product version number to reflect the latest transaction number from AccuRev. Ryan recently blogged about some of the cool things he’s done using the AccuRev command-line interface (CLI) and its ability to output results formatted as XML: The AccuRev CLI, Going Beyond SCM.

Click here to view the recorded session.

To obtain Ryan’s custom labeller for AccuRev that retrieves a stream’s highest transaction number, visit his blog at http://weblogs.asp.net/rlaneve