In my ‘How do you handle your build/promotion process?’ post, I promised some screen shots of a tool we built called Strider. It’s been more than a month since that post and due to the lack of nobody banging on my door for the follow-up post I decided to shelve it until I had ample time to provide a quality post. It’s your call on what is quality, but if I can just touch one reader…. anyhow let’s get on with it.
The quick overview of the build/promotion problem they we tried to solve is trying to come up with a less painful process of managing source code promotion through the different development cycles (Dev to QA to Prod). I’ll let you read the previous post to get the full jest.
With Strider we are taking the pinning process out of SourceSafe and moving into our own custom database. In our particular case, we would like to treat a group of files as a unit of work that moves together through the promotion process. We call this a submission. Typically when you make enhancements to your application, you modify more than one file. Wouldn’t it be nice to move the related files behind an enhancement through the development cycle as one unit? This way if something doesn’t quite work out, you can back out the files as a group as opposed to one-at-a-time.
In our process, once the developer is satisfied with all of their programmer tests (unit tests), she will open the Strider tool and create a submission for the files that were affected. The following screen shot shows Strider’s submission form.
Here the developer gives the submission a descriptive title and assigns the various files, at their particular versions, that are affected by the enhancement.
In a perfect world, a succeeding version of a particular file will always be included in a submission. For example, Bob creates a submission for Version 2 of Login.cs and promotes it through the development cycle. Next Carol needs to make a change to Login.cs and creates Version 3. Carol than creates a submission that includes Version 3 of Login.cs and so on. Unfortunately development is never a perfect world. In the Strider tool, we mark skips in file versions by color coding them red. Green signifies that this file is the next version in sequence from a preceding submission. Red signals there was a version skip. What this says is that it’s possible that someone else modified this file but didn’t create a submission for it. If you include this file in your submission, you will be forced to include theirs as well. It’s a warning to verify it won’t be an issue.
Now there are cases were it makes perfect sense to not submit a version. If the file was checked into source control but something was left out, the developer would have to check out the file, make the modification and check it back in; bumping up the version number. Strider just warns the developer of the version skip just in case someone else made a modification to the file and didn’t create a submission for it because it wasn’t ready. So if Bob made his modifications to Login.cs and checked it in at Version 2, but never created a submission for it, and Carol comes along and creates a Version 3 but needs to promote her changes, she’ll be forced to promote Bob’s changes as well. This gets a little complicated but can be solved by communication. Strider just warns you that communication may be necessary. In the case of the screen shot, WebServicesLayer.cs jumped from version 1 to 3, so it is therefore marked red. Sorry that was a little long winded, but I wanted to get the point across, hopefully I succeeded.
After the developer has created the submission, the submission sits in what we term the ‘initial environment’. In our case this submission doesn’t belong to any environment just yet. You have to promote the submission from Initial to Dev. For us Dev means it’s published to the other development groups for usage (integration testing).
The following screen shows what the submission list looks like for a particular environment. Here the submission list is for the initial environment for the IssueVission project. To promote my submission, I highlight the submission (which displays the associated files below) and click the Migrate button. After I click Save, the submission goes into Pending status for the next environment build (in this case Dev).
After all submissions have been migrated to their particular environment, an environment build is kicked off. This is either done on a schedule or an as-needed-basis. Most of the time we had a build manager that would kick off the builds when need be. All of the builds were executed on a build server that would execute the associated NAnt build scripts for the particular environment build. We would setup an icon to kick off the Strider console tool that would be responsible for pulling down the new submission source files for that environment and executing the NAnt build script.
If the build completed successfully the submissions were promoted to the next environment. If the build wasn’t successful, the developer was notified and they would have to back out their submission and make their modifications.
I hope this helps in giving you a glimpse into how we handle our source promotion process. I’m very interested to get my hands dirty with Team System to see if there’s any overlap with Strider. I’m also interested to hear from everyone on how they handle their promotion process. Are we making it too complicated? I haven’t found a better way, if you have, I’d love to hear it.
I’m also pondering on submitting this up to GotDotNet to let the masses make it better. If you’d be interested in this, let me know. I have to do quite a bit of clean up before I feel comfortable submitting it though.