So, you’ve coded like a banshee for 7 weeks straight, listened to your manager badger you about “sprint” this, “agile” that, “can you tell me when its really going to be ready to install at the customer’s site?
Well, before you go there, you should run through a pre-deployment checklist. Here’s one that I’ve come up with after going through the motions on a number of occasions.
Build and CI
If you’re not using NAnt or MSBUILD scripts then start right now! The first thing you should do when you’re building out your new project source tree is to get it committed to your version control system and then make sure it will be built by your Continuous Integration server.
By integrating constantly you’ll know when the changes you are making are going to break what someone else is working on. I hear talking about changes they’ve held on to for weeks before attempting to commit them to version control out of fear of breaking the build. Face it, the days of Big Bang check-ins and waiting for the nightly build are light years behind us now. To move fast, we have to identify the risks before it hits the deadline.
DO YOU KNOW YOUR INSTALLER?
How many times have you been burned by this:
Larry - You know, file fizzbin.dll is missing from the build.
Joe – Did you add it to the installer?
Larry – We have an installer?
Alright, I played that up a bit, but you catch my drift. Installers can be quite complicated beasties. In my team, I adopted a stripped down open source installer (Inno Setup). Sure, it doesn’t have all of the bells and whistles of some of the big name installers, but its damn simple. I combined that with something that we use every day (NAnt) and now we’ve got a half-way decent installer pattern.
If you write code, you should understand how your bits (DLLs, XML files, web files) get to where they need to go. Here are some things you should ask yourself about any file that needs to go into the installer:
- Is this a DLL? Is it already part of one of the projects whose output will be installed to the ‘bin’ directory, or is this something new?
- Is this a Configuration File? Should the values be preserved between installations/upgrades? How should I take care of values that are Added/Removed/Updated? Which services will access this file? Will the correct permissions be assigned to the file/directory? Does this file need to survive an uninstall?
- Is this a web virtual? Is there anything special that needs to be done to the virtual in the IIS Configuration? Does it need to be locked down?
- Is this a Windows Service? Have you followed the same naming conventions for the name, the .exe, the log file? The three of these should be similar in name so its easier for support to identify which service is associated with which executable and log file.
- Logging? Did you make sure that you are logging to the Log directory?
- Are there files that you no longer want to be included?
HARD CODED VALUES
OK, nobody does this anymore. We all have all the time we need to isolate the hard coded strings and have already moved them to configuration files or they reside inside of a resource file.
Now really, we all do this in our rush to quickly prototype the code we’ve got to get finished for the upcoming trade show or GA release of version 5.8. But really, you need to identify and move these values first to say a common access class and from there to a configuration file.
Check your configuration files
So all the code is done, you’ve made it through your xUnit tests and QA is saying that the risks are acceptable to deploy this app. And yet the application most likely has never been deployed to an environment similar to your (or your customer’s) production environment. So, now comes the hard part, we have to adjust all those configuration settings (URLs, passwords, connection strings, file paths, frequency values, etc). Sure that’s great. I know where all of those are. OK, but how many of those values are REPEATED in your configuration files? You know like, IP addresses to servers, account names, etc.
For those of us that enjoy using Resharper you become smoking ninja’s with your ability to keep your code DRY. But what about the ‘data’ in your configurations? How many connection strings do you reference? Do you have URL’s for WCF services that contain the same server name over and over again?
If we apply the DRY principle to our configuration files as well as our code, then its far easier to create instructions on which values to change for production deployment, or better yet to automate or provide tools to safely adjust these values (and even better yet, make sure that the values that are in the configuration files will work when the service/application is running!)
Database connection string
Hey, you’ve tested this, you know it works. Works for me! Every time. Recently we had a “head scratching” moment with our newly arrived QA engineer. She’d built out a VM and installed our software on it to discover that one of our applications didn’t run at all after installation. My team looked at it and said, “Hmmm… that can’t be happening. It works everywhere else. Let’s rebuild your server and install again.” So, after rebuilding the server it worked fine and dandy.
Some weeks later, I stumbled upon a hard coded connection string in the previously mentioned application and had my “AH-HA” moment, “So this is why it failed!”. If you’ve been reading above then we should have reviewed this and identified that first, there was a hard coded string containing a connection string and second it was duplicated.
So, what’s the lesson here? Well, the deployment environment should be taken into account even when a developer is writing and testing his/her own code. In this particular case, we would have recognized that the connection string was pointed to localhost\sqlexpress and it needed to honor what has in our connections.config file.
mock me? NO MOCK YOU!
OK, funny! In today’s world we need to be able to provide “fake” interfaces or simulate external services. The only way to make sure that you’re really ready for the vagaries of what you’ll find out in the production wilderness is to mock the different services that you connect to. The benefits will allow you to have confidence that the application you’ve written will stand up when it encounters unexpected results.
This is really a follow on to TDD. Test driven development actually leads to building out mocked interfaces.
Naming Conventions
If you are writing an application for a company and there is more than one application you’ll want to follow similar patterns when naming and identifying your application. Things to keep in mind:
- Keep track of the ports that you use if you use WCF services, proprietary listeners, etc. Support and the customer will want to know if your application needs to have inbound or outbound access on specific ports. Also, when it comes to TCP/IP ports, you really should check for a port range that is not used by other applications. Anymore, that is up in the 38,000+ range and anything below 10,000 should be reviewed carefully.
- Name your virtuals so they are consistent, easy to type and make sense for their intended purpose. Again you might have a common prefix for your application suite, or common suffixes for types of applications.
- Windows services are a big pet peeve of mine. Make sure you’ve made sure that you have a consistent Service Name, Display Name and you’ve taken some time to write a decent 10-20 word description of what the service is.
- Finally, make sure that your DLLs have the appropriate information in the ApplicationInfo files. The Company Name, Copyright, Product Name and version should all be there and be current. You can accomplish this by hand or by incorporating some steps into your build file.
Last Thoughts
This is entirely too long and I’ve most likely lost a lot of people by now. But the last step you should think through is about what you’ve done to your application during your own testing. Do you normally change values in the configuration files to debug settings? Have you deployed with the Log Level set to Debug? Have left the web.config with the debug turned on? Are you including your symbol files?
There’s a lot more of these types of questions that you should think about when you release your application into the wild. Some of this is about your ability to control your ADD (attention deficit disorder or bright shiny object chasing) and concentrate for an hour or two on the questions and topics I’ve brought up here.
Now Playing - Tom Scott - Reed My Lips - Saxappella
No comments:
Post a Comment