Posts Tagged ‘change management’

« Older Entries

AccuRev is a 2009 Jolt Award Finalist

January 22nd, 2009

AccuRev is once again pleased to inform everyone that its flagship product, AccuRev, has been selected as a Jolt Award Finalist for Dr. Dobb’s 19th Annual Jolt Product Excellence Awards in the Change and Configuration Management category. 

For the past 18 years, the Jolt Product Excellence Awards have been presented annually to showcase products that have “jolted” the industry with their significance and made the task of creating software faster, easier, and more efficient. The awards presentation is sponsored by JOLT, the fabled soft drink quaffed by software developers for sustenance during project development marathons.

“The Jolt judges have selected these finalists from the nearly 300 qualified nominations that were submitted online. The submissions represent the many innovative tools available for every phase of the software development lifecycle,” said Amber Ankerholz, Jolt Award Project Manager. “This year’s finalist round was extremely competitive and we appreciate the effort all of the participants put into showcasing their products’ features for the judges.”

In the next round of the Jolt Award process, the judges will examine the finalists according to the standard criteria of audience suitability, productivity, innovation, quality, ROI, risk, and flexibility. They focus on products that are ahead of the curve, universally useful, rich in functionality or that were solutions to problems in their product space.

Winners are announced during the Jolt Awards ceremony that takes place on March 11 at SD West 2009 Conference & Expo at the Santa Clara Convention Center.

No comments »

Posted in News

Tags:

Developing in streams, releasing from streams

September 25th, 2008

By Matthew Laudato

When I read the following blog, Developing in branches, releasing from trunk about a software configuration management development process that was constrained and tortured by branches, I had an ‘aha’ moment. Actually, I had three moments. They went something like this:

1. Branches are obsolete, so why does anyone still use them?

2. People use them because they are unaware of the alternatives – specifically streams.

3. I must act quickly to save my coding comrades from any further branch related pain.

If there is a cyberspace equivalent of shouting from the rooftops, then this blog post is it. My goal is to help the author to simplify his development process, and to free him and his team from the time-wasting, error-prone, outdated branch-induced hysteria that is clearly evident in his post. OK, so maybe that last sentence was a little hysterical, but you get the point.

In the post (which I encourage you to read first), the author outlines a branch-centric process that goes something like this:

- create issues in JIRA for feature (defect, etc) work

- create a Subversion branch for each JIRA issue, named by the JIRA issue ID (eg, SUP-3452). Developers write code on these feature branches.

- create a JIRA release (for example, R4.2) and target the issues created above to this release

- create a Subversion branch (off of the ‘trunk’) with the same name ‘R4.2′.

- Write a bunch of scripts that look at the JIRA release, find all the issues for that release, look at Subversion for the branches that are named for said issues, merge these branches to the release (R4.2) branch.

- Do some testing on the R4.2 branch

- Tag the release R4.2 branch

- Release software

- Merge the R4.2 tag back into the trunk

Rinse, repeat for the next release.

For some reason, I’m reminded at this point of a character in Tom Robbins’ “Even Cowgirls Get the Blues”. The character had a little business card that he would hand to people. One one side it read, ‘I believe in everything, nothing is sacred’. On the other side it read, ‘I believe in nothing, everything is sacred’. When I think about the author’s process, one side of my brain says ‘there is nothing wrong with this process’, and almost immediately, the other side screams ‘there is everything wrong with this process’. The truth is somewhere in the middle, and it all comes down to branches.

The problem with this process is that branches get in the way. The idea of isolating features in your SCM tool is a good one. Although I don’t personally agree with the idea of dedicating an SCM construct per-feature, there are plenty of people who do. (See Stream-per-task paradigm, for example by Dave Thomas). But that’s not the point. Whether you put one feature or ten in it, a branch constrains your ability to work efficiently. Once you create a branch, it loses all contact with the outside world, most importantly, with its own history and its relationship to other branches. The author even admits jokingly that a ‘release manager’ will likely be needed to handle the merges. Ya think?

Here’s an alternative process that uses AccuRev streams:

- Create issues in JIRA as before for the desired features and fixes and assign to developers. Use AccuBridge for JIRA to sync those issues into AccuRev

- Create a stream for R4.2

- Create (or reparent existing) developer workspaces off of this stream.

- When developers finish coding, they use ‘promote to issue’ to push the code to the R4.2 stream (automatically creating a change package that associates the code changes with the JIRA issue, and automatically updating the JIRA issue with an annotation about said code changes).

