Man, my project's development and testing phase is almost up and boy, am I feeling great with the expected delivery of our baby. We're expecting a sign off from the testing team sometime tomorrow morning and waiting to deploy our seven months hard work on a staging environment, play around with it over there for sometime and then finally host it up on the production environment and live happily ever after. Jeeze, I get all too emotionally close when I talk about my project but that's probably because this is one project where I've been involved since day one and will be around till the day it gets live and probably extend a helping hand for the expected phases in the pipeline. Since I'll have to worry about deploying our project onto the staging environment next week followed by the production environment at a suitable date, I was thinking of looking a little bit into various aspects that we developers might need to consider while deploying our application on to different environments to get our baby on board and working the way we want it to. Since scope for scrutinizing all the aspects of deployment and that too, with respect to a .Net development environment, is massive, I'll start with this elementary article that takes a look from the high level at deployment considerations and probably follow it up later with deployment mechanisms that we can employ using the .Net framework. Different Deployment Scenarios When we're talking about deployment, remember that the task is not a one time affair. To elaborate, not only does deployment entail the process of getting your final application onto the production server and making it live, but prior to that, it also consists of setting up your project to work in various environments before you actually host it (in the case of web applications) on the production environment or make it available as a download or a package file that you might want to install as a windows application on the end user's machine. A deployment strategy is devised at inception itself - during the design phase at best or at least on a parallel, during the development phase. Starting with the development phase, through the testing phase and finally getting our project onto production, there are different considerations that you will have to tackle to get your application working without issues during post production. Initially, the development team starts code construction by setting up a development environment. The development environment will consist of computer systems with the necessary hardware configurations required along with all the necessary software - the Operating System, a development IDE (like VS.Net), SDKs, tools that aid in designing, and any other applications or tools related to the project. Now what this implies is that there is a chance that we can tend to create dependencies knowingly or unknowingly during the development phase. I published a little crude program to read emails from outlook a few months back, but I still have people asking me to send that required component because they did not select the component while installing Outlook (and I did while developing it). Consider for example, when you might have a small functionality in your web application to export data to a Microsoft Excel file using the conventional method (creating an instance of the Excel API). This might be possible on your local system because you already have Microsoft Excel installed and all the necessary Excel components for development. But what about the production environment where your web application resides in real time? Will the server have Microsoft Excel installed? If you do want to have that excel functionality, that implies that you possess a license and install the thing on the production server. So now you know what I'm talking about: unforseen dependancies inherited from your development environment. So once everything in the development phase is done and you have all that neat code worked for your project, it's time to get your baby tested. This is where the Testing Environment comes in and we'll have to get our deployment package ready here itself and installed. The next part of the life cycle is to perform various testing processes on the application on an environment that closely resembles the production environment. This is where personnel involved with the testing phase rigorously scrutinize every aspect of your baby, its functionalities and its performance and report any issues to the developers to get them fixed. It is crucial that the test environment duplicates the production environment. I think specifications for this are flexible and vary between team to team. I've had a few developers tell me that this might not always be the case as test environments are sometimes intended to test the functionalities of the application only and other aspects such as performance are given a second priority at this point. Hence, you might have a hardware mismatch (it could just be another desktop as in our case) in the test environment and this might not be the best place to do a performance, load or stress test (though you could still do it and gauge how well your application works). Therefore, the performance aspect of the application is tested later on another test environment that duplicates something close to hardware setting. Another requirement of the test environment is that development environment tools, extra software and unnecessary applications that are not expected to run on the production environment SHOULD NOT be installed here. Similar to what I mentioned earlier on our Excel example, such a miscalculation might hide potential problems that will show up in the wrong time and the wrong place and you already know that this is your everyday programmer's worst nightmare (Incase you don't get it, I'm talking about everything getting screwed up during post production). This is because many components present in the construction environment may not or are not expected to be present in the production environment. These components get installed on the construction environment thanks to development tools that you might have used or the SDKs or anything else. Another common situation is reflecting the Database (Timeout issues for instance) or Web Server (Mail settings in IIS for eg) configuration settings on your development environment to other environments. Security permissions, message queues, performance counters may not always be correctly configured on the deployment environment. So that's just one crucial aspect while migrating your application from the development environment to another one that we'll need to keep aware of. I find a check list the best way to ensure that no goof up happens during this time. Following the successfully completion of testing your application on the test environment, the next environment you need to deploy your application to is the Staging environment. The Staging Environment is the place where you might want to do last minute tests on everything and probably scrutinize good enough to make little changes if necessary. We'll be putting up our application on the staging environment next week. What we expect over here is to actually run the system as if it would run on a live production environment. This means that we'll be loading the database with thousands and thousands of records; connect it to the network too, have lots of users access it, perform stress and load tests, run lots of other real-time scenarios and see if it works as expected (we'll be showing a demo here too). I've heard a few people tell me that their teams skip this environment and sometimes don't give it serious thought where time and effort matter but yet, that doesn't sound so professional and safe does it? I think it's still a common existing environment that many big projects budget for. All functionalities are retested here as the production environment is closely replicated. For instance, the staging environment should have the exact same Operating System (with the same patches etc), the same network settings with the same security policies in place (We had a situation once where a firewall stopped our application from shooting mails - the reason? We were sending unauthenticated emails which was okay till the customer's security policy changed after a few months), the same components and applications that will be installed on the production environment need to be setup here. It's not always feasible to exactly replicate the hardware setup existing on the production environment in an intermediate one like the staging environment, yet, this environment is the closest the team can get to deploying their application on the production environment and having the luxury of making last minute changes. So now we finished with staging our application on an environment closely similar to the final destination aka The Production Environment. No giveaways for guessing what happens here. But just a thought that sometimes I see happen to often: remember that this is a real dangerous place to make last minute changes, tweaks, run database queries (inserts, updates, drops, deletes) and play around with your application. That's why many (or all?) systems developed (even if they're not big enterprise level systems) and made live have a dedicated administrator to manage anything and everything related to the application deployed and do the dangerous kind of stuff that you might have done without a second thought on your development environment. The real performance and efficiency of your application under real-time usage becomes clear over here (and probably scope for a good appraisal :-) ). On a production environment, you might have other systems linked to your system, extracting data to create reports, or perform other complex tasks running along with it on a parallel. Well, that's something we're expecting to come up at a later stage soon. This project has been simply great. The best part is that we learnt a lot on the edge and also had the fortune of designing a system in such a way that scaling it up, working on extensibility and customizing it further would not be an arduous task for another developer that comes to the team later for phase II and phase II.... even if we developers were not around. So time to call it a day and look forward to tomorrow. As usual, the first thing in the morning will be the Single Point of Contact (SPOC) from the customer calling with a "Geeee-orge.... what about the..." and that'll start with another day of feedback and queries. Oh wellï¿½ thats my programming life, how about your's? Good Night and Happy Programming Y'all!