The automated deployment story
Here’s the story of an automated .NET deployment. Story is strongly based on my current project. To give you some context, here are few facts about the project:
- dozen web applications (half of which to be installed only on test environments)
- more than dozen console applications doing various things (reporting, mailing, etc.)
- four environments (DEV, TEST, DR and PROD), up to 4 machines each
While it certainly is not the biggest .NET project, it for sure calls for automated deployment procedures. The previous tedious manual process was taking up to 8 hours to complete and, needless to say, was failing quite often due to deployment notes not being up to date.
I started automating the process a few months ago, but at first I was struggling with each and every step. The breakthrough came with reading the awesome Continuous Delivery book by Jez Humble ad David Farley.
This is the first post in the (hopefully) long series. It is mean to give you an outline of the process we implemented. As time passes, it will fill with links to posts covering specific areas. So, here’s the sketch
- Compile the source code (nothing fancy here)
- Run the commit stage tests (mainly unit tests)
- Build and digitally sign the deployment package
- Put the package in the build drop folder (again, nothing fancy)
- Create a new Release Candidate in the release repository
- Get the latest Release Candidate which passed commit stage tests
- Start the deployment based on description of the environment (what to install where)
- Upload the deployment package to target machine(s)
- Validate the authenticity of package with public key of the publisher
- Stop all running applications (both web and console hosted by Windows Scheduler)
- (Re)create the applications and application pools on IIS
- Update the binaries to new version
- Start the web applications and schedule console applications
- Verify the correctness of deployment
- Run the integration and automated user acceptance tests
- Update the status of Release Candidate reflecting the outcome of the tests
- Building the deployment package « Posts In English « Simon says… architecture!
- The release candidate repository « Posts In English « Simon says… architecture!
- Deploy based on external description of the environment « Posts In English « Simon says… architecture!
- Automated deployment security concerns « Posts In English « Simon says… architecture!
- TFS 2010 and multiple projects output « Posts In English « Simon says… architecture!
about 4 months ago
Can’t wait!
What tools are you using? TFS with MSBuild, or maybe something “cool” (like TeamCity + Rake)?
PS this post has the incorrect polish flag assigned
about 4 months ago
@Procent
Thanks for pointing the flag problem. Fixed. This may be a little spoiler but I use TFS (company policy), MSBuild, WebDepoy/MSDeploy, PowerShell (+remoting), IIS scripting, Windows Scheduler scripting, custom packaging tools and curl
about 4 months ago
Waiting for next posts
Need to rebuild my build/package/deploy solution – more customers, more versions, more environments – current solution based on TeamCity, msbuild & custom scripts started to be too complicated 
about 4 months ago
What about symbol files? Do you store them for later use (support of crashes/hangs, etc.) ?
about 4 months ago
I store all the binaries I generate but since there was no production deployment yet, I have not used them in any way. I deliberately use optimized compilation for all binaries, even the ones deployed to dev/test, and so far had no problems with diagnosing crashes based only on limited stack information. Short methods and SRP are key enablers of such strategy.