At this point, the R4.2 stream contains everything that you want to release. If you decide to back out a feature, you can use the revert by change package feature to remove it from the stream. The code changes are always available in the developer’s workspace if you need to revive them in the future. Once it is time to release, you can create a snapshot of the R4.2 stream to preserve it, and then you can go about working on the next release. If R4.2 and R5.0 (The Next Big Release) are happening in parallel, you could create an R5.0 stream as a child of R4.2, so that the R5.0 stream automatically inherits all of the R4.2 changes.

The advantages are many:

- Fewer and simpler merges

- Right-sized feature isolation and management

- Inherent parallelism through code inheritence

- Fewer process steps

- Built-in automation and thus fewer opportunities for manual errors.

I could go on, but I hear the footsteps in the hallway. There are people out there who don’t want you to know about streams. “We’ve always used branches,” they’ll say. “We’re too smart to use some vendor’s solution,” others will say. I say, don’t listen to them. Fight the power. Walk right up to them and say “Why branch when you can stream?” And then go ahead and watch your team spend less time fighting with branches and merges, and more time writing features and fixes for your customers.

1 comment »

Posted in AccuRev, Best Practices, version control

Tags:

Globally Distributed Developers, Under a Single Roof

May 7th, 2008

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 ;-)

No comments »

Posted in AccuRev, Agile, SCM Resources

Tags:

A Few Good AccuRevvers

February 14th, 2008

James from AccuRev: You want answers?

Tom the CC User: I think I’m entitled to them.

James from AccuRev: You want answers?!

Tom the CC User: I want the truth.

James from AccuRev: You can’t handle the truth! Tom, we live in a world that has complex software. And that software is going to be coded by men with computers. Who’s gonna do it? You? You, Tom with your CC? We at AccuRev have a greater responsibility than you can possibly fathom. You weep for CVS and you curse SVN. You have that luxury. You have the luxury of not knowing what we know: That the AccuRev SCM tool, while special and unique, probably saved jobs. And AccuRev’s existence, while grotesque and incomprehensible to you, saves jobs. You don’t want the truth. Because deep down, in places you don’t talk about at tradeshows, you want us for your source code. You need us for your source code. AccuRev uses words like Keep, Promote, Update…we use these words as the backbone to a life spent managing source code. You use ‘em as a punchline. We have neither the time nor the inclination to explain ourselves to a man who drinks coffee and programs under the blanket of the code management we provide, then questions the manner in which we provide it. We’d prefer you just send us a P.O. and went on your way. Otherwise, I suggest you pick up an IDE and start programming. Either way, I don’t give a damn what you think you’re entitled to.

James from AccuRev: Did you order something besides AccuRev?

Tom the CC User: I did the job that the IBM bigot made me do.

James from AccuRev: Did you order the CC?

Tom the CC User: You’re damn right I did!!!

James from AccuRev: All you did was weaken a company today, Tom. That’s all you did. You put software projects in danger. Sweet dreams, son.

4 comments »

Posted in Humor

Tags:

GNU Bash plugin for AccuRev 4.6

February 8th, 2008

I’m happy to announce the latest release of the GNU Bash programmable completion for AccuRev 4.6!

For those AccuRev users out there that know the true power of the GNU Bash shell, life just got even better.

This GNU Bash plugin has its own site at www.bash4accurev.com for downloads, announcements, documentation and user feedback (ala blog style). You can download the plugin from the download page.

The plugin requires GNU Bash 2.05+ and supports AccuRev 4.6.x. It was developed and tested using linux (Ubuntu 7.10) and GNU Bash 3.2.25.

Important note: While the plugin was developed by an AccuRev employee (me) and GNU Bash user for 10+ years, it is considered a third-party open-source plugin and is not officially supported by the folks @ AccuRev support. That being said, I’m proud of the plugin and welcome feedback and enhancement requests for the next release. You’ll find my contact information on the plugin website.

/happy tabbing/ – dave

1 comment »

Posted in AccuRev

Tags:

Evil Twins in SCM, Not Hollywood

January 24th, 2008

I keep expecting customers to ask me “Is it contagious Doc?” Or state, “but I am an only child!!!!!” What am I referring to? Evil Twins!!! Sounds menacing right? It really is not, but to a first-time user or someone who has never encountered the warning, “Name already exists in backing stream,” it can be rather perplexing.

So what exactly is an Evil Twin you ask? It is a situation where two completely separate file elements in the same directory structure have the same name. It is actually a common problem across many software configuration management (SCM) systems. So how does this happen exactly? All it takes are two well intended individuals with their own workspaces. Lets use the following scenario, User A and User B both have their own workspaces attached to the same development stream. Currently we have the following directory structure;

