I’ve been sitting on this post for awhile now. Not because I didn’t want to share our practice of source promotion and build management but purely on the fact that I knew it would take me a while to get my thoughts down on virtual paper. Plus I wasn’t quite sure how to get the details across without boring you to tears. Let me start by just babbling away…
As a consultant, my projects typically involve some sort of custom business application that never sees the light of day outside the corporate walls. Yes, I was lucky enough to build something my mother could touch and feel and that was pretty cool. But 99.9% of the projects I’m involved with are pure custom business apps. In the past few years, I have found myself becoming less interested in what we were building and more interested in how we built it; defining the process and the tools to help us stick to our process. I became more interested in building the tools to help our developers do their jobs as opposed to building the software apps to help the business users perform theirs. (any VS team members looking for individuals such as myself, please see me after class) After all, I was a developer to, so I knew exactly what I needed to help me perform my job better.
No matter what our process was, there was always the need to be able to provide an efficient and structured way of promoting our source code from one environment to the next (DEV to QA to PROD). For whatever reason, my clients had a hard time justifying the cost of purchasing a 3rd party SCM product when we already had a license for one with our given Visual Studio purchase. And that as you all know is our good friend, and our worst enemy, Visual SourceSafe. True Visual SourceSafe works well in small team environments (on most occasions). But what I’ve always fought VSS with in the past is the ability to promote our source code through the development environments.
In the past I would create a project in VSS, call it DEV, and share out the files into a new project called QA. Within the QA project, we would pin the files at the specific version numbers for which QA would be built off of. As you know, when you modify a file and check it back in to VSS that check-in is assigned a new version number. After the code has been reviewed and passed the unit tests, the word would be given to promote it to QA. Within the QA project, I would have to unpin the file and re-pin it at my new version. This same process would be repeated for the PROD project as well. This is fine when you’re dealing with one file, but what happens when you need to re-pin a group of files? VSS certainly doesn’t provide an easy way of doing a batch “re-pinning”; short of writing some command-line batch scripts or building your own with the VSS APIs – not an easy feat.
Out of our frustration with trying to make an old-tool do new tricks, we decided to build our own source promotion tool on top of VSS. We call it Strider. I will go into further details in my next blog entry about the Strider tool as this entry is becoming increasingly wordy but the gist of the tool is this:
1.) Create a submission tied to a unit of work (ex. I’ve implemented a new login process that involves 10 files) (MSFT is calling this a ‘Work Item’, I believe)
2.) Bind the affected files (and their version) to the submission.
3.) Promote the submission as being available for the next environment build (DEV or SYS TEST).
4.) On the next system build for DEV, the Strider back-end tool will pull down all the file versions pinned for its build and kick off the build scripts. In our case, we use NAnt.
5.) If the build is successful, the submission is tagged at that environment and ready for any regression or integration tests.
6.) If anything fails, build-wise or test-wise, the submission is rejected to its previous environment. The unit-of-work (and all its files) succeeds together or fails together.
7.) If everything tests out within the given environment, the submission is than tagged for promotion to the next environment (QA). When the QA build is triggered, the Strider back-end tool pulls the source files tagged for its build and continues the same process.
Everything is automated once the developer creates their submission. In this case, we are covering the first 3 items of the Joel Test.
· Do you use Source Control? Yes
· Can you make a build in one step? Absolutely!
· Do you make daily builds? At a minimum.
I’ll try to put together some additional posts with Screen Shots and more details into the workflow of the tool. I’m interested in hearing your opinions and thoughts and how you do perform these types of tasks within your environment.
After spending the past 2 weeks visiting a five-foot mouse and experiencing the Greek culture through my sister's wedding, I'm ready to get back to it. Technology that is. My sister's unfortunate decision to plan her wedding the weekend proceeding TechEd prevented me from attending the grand 'ole party.
I'm a conference nut. I enjoy the networking with fellow geeksters and crashing the hip parties more so than attending the sessions themselves (who doesn't?). Don't get me wrong, the sessions are great, but the parties and networking opportunities are the key to great conference experience. What do you remember more? The hooker who buddied up to you in the wee-hours at the hotel bar or the talk on Architectural guidance? Seeing as how it doesn’t look like their will be a PDC this year, there’s always TechEd/Europe. Now I just have to convince management on that one. It’s an awfully long wait until TechEd 2005.
The entire conference week usually gives me the adrenaline needed to take me through the next 6 months of pounding away at the latest and greatest. Thanks to the blogosphere I don't feel totally left out as there are a number of people and sites allowing me to experience TechEd vicariously through their postings.
One of the announcements coming out of TechEd that feels me with utter excitement and interest is that of Visual Studio 2005 Team System. This new tool set will help in the effort of the Software Development Life Cycle and is an area that I’ve had great interest in of late. I’m plan on keeping a close watch on this one.
Blogs of interest:
Visual Studio 2005 Team System blog
Rob Caron
Brian A White’s Bug Blog
Korby Parnell
Buck Hodges
Brian Harry