Archive for the ‘VSS’ Category

AiS 36: Branching, Tagging, and Promotion

Wednesday, August 15th, 2007

Listen Now

At Handmark, we use Subversion for source code control. (Check out this Subversion Quickstart at the Polymorphic Podcast.) Like most systems, it supports concepts like branching and tagging. The mechanics for each system varries, so check your documentation for those details. But a more interesting question is, how do you manage branches and tags? Where do you make your changes? What steps do you take when it's time to release?

There are essentially two schools of thought for branching: for features or for releases. We've chosen to branch for features and merge into the trunk to build a release. But another option would be to make all code changes in the trunk and branch at the point of release. You choose your policy based on where you will accept instability. If you can tolerate an unstable trunk, then branch for releases. If you need to isolate instability in the branches, then branch for features.

We've chosen to branch for features because our priorities change quickly. This strategy allows us to isolate changes away from each other, put them on hold for a time if necessary, and keep the trunk stable. All builds are performed from the trunk, so changes must be merged from their branches to the trunk prior to release.

Once we've build a release, it moves through various staging areas. A build starts in integration, moves to testing, and finally into production. At each point along the way, there are checks in place to ensure that it is ready to move forward. The pipeline is rigid in that no build may pass another on the way to production, and no build can move backward. If a build fails one of the checkpoints, it drops out of the pipeline. If we need to expidite a change to production, the build that's currently in the pipeline is dumped.

We find that this policy works best for our environment. It may or may not apply to yours. Choose the policy that fits your team, discuss it, document it, and stick to it.

The promotional model

Friday, June 29th, 2007

Yesterday I modified a Bugzilla entry to indicate that the change was ready for QA testing. QA responded that not only was the bug fixed, but it was also working in production. That's when I realized that the build that went to production the night before actually included my fix, before QA had had a chance to validate it. Our promotional tracking failed.

If you manage a live production system, you need a good set of procedures to define how changes are rolled out. It's a common problem. How do you control what changes to into production? How do you notify QA of all the bug fixes that they should be testing? How do you know what version of the software currently in QA? How do you pinpoint an issue to a particular build? Although the problem is a common one, it seems that every place I've worked has had a different solution.

The ideal solution is known as the promotional model. This is the world view whereby builds are promoted from one platform to the next. At a minimum, you need five:

  • development
  • integration
  • QA
  • staging
  • production

The purpose of these five platforms is to test different parts of the system with reasonable isolation. Programmers can test their individual features in development, and then make sure they don't break each other in integration. Meanwhile, QA is running regression tests on a stable build. The staging area is used to test the deployment process itself before it finally sees the users in production.

The promotional model forms a pipeline. A build of the software moves through this pipeline, stopping at each of the five platforms along the way. When it fails to pass the tests at a particular platform, it falls out of the pipeline and another build comes up behind it. No build proceeds to the next platform until it passes all tests at the previous platform.

The promotional model has no forks. So while it is likely that you will have different builds installed on different platforms at any given time, a build cannot pass another one in the pipeline. Unfortunately, this makes emergency releases extremely disruptive. If QA is testing the new features when you find a problem in production, you have to take the feature build out of the pipeline to allow the fix build to flow through. That means that QA has to stop testing new features in order to perform a regression test on the fix. I've been on teams that have tried to short-circuit this process to their own detriment. Just take it as a given that you will disrupt QA testing to push an emergency fix.

The promotional model is not the same as source control, but they do touch each other. The source control system is allowed to branch. This is necessary when a change needs to be applied to a build that occurred in the past. So while it is not possible for a build to pass another one within the pipeline, it is possible to push through a build from an older branch.

The promotional model is not the same as bug tracking, but they do touch each other. A bug is opened against the particular build currently installed on a particular platform of the pipeline. It should be possible to identify the exact branch and revision that were used to create the build in question. So it should be standard practice for a developer to pull the code in question before looking for the bug. It should be, but in my experience it rarely is.