\.\dir1\child_dir\

with the following files already under source control:

file_a.txt

file_b.txt

As part of our software project, we also need to create one additional file:

file_c.txt.

User_A creates and adds file_c.txt to source control in the child_dir directory and promotes this newly added file into the development stream.

At the same time, User_A was creating and adding file_c.txt, User_B did the exact same steps. However, A was first to promote so in effect User_A won the race. When User_B attempts to promote his/her file_c.txt the “Name already exists” error pops up front and center and does not allow the promote to continue. Evil Twin prevention at it’s best.

AccuRev tracks an element by its eid (element identification number) and not its name. This is how an Evil Twin is detected. When User_B attempts to promote File_c.txt AccuRev knows that there is already a File_c.txt in the development stream but notices that the eid’s do not match. They are truly separate files since they were independently created and added by different users. They are Evil Twins because they look identical but are different. Really only one of the two is Evil and that is typically the file that ends up getting removed/renamed. But that is another story for another day.

So what should an AccuRev customer do when encountering this problem? Give support@accurev.com a shout and title your email “Need Evil Twin resolution help” or “Name Already exists in backing stream error.” Or you may also take a look at the AccuRev Online FAQ’s in the Customer Support Forum.

Please feel free to let me know if this helps you out!

3 comments »

Posted in Tips and Tricks

Tags:

Streams vs Branches

January 4th, 2008

by Damon Poole

From time to time, people ask, “What is a Stream?” At this point pretty much anybody associated with software development has heard of branches, but streams are a relatively new concept which is similar to, but at a higher level than branches.

Here’s my .02 on streams, coming from the AccuRev point of view. First, I think that at some level the various SCM systems which talk about “streams” are probably all trying to achieve something fairly similar. That is, a “stream of development.”

My initial exposure to “streams” was from hearing folks talk about “streams of development” independent of the SCM system that they were using (which did not have such a concept). The idea was that you had work which was towards a particular purpose, such as new development, maintenance, a team working together on a sub-project, etc. Each of these was a “stream of development.”

I have also heard the terms “codeline,” “development effort,” and “line of development” used in the same context. At the end of the day, the folks which initiate these things (managers, business people, etc) don’t really care how they are implemented, they just want to ask questions like, “How is 4.0 coming along?” and “Are all of the fixes from maintenance in the latest release?” Somebody else then translates that into the appropriate queries, which may be in terms of branches, scripts, streams, or something else.

Prior to AccuRev, I found the need to translate somewhat mystifying. ‘Why should there be any difference between the mental model of “streams” and the implementation model?’

Thus, in AccuRev, the mental model and the implementation model are the same. Streams are the basic building block of the architecture. There are no branches or labels, just streams. There are streams for releases, streams for active development, streams for end users, etc. Each stream except the root stream is defined in terms of a parent stream and inherits everything from the parent (recursively).

So, if you want to do maintenance on the 4.0 release, you would create a new stream based on 4.0 . Through inheritance, it is the same as 4.0. The definition itself is all that is required. The definition is simply “4.0_maint” is everything in “4.0″ plus all of the changes in “4.0_maint.”

Since streams are first class objects, you can act on them directly. You can assign security attributes, lock them, define other streams in terms of them, compare them directly, do queries on them without having to understand how the streams themselves are composed, etc.

For the curious, I’ve written a whitepaper which describes AccuRev’s stream architecture at an even deeper level.

And if you want to go even deeper than that, the basis of AccuRev’s streams is TimeSafe .

1 comment »

Posted in AccuRev

Tags:

Eclipse BIRT and AccuWork

December 6th, 2007

As a developer I’ve found it necessary from time to time to generate reports, especially for internal consumption. Internal reports tend to be more adhoc than those presented to clients or non-technology managers, and therefore have less time devoted to their care and feeding (and cost). While I’ve used Crystal Reports and similar tools for external reporting, most development reporting has consisted of spreadsheets and any charts that they generate in the ten minutes I have before a review meeting.

Always wanting to explore various technologies, I took the opportunity to try my hand at using the BIRT (Business Intelligence and Reporting Tools) implementation in Eclipse. If you’re interested in finding out specifics about this plugin, you can find it on the Eclipse web site. While I find the tool to have a higher learning curve than I would have expected, it shows promise for the future.

There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I’ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I’ll be describing what I’ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here.

Here at AccuRev our projects are issue oriented. We use AccuWork, which is our own tightly integrated issue management environment.

Given that, and the goals for the reporting that I defined, I had to find a way for AccuWork to communicate information that BIRT could interpret. In the past using Excel, I’d simply query issues in AccuWork and export the data into an HTML table that Excel could then read in and, with the help of pivot tables, generate the desired reports. The basic information reported included:

  1. Number of issues per developer
  2. Count of issues by priority per developer
  3. Distribution of issue resolution (Whether issues are duplicates, regressions, cancelled, deferred, etc)
  4. Distribution of issue severity (Whether issues are crashes, major implementations, cosmetic, etc)
  5. Weekday issue completed per developer
  6. Weekly Find rate vs. Fix rate
  7. Weekly average number of days to complete issues

Using this information, it is easy to see projects taper off to closure, as well gather some ideas as to how the developer workload was being distributed. Some developers cringe at this information, but I believe as long as it is used positively and to evenly distribute work, then everyone gains from reviewing this information.

With these same charts in mind, I loaded up my version of Eclipse, installed BIRT and its associated plugins, and started to figure out how to get the data into the tool. » Read more: Eclipse BIRT and AccuWork

2 comments »

Posted in Tips and Tricks

Tags:

AccuRev 4.6 preview nuggets

November 21st, 2007

As we head into Thanksgiving here in the United States, one of the things AccuRev customers have to look forward to on the other side is the upcoming 4.6 release. I thought this might be a good time to start giving some preview tidbits of 4.6 core functionality that would be of interest.

As you already know, the AccuRev StreamBrowser gives you a complete visual representation of how code is flowing through your system, not to mention dymanic control of the development process. And the “shamrock”, or default group icon, lets you know specifically what elements have been worked on at each stage. Well, with 4.6 you will now be able to see work in progress at the Issue level instead of just the file level:

4.6 preview default group by issue

This top-level visibility into what Issues have progressed to what areas of your development process further abstracts the team from needing to worry about individual elements, and instead they can concentrate on the bigger picture: “Am I going to get this release out in time?” Or “Do I not have enough of my core features past the QA gate yet?”

You can also still show the default group by file, and additionally you can view by transaction as well. Ponder this while fighting off Tryptophan induced sleep. Many of you asked for this feature and I look forward to learning how you will make use of it.

No comments »

Posted in AccuRev

Tags:

SCM Team Collaboration

October 26th, 2007

It’s amazing how many times I’m asked about how you can collaborate on sub-projects or individual features with other developers without affecting the rest of the development team.  As a matter of fact, this came up the other day, which is why I thought it would make a good post.

There are several ways that teams can collaborate in AccuRev, and depending upon what the situation is, would choose different methods.  I describe two simple scenarios where 2 developers are working on a few files together and another where several developers are teamed together to work on a sub-project.

Scenario 1: Two developers are working on the same foo.c file and must complete the work before it can be merged with the rest of the project (ie. promoted).

The great thing about private workspaces is that developers have a place where they can commit their code without impacting the rest of the team.  The code *is* placed on the server, but still remains private to the developer.  Meaning, other developers who update their workspaces will not propagate those changes into their private workspaces.

However, since the code *is* on the server, another developer can explicitly pull that version into their workspace using the “send to workspace” command (aka. “co”).  The developer can make changes and keep the file to place the new version on the server, again stored in the private workspace.  This exchange continues until the work is completed and the file can be promoted to be shared with the rest of the team.

This is typically a good method to use for collaborating on just a few files, but what if you had an entire sub-project to share with many developers.

Scenario 2: Many developers working on entire sub-project which must be completed with testing before merging with the rest of the project.

This scenario is the “bread and butter” of what AccuRev and the stream based architecture is all about.

To set this up, you simply create a stream for the sub-project from the main project stream.  The sub-project development team creates workspaces off the sub-project stream while the rest of the development group is based upon the main project stream.

With inheritance, any changes made by the main project team is automatically inherited by the sub-project team so they [sub-project team] are continuously integrating with the main development effort.  The main project team is completely unaffected by the changes made by the sub-project team.  The sub-project team can also control what changes are inherited into their stream by setting a time basis on their stream.  The time basis will only allow the changes to flow into their stream up to the time set.

Eventhough I described this scenario as a method for larger groups, it can also be used for the simple case of 2 developers working on the same file.   Streams are so architectually light weight, that they can be created and removed in a matter of seconds.

 I hope this little tip helped for those looking to collaborate.

1 comment »

Posted in Best Practices

Tags: