I read a bit on Environment Tests and Deployment tools and it got me thinking. In my mind if there is a picture of deployment tool, it is InstallShield. If I need to install an application in my PC, I would ideally like to get a package which tells me exactly which exe to double click to start installation (No, I don’t want to do 10 things before starting my installation), essential information I need to know (I don’t want to choose a thousand attributes which can be probably defaulted) and a neat and complete way to uninstall the application (it should remove every bit of itself – I don’t want to pollute my PC with unnecessary stuff). Now, the application I am developing can be deployed like this? Probably no. I assume my job ends when I have a perfectly working application satisfying all user requirements and more. Deployment should be easy and it is left to system administrators.
Deployment or Implementation would seem like an insignificant task for most developers. We burn so much energy into designing an application, build, test, fix and make it ready for the user to test it or to implement it in production – a minor problem in the implementation can create bad vibes for the product at the outset. In my experience, most often the initial implementation problems were minor in nature (as far as I am concerned) – it usually takes less time to fix and more time to explain. It is very frustrating for the developer than anybody else when somebody totally unaware of application starts screaming that it is not working! At least for the peace of mind, it is important to have the steps for installation of the product and the pre-requisite and post implementation tasks documented and as much as possible automated to reduce the risk of manual error.
In the systems which I have worked on, as soon as it goes for production implementation, system administrators take over the implementation tasks. It is like you go through all the pains of developing your baby and as soon as it is the delivered someone who may not even care as much adopts it. When it starts crying, they become angry and frustrated and you know exactly what it needs and you can only explain what to do. Suddenly you have limited access and you are required to guess what is wrong with it. A compilation sequence has gone wrong and a package did not get compiled or after implementation couple of packages became invalid and needs recompilation – just this much could make it unusable. That is probably one more reason for me to consider this step as important.
So far, in my experience, following were tried out-
1. Environment Documents: - Document every single bit (configuration file changes, directory setups) and keeping the focus that a third person is going to configure the system.
2. Installation Documents (Readmes etc):- Pre-requisites:- Make sure that everything which is needed to even start code installation is already setup in the environment; sequence of installation of various types of code. Post installation setups.
3. Automated Installation Scripts: - As much as possible automate. It will simply reduce the chance of manual error and you don’t have to answer any questions.
At this point, I did a bit of research and following are some points, which I may be doing, but not put into a structured thought process.
Other systems should still work after your implementation. We could be so much concentrated on getting our software installed on to the target machine that we may forget it already has something which may get affected by our installation. Make sure such impact is tested earlier.
Generating logs of installation: - Success as well as failure of installation should be logged and log should be verified before starting to use the system.
Pre-cursor steps: - Check whether instance is even ready to take application in. It could be multiple steps ranging from verifying application server setups, presence of database objects to checking whether required directories are present with required permissions.
Installable in multiple host instances: - Often we design the installation scripts knowing the target system specifically. If there is a chance of the scripts being used for multiple stages (probably user testing, acceptance, production type of scenario), keep the scripts and configuration documents generic.
Versioning could play a very important part in a system where continuous software upgrades happen to the system and the code base progresses through multiple stages before reaching production.
There are two distinct dependencies: - Run-time and Install-time. Just because of the files are installed successfully may not mean that application will work. It would require run-time configuration steps to be completed. It is possible to write a script to verify whether all nuts and bolts required for the application to run are already put in place. Another handicap for developers is, once application is live, you cannot run it through a set of test data and make sure that all its functionalities are proper.
Deployment involving change in system configuration could take backup of the existing configuration files and then perform the new steps.
Packaging the builds: - To refer to what version of the build is currently deployed, it is important to wrap the different set of sources into one (usually compressed format to transfer safely and completely) and refer using a naming convention. There could be initial installations, upgrade releases and hot fixes – depending upon the complexity of environment it may be useful to name the packages used in each case appropriately.
If the development and deployment teams are well separated, then complete transition becomes key to successful implementation. It is too easy for something to go wrong if the development team’s assumptions about what they are building is not documented and known to deployment team.
File-conflict detection: - Bit more advanced. This could make sure the existence of a lower version of the file when a new build goes into the system.
De-install scripts: - what will happen if installation breaks down in the middle? System can’t remain down until you fix the installation? If there is a chance of incomplete installation harming the host system and existing applications in any way, plan for it by keeping any de-install script or steps ready.
This whole process should be well integrated with the build process itself. If you wait till the last of the features are tested, close your books and hang up your boots and then remember to make up some installation scripts, first of all, it will be a grunt work and second, you probably don’t have any way or patience to test your deployment scripts.
Deployment plan (level of automation, mode of deployment, usage of tools) should be made well ahead. Typically, the race will be to meet the deadline for the development of the application, but on the designated day if you give hundred files to system administrators, it would probably take another week to get it implemented and effectively there will be project delay.
Deployment process could have following steps:-
Validates prerequisite dependencies
Checks for file conflicts
Executes and pre-installs scripts
Installs the files
Records the installed files in a database
Executes post-install scripts
The level of automation or planning for deployment will depend upon the scope of the project, frequency of upgrades, complexity of environment etc. It could range from simple readme for installation to full-scale deployment tool to be used.
There are variety of deployment tools available which I haven’t had an opportunity to use and have a prejudice that it will probably not meet 100% of my requirements and I may have to then find ways around it which will in turn reduce the effectiveness. But then again, it is just a prejudice.
References:-
1. Software Deployment and Configuration
2. Towards automated software component configuration and deployment
3. The Software Deployment Mystery – Solved
4. Agile Deployment: The View from the Inside
No comments:
Post a Comment