The industry has known about the promotional model for many years. In fact, some source control systems claim to support the promotional model. They usually support this claim with branching and tagging features. It's not the same thing. To do promotion right, you should implement both source control and bug tracking, and then integrate them with a database that tracks builds through the pipeline.

Start a Source Code Repository

Friday, March 16th, 2007

Most of us have side projects going on at home. These help us to hone our skills and learn new technologies, as well as to explore other domains that catch our interest. Sometimes our hours spent at night and on the weekend are an effort to get out of our day job. Software professionals tend to be software hobbiests.

Whether your side project is your cubicle escape strategy or just for fun, you should create your own source code repository. Obvoius benefits include a backup of your work, a log of changes, access to past revisions, and portability between machines. Just running VSS on your desktop machine can satisfy these needs. But I recommend that you take it one step further. Put your source code repository out on the Internet so that your friends can share your code.

I use SVN Repository to host all of my side projects (I have three going right now). Their small business plan runs me $7.00 a month and gives me all the services I need. Sure, I run a small business, but this plan is good for individuals too.

If you want to have show-and-tell in the office, you can quickly add an account for each of your friends. They will be able to browse the code from the web, or download it using an SVN client like Tortoise SVN or Subclipse. One of my friends was so intrigued by the show-and-tell that he offered to contribute to the project. Hosting the repository online made this possible, where a local VSS database would have been difficult to share.

Indexes in the File System

Sunday, November 26th, 2006

The Windows file system has become a jumble of mixed concerns. What started out as a way of organizing information hierarchically has mutated into something that second-guesses users at every turn.

Case in point. I finished building my wife's new machine and started copying photos from mine. I left the process running for a while, then went back to my machine to check on its progress. I found a message on the screen asking if I would like to overwrite the file "Thumbs.db". As Alan Cooper says, the computer had gone stupid. Instead of doing something useful, like continuing to copy the files that it could, it stopped and waited for someone who wasn't there to answer a dumb question.

This, of course, happened because Windows creates an index file whenever you switch to thumbnail view. Her machine had the folder open in thumbnail view so that we could verify that the pictures were indeed being copied. So her machine created an index file, and my machine tried to push a new one to it.

The root of the problem is that the OS is using my file system for something other than my files. My intent is to store pictures in this folder, but the OS throws something else in for its own purpose. Who does this folder belong to, anyway?

There are plenty of other examples of this. When you edit a Word document, the program creates a temporary tilde file in the same folder. This is used as a workspace while the program runs, and as a restore point if the program crashes. I once made the mistake of editing a Word document directly on a floppy disk (yes, it was that long ago) and removing the disk while editing. The program crashed soon afterward and the disk was left in an unusable state. I intended to put the disk back in prior to saving, but Word was using it for its own purposes.

Some source code control systems also exhibit this behavior. Visual Source Safe puts index files in all of your working folders. Subversion creates an entire subdirectory called .svn in each working folder. This makes it impossible to just check out a snapshot of the project, say for an automated build, and get a pristine copy. Or to check out of one branch in order to check into another. And what if, for some strange reason, a folder named .svn was actually part of my project?

Here's my solution
Just use your own database for information about a user's files. Leave the file system alone. That belongs to the user.

Or better yet, put the user's documents into your database, too. The file system is just a confusing jumble of metaphors for the average user. The less they have to see it, the better their experience will be.

But in any case, don't put indexes in the file system.

Separate Concerns

Thursday, September 7th, 2006

A spreadsheet contains both formulas and the data on which they operate. This makes it difficult to share formulas with someone else without sharing the data. If you want the same calculations performed on a different set of data, you have to make a copy of the spreadsheet. If you later need to update the calculations, you have to make the change in both places.

A Visual Source Safe database contains one tree of folders. A folder can represent a project, a package, a branch, or a shared library. Through discipline, programmers keep these different degrees of freedom on different levels of the tree. We will create a folder under a project to represent the trunk, and another to represent a branch. But what about branches of the shared libraries? Where do they go? Sometimes it is not easy to place one concern neatly below another.

