Ah, deployment. That nervous moment when you release your code in to the wild to be used by, well, users. You’ve done your part to test it yourself. You’ve maybe even had a QA team or engineer take their best shot at finding bugs. And now it’s time to kiss that baby good bye and promote it to the all grown up world of “Production”.
Having a good strategy for deployment does two things. First, a good repeatable process will ensure that anybody on the team should be able to issue a release. This is important purely so you don’t get that call while you’re waiting in line at Sea World telling you that an emergency patch is needed and you have to guide the team through the release. Secondly, a good deployment is prepared for the awful but very possible reality that you might have to abort the release and roll back to the current version.
That said, here is a basic structure I use for preparing and deploying code.
Get a clean build.
This can come either from a build server, continuous integration platform, or a reliable developer’s system. I primarily use Visual Studio, so I always Clean and Rebuild at the Solution level to ensure all the assemblies are refreshed.
Create a label or tag to mark your code.
For me, this is a basic audit trail so I have a timestamp of the release candidate version. It also is a milestone from which I can merge to a Production branch if this release is the final version that goes live.
Create your release package.
Again, the actual packaging of your release can take several forms. For some projects I use the Visual Studio ‘Publish’ feature, and have it output to the file system. From there I’ll FTP the files to the production destination. For other projects, we use a Setup package that creates an Installer. This is mostly used when someone else such as a client is performing the deployment. Pick a method that makes the most sense for your product, team, and production environment, and stick with it.
Establish your release schedule.
I tend to favor Friday night as a deployment timeframe mostly because it gives you the weekend to address any issues that may arise (when dealing with a business or corporate application). Some of my clients do releases on Thursday mornings, others on Thursday nights. There really is no right answer here, so again, find the most suitable time for your team and users and make it predictable.
Put up a maintenance page.
Depending on the size and effort required to execute the deployment, it may be necessary to put up a maintenance page informing visitors to your site that you’re making updates. What you don’t want is people thinking your app is broken because they stumble upon it while your trying to release fixes or new features. I love the ‘app_offline.htm’ file that IIS can use to show a maintenance page. It’s simple, easy to customize, and is easy to turn off and on as needed.
Back up code.
Pulling a back up of your code pre-release is the contingency plan in case a rollback is needed. It may or may not be necessary to back up every file, particularly if you have static or user-contributed content. Ditto that for any log files that may be in your app. But certainly the ‘guts’ of your app (meaning .DLLs, include files, etc.) and the ‘skin’ of your app (meaning any UI elements).
Back up data.
In many cases, if you have nightly database backups running, then the prior successful backup may be sufficient. However, for highly transactional or critical data systems you may need to do an explicit data backup during your release window.
Deploy code.
FTP files across, or run the installer.
Deploy data changes.
Execute any database changes that are necessary using your database administration tool.
Confirm.
Confirming a successful release may simply mean checking a status page, or logging in and running through a series of transactions. Your QA process will dictate what is required to verify a release in the production environment.
Take down maintenance page.
Rename the app_offline.htm file or otherwise set your app to live mode.
Branch or merge in to Production code line.
Now that you’re in Production, create or update a Production code branch with the code versions that have just been deployed so that you can address any production bugs without interfering with your ongoing development process.
Announce your updates.
In some form or another, let your users know what’s changed. This might be a blog post, a status update, Tweet or email. You’ve worked hard on this code and these features, so use this as a chance to get your users excited about using it.
The process of releasing code to production will obviously vary according to the nature of your app, your user community, and your hosting or production environment. But having a defined process will help make each release go smoother.
Leave a Reply