A year ago, my team was using Visual Source Safe as our version control repository and our builds were built and deployed manually using sophisticated tools like windows explorer and remote desktop. This was not a happy time.
- VSS was awfully slow and practically impossible to work with remotely.
- VSS branching, tagging and merging capabilities were primitive at best.
- Our manual deployments were not scripted and therefore not easily repeatable and certainly not guaranteeably repeatable.
- Deployments were inadequately documented and it was often impossible to know exactly what was deployed and when.
- Complicated deployments were time consuming, error prone and just plain stressful for the build engineer.
Well all of this has changed now. We migrated to Subversion for source control and implemented CruiseControl and NANT as an integration server and deployment solution. Looking back on this migration, I can honestly say that it represents the biggest leap forward we have made in terms of process improvement. This is a first in a series of blog posts where I will document this process in detail. I will outline how we tackled the following:
- Repository structure: We did not want to merely copy our VSS repository tree. We wanted to create something fundamentlly more useful.
- Generic NANT scripts to handle Visual Studio Projects and Solutions
- Managing configuratioin files in different environments (dev, staging and production)
- Automated tagging production deployments
- Cruisecontrol organizaion
Some may say, "Its only source control, what's the big deal?" Well our source is our product. Any inability to produce our product or any risk to the integrity of our product is a big deal. As developers, we interact with source control throughout every working day and it is imperative that these interactions are simple, reliable and valuable. If there is waste in terms of time or lost code at this layer of the develoopment process, its like a death by a thousand cuts to the whole dev team.
This was a migration that I took very seriously. Like most software shops, we are always very busy and juggle lots of projects at the same time. This migration provided no direct revenue increase to our business and was always difficult to prioritize. I was often asked "why don't we just migrate now? Just have Joe Jr. Developer port the code from VSS to SVN and be done with it." This was something I really wanted to think through, research and do right. I knew it was not going to be a "set and forget" operation. It needed to be planned, implemented and enforced and baby sat. My team, including myself, had been using VSS for years and were not familiar with the branch/merge paradigm of SVN. I knew we needed to understand these concepts and use them to their fullest. I also knewthat developers were going to experience hickups with usig SVN and its related tools. I needed to educate myself and make myself availale as a mentor of this technology although I was a novice. There was no budget to bring in a consultant.
So I researched on the web, I talked to colleagues with experience in SVN in varying environments, and I mapped out my own custom solution. My tech department is composed of different teams that produce and maintain several different applications that are web based, desktop and background services. We also have some common libraries shared and maintained by all teams and we share third party tools and libraries some of which are open source and require constant updates to new versions. We needed a solution that would allow us to build separate applications maintained by separate teams with code shared accross the organization. We needed a setup that would allow developers to commit code to a centralized Trunk that had all of the most recent changes but would present these changes to different applications in a controlled manner.
I beieve we have acieved exactly this and more. So what do we have now?
- We have a source control repository that informs us of exactly what is on an individual dev's environment, on our integrated dev box, on staging and on production.
- We have a setup that allows us to see exactly what code was deployed on which application on which date.
- Commits to SVN are automaticaly built and deployed to our integration dev server
- Commits to staging are automaically built and deployed to our staging servers.
- With a click of a button in CruiseControl, an application can be deployed to our production server farms
- Each environment can have its own versioned configuration
- Rolling back to a previous deployment is trivial
My next post in this series will focus on the SVN structure we developed and how it partitions our different environments and applications but ensures that each new build incorporates the latest comon code.