An Ant build script contains several targets. A target can represent an action (clean, compile, deploy, etc.), or it can represent a project (shared library, business logic, web application, etc.). Targets depend upon other targets: deploy depends upon compile, and the web application depends upon the business logic. I need to clean and compile each of my projects, but only deploy my web applications. The web application deployment should include all dependent projects. When describing this to Ant, I end up with a cartesian product of actions for each project. If I later have to modify an action, I have to do so for every project. Similarly, to add a new project, I have to copy and paste all of the actions from another one.

All three of these scenarios suffer from a coupling of concerns. Different dimensions of the problem should be allowed to vary independently. But when the design of the solution mixes these dimensions, it becomes difficult to pull them apart later. Unfortunately, this sort of design flaw is usually not detected until the system has been in use for some time. Please take the time during the design phase to ask if yourself if you can separate concerns.

Source code inconsistency

Thursday, July 27th, 2006

Earlier this week, I talked about an error message that appeared in Microsoft Visual Studio as a result of VSS integration. While the error message itself offered a few lessons for the software adventurer, I would now like to examine the core of the problem: VSS is not ACID.

If you are not familiar with the acronym ACID, please see this Wikipedia article. Basically, the idea is that you get to work on isolated snapshots of the data, with no interference from others who may be working concurrently. When you want to commit your work, you synchronize with others.

This is a fundamental flaw in the way that VSS works. Other source code control systems are ACID, like CVS, Subversion, and StarTeam, just to name three. Let's walk through a scenario to see why this is important.

Suppose you are working on a bug or enhancement and you have some files checked out. Now you need to change code in a file that you haven't checked out to complete your work. You open VSS and check out the new file. Or, if you are using VSS integration, you just start typing and Visual Studio automatically checks out the file for you.

But wait, someone else has modified the file and checked it in. Their change was part of a larger modification. They have also changed other files that it depends upon, including some that you currently have checked out. As a result, when VSS checks out this one file, thereby getting the changed version, it is incompatible with the other source files in your project. You will spend an hour or two getting your project to compile again, which may mean merging with the changes you've already completed.

The only way to continue working without interruption is to start making your changes from the version of the file that is already on your system. This ensures that you have a consistent set of source (the C in ACID), and keeps you isolated from other peoples changes (the I) until you are ready.

There is a way to do this in VSS, but it is tedious. First, turn off Visual Studio integration. Then, when you need to check out a file, go to the VSS file history window. Click on the version that you already have (you may have to click Diff to find it, or better yet create a label before starting your work). Perform the check out from history. When you are ready to check in, VSS will help you perform the merge, if necessary.

Better yet, invest in an ACID version control system. CVS and Subversion are free, but they take a little setting up. StarTeam and others cost money, but may offer the usability and features that you need. Whatever you choose, you will recoup your investment by avoiding interruptions due to inconsistency.

Visual Studio in a Zombie State!

Tuesday, July 25th, 2006

Never let a programmer write error messages. In our own software, we have one error message written by a former employee which reads, "Problem shutting down server! A cold blooded murder will now be performed." This, of course, indicates that the server is terminating the background thread.

I'm tragically amused when I see such error messages in software. Take, for example, Visual Studio. Open a project that is under source control. Make sure you have an older version of the project file than the tip. Now go into the project properties dialog and make a change. Visual Studio will check out the project file for you to edit, and in the process it will get the tip (a serious problem that I will blog about later). At this point, when you press OK or Apply, the following message will appear:

"Cannot access data for the desired configuration since it is in a zombie state."

Being a programmer, I think I can understand why my configuration might be in a "zombie state". I can also figure out that all I have to do is cancel the dialog and try again. This time, the project file will be checked out before I begin.

But while this error message may speak to the programmer who wrote it, it does not mean much to me.