Archive for October, 2008

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

How AccuRev makes releasing Beta software easy

October 27th, 2008 by AccuRev

I work for a large global enterprise software company with over 500 users, that has been using AccuRev for over 4 years.

We are currently managing a Beta release of our main product line.  The management of the source code is easy thanks to AccuRev, and here’s why:

1) Stream inheritance is just plain awesome!

We manage hundreds of streams to make up our suite.  We are able to promote code up through task streams, to integration streams, to qa streams where we ship.  For the Beta, we have child streams qa.beta, and our build machines use these streams.

2) Snapshots rule!

Snapshots by definition are immutable.  So you know what you built, when you built it.  Our build process creates snapshots automatically, and we fetch code based on snapshot.  We have 100% confidence in knowing what went into a build, and our snapshots are named to a pattern i.e. <parent stream>.yyyymmddhhmmss.build<build number>.  That gives one a lot of info about a build.

3) Timelocks let you stabilize code, even if set the next day!

We built our Beta release on snapshot, and the next day we retroactively set time locks on the qa.beta streams based on build time, and we access locked them down.  Now we can finalize the Beta, and still allow other integration and qa work to happen.

In summary, if we were using a traditional branch/merge SCM, this would be a lot of work and require dedicated personnel.  Instead, we did this part time and the StreamBrowser makes is so easy to see what code is where and why.  There is no confusion with views or other techniques used by other vendors.

The AccuRev CLI – Going beyond SCM

October 1st, 2008 by AccuRev

By Ryan LaNeve, AVI-SPL

Much has been written on this blog already regarding the ease with which AccuRev allows you to tailor your development process without having to fight with your SCM software. While I could offer yet another account of how simple and straightforward it is to manage our particular process using AccuRev, instead I thought I’d take a few minutes to point out some of the things we’ve done using the tool’s command-line interface and its ability to output results formatted as XML.

Of the various tools we have created over the years, the two we find most useful are what we call “AccuLoad” and “SQL Object Scripter”. The former pulls data out of AccuRev, while the latter puts data into AccuRev. Both were developed in a matter of hours thanks to the extremely intuitive command-line interface which AccuRev provides. Let’s take a closer look at each.

We’ll start with our “SQL Object Scripter”. Anyone whose development efforts involve a database server knows how difficult it is to maintain change logs for the “code” kept within the database. There are a number of “best practices” with regards to maintaining this information within an SCM, but in our experience they are all too time-consuming and involved, which leads to one or more members of the team either forgoing the process due to time constraints or just ignoring the process all together. Maybe we’ve just become spoiled by AccuRev allowing us to work exactly the way we want and otherwise staying out of our way, but we now have a hard time following any procedure which requires us to change the way we do things.

So one day a couple of us sat down and decided to find a new solution. We felt that, at a minimum, what we really wanted was to be able to view changes over time for our database objects, such as tables, views and stored procedures. We knew that if we could just get each change into AccuRev some of our issues would immediately disappear, but we found it too difficult to require the entire team to manually create every script and then manually promote that script into our SCM. We decided that what we needed was a tool that could simply detect changes to our database objects and automatically store those changes within AccuRev. Again, thanks to the simplicity of AccuRev and its CLI, our “SQL Object Scripter” tool was born in a matter of hours. We now have a record in AccuRev of (almost) every change made to any database object we care about, which then allows to use the features of AccuRev to view the history of any object, the differences between any versions of any object and even an annotation of any object to see who is responsible for the make-up of the object. The solution consists of a few parts: a SQL Server table to store DDL change event details, with a DDL trigger on the various databases we care about. The trigger fires whenever a DDL event occurs, such as the creation or alteration of a table, view or stored procedure, and the details of the event get logged to a table. Our custom console app is then scheduled to run every few minutes and checks the table for any records. When a record is found, the console app scripts out the definition of the object to a file and then uses the AccuRev CLI to add/keep/promote the file to our “SQL Scripts” depot – whatever is appropriate depending on whether the object is brand new or pre-existing and has been changed. The AccuRev commands all run within the context of whichever user made the change in the database itself, so all of our AccuRev transactions are associated with the correct team member. While this solution is not optimal and does not provide as much traceability as having each developer maintain and promote database change scripts themselves, we have found it to be an excellent interim solution which was extremely easy to put together.

Another of our tools is the one we call “AccuLoad”. The purpose of this tool is to pull various bits of information out of AccuRev and load that information into a database. We then use the information in the database from several other applications. The tool is a console application which runs in a couple of different modes, but the primary mode is run via an AccuRev trigger. Whenever a promote happens in one of our depots, our custom trigger runs and fires up our console app, passing in a few details such as the name of the depot, the name of the stream and the transaction number of the promote. AccuLoad then takes this information and makes various calls to the AccuRev CLI to gather more details, such as which elements were included in the promote, the version numbers of each of those elements, the user who performed the promote, etc, etc… Additionally, a diff is run against any changed elements, and those details are stored in the database as well. Gathering all of this information from AccuRev was extremely simple thanks not only to the intuitive nature of the functionality exposed by the AccuRev CLI, but also thanks to the option of having the results returned as XML. While I’m sure it would have been possible to create such a tool using any SCM, I doubt we would have ever found the time to do so had we not been fortunate enough to have AccuRev as our SCM. It was, again, only a matter of hours from the time we came up with the idea for AccuLoad and the time our first promotions were being logged in our database.

Having this database detailing the activity in our SCM, we were then able to create several other tools to utilize the information, such as one we call “AccuBrowse”, seen below. This web-based application allows us to browse the database and view any transaction within any stream of any of our depots, and see who performed the promote, the comments supplied during the promote, the elements included in the promote and the differences for any changed element. I should mention that much of this functionality is probably available in the AccuRev Web Interface, though we have not actually used that tool provided by AccuRev. Ours was created a couple of years ago and suits our needs. Beyond just allowing us to browse our SCM history via a web-interface, our database also allows us to perform some analysis, such as frequency of change for elements within a specific depot or stream, which allows to keep tabs on classes within our systems which may have too much responsibility. We can even run queries against the data to find “problematic” code, such as those files most often included in promotions which cause a failed build (not that our builds ever fail, of course…).

In summary, there are a myriad of fantastic features and functionality within AccuRev which make it a great fit as an SCM for any development environment. Once you’ve got your core needs taken care of by the out-of-the-box functionality, I encourage you to explore what can be done with the provided CLI and its XML-formatted output. In our experience, if you can imagine it, you can build it with AccuRev in no time at all.

Our custom AccuBrowse application, viewing a transaction involving a SQL Server stored procedure:

 The AccuRev CLI   Going beyond SCM