Archive for 2007

AccuRev is a Jolt Award 2008 Finalist

December 21st, 2007 by AccuRev

AccuRev 4.6 for ClearCase, which includes our new ClearCase Coexistence Adapter, has been selected as a Finalist in the 2008 Jolt Product Excellence Awards! James has been sharing with you some of the core new features in AccuRev 4.6 in his previous posts, such as the VersionSlider and viewing work-in-progress at the Issue level, but for a more detailed look, check out the What’s New in 4.6 Web page.

2007 was truly the year of both SCCM conversion, and co-existence (a relatively new concept). While AccuRev added significant new features to its core offering this year, enabling co-existence with leading SCCM solutions is jolting in a number of significant ways.

AccuRev is the glue that allows teams to continue using their existing SCCM infrastructure, while integrating AccuRev into new or existing projects.  This eliminates risk and potential disruption associated with a comprehensive one-time conversion, and provides freedom of choice.

AccuRev 4.6 for ClearCase enables adoption of AccuRev in previously homogenous ClearCase environments, through real-time bi-directional synchronization without rework or porting. Ultimately, these organizations will save time, money, and deliver higher quality software.

Jolt Product Excellence Winners for 2008 will be announced at the SD West conference in March.

Happy Holidays!

Always Act Like This is The Release

December 20th, 2007 by damonpoole

by Damon Poole

I think of this practice as a major guiding principle of software development. If every practice is done as though it is part of the final act of releasing the product, then you will automatically have fewer practices. Fewer practices means less chance of problems falling through the cracks until the last minute and a higher level of maturity for things that have been done multiple times.

For instance, instead of having one process for developers to build during development and another build process for release, use exactly the same one. That way, when it comes time to release, the path is well worn and the chances are better that you will be able to completely reproduce the release if and when the time comes.

How Accessible is Your Source Code?

December 19th, 2007 by jtalbott

One of the things that frightens anyone who develops code the most, or more accurately the people who are responsible for releasing or deploying that code, is the possibility that you might not have access to it within your software configuration management tool or version control system when you need it. Computers are fickle things; unless you are prepared to spend fantastic amounts of money for a truly redundant hardware/software infrastructure, there is always the chance that your system could be inaccessible when you need it most. And this doesn’t even begin to address potential network outages.

AccuRev, because of the ease of backup and restore for one thing, and the always accessible locally resident Workspaces for another, is a great insurance policy against data loss and brings developer down-time to zero. But let’s say that one of those dreaded network outages or hard disk failures occurs exactly at the time when you need to pull the latest source over to your build system for a critical release. Or imagine any kind of similar roadblock you’ve run up against in your own environment. This is yet another area where AccuRev, with just a tiny bit of prep and foresight, can save you hours, if not days, of aggravation by ensuring that you always have access to your latest “buildable” code.

How does this happen? Well, consider first the AccuRev stream paradigm where – unlike branches – there is a well defined progression of code, from the high instability of a developer’s Workspace to the “always buildable” top-level release stream. You simply have to choose the stream that you would consider as your ideal location to retrieve “offline” code from. In the following StreamBrowser, I’ve chosen the top-level “Claims_Client” stream.

offline_code

Create an AccuRev reference tree based on your chosen stream. Define the location on disk where that reference tree should populate the code to. Then, use a trigger (we provide examples with exactly this functionality) to Update that reference tree anytime a Promotion happens into this stream. The end result is that you have a specific file-system location that is *guaranteed* to have the latest and greatest code from any given stream that you want. Also, this approach is optimized because it only has to transfer changes, not the entire source tree, and there is zero manual intervention required! So in the case where the network or SCM server goes down, no problem for you; your code is happily hanging out right where you need it to be.

Some organizations are much more tolerant of this kind of scenario than others. If so, can you think of other times or examples where this kind of functionality would be helpful to you?