How do you handle your build/promotion process?
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.