Application lifecycle management: Best practices for improving the deployment process
Nothing is more visible to both clients and senior management than an applications that doesn't work. And the risk for failure is never higher than it is the moment after deployment. So how do you ensure deployment always goes smoothly. There is no silver bullet, but there are some best practices for deployment, which we will examine in this article.
One of the biggest application lifecycle management (ALM) challenges is dealing with the task of application deployment. The process can be complicated and multi-pronged, with many different components and pieces interacting together when the final build is sent to production. Plus, when problems do occur the deployed application is also the most visible part of the ALM process.
After all, if a working application stops working suddenly, everyone from senior management to the end users will be asking questions and demanding answers about what went wrong. Fortunately, there are many best practices that project managers and DevOps managers have learned that can help to improve the deployment process. Follow these guidelines, and you’re much more likely to avoid running into problems after your application launches.
Do a reality check
Testing deployment in a sandbox environment that mimics the real production environment as closely as possible is essential for success. Still, many enterprises let their preproduction server and their real-time servers get out of sync as updates and upgrades happen. Make sure the testing servers and the production servers are as close to identical as possible, be it operating system patches or configuration file settings. The smallest deviations can have profoundly negative effects on a deployment.
Remember that the typical testing environment only shows you how an application performs in a perfect world. Sure, you can change the parameters, scale up and scale back, but that’s still the equivalent of an experienced driver testing a car on a nice, straight stretch of highway with no traffic. There’s simply no way to foresee every outside force or end user habit that might break your application.
You need a test environment that’s as close as possible to the production environment. In some cases, that might mean deploying to a staging environment that is Web accessible. Alternatively, you could deploy on your organization’s hardware and infrastructure but reconfigure the server load temporarily so only the testing team has access to the beta version of the appliction.
Use hands-on deployment testing
When you do test your deployments, there are a few things that you should be testing from the end user’s point of view, and not simply by running an anonymous script. How does the content delivery network affect the performance of your application? Does it render well and function properly on real browsers (including older versions if some users tend not to update to the latest version)? Do firewalls or Web servers restrict access to certain files or scripts? Are modules and extensions functioning as expected or do they result in unacceptably long run times under high loads? These are all questions that an automated script is not particularly good at answering.
Put people first
Remember, deployment is not simply a technological process – it is a human endeavor, and it requires a team approach in order to be successful. IT projects often run far past their projected finish date, but that doesn’t mean the project should keep everyone working overtime during the run up to deployment. Overworking the development team will result in worn out developers introducing more errors near the end of the project, when you are almost ready to launch.
Of course, it’s not just the people on your team that have a vested interest in successful deployments. The various stakeholders inside or outside your organization, as well as the end users, are important too. Understand their needs and expectations, or else your deployment may be taken off track by their resistance to change. This is especially true in larger organizations where there is a bigger the risk that someone will throw in a monkey wrench if the pending deployment doesn’t meet their requirements.
Automation and application lifecycle management
In almost all cases, manual deployment is the least effective option, and automation is now a mandatory part of application lifecycle management (ALM). Manual processes introduce errors rather than eliminate them. Dedicating an employee to manually performing a task that can easily be automated is simply a waste of resources, a reality that becomes increasingly apparent with large scale and frequent deployments. Take the time to source reliable, modular automation tools or scripts to handle as many of the ALM processes as possible, including:
- Load testing and performance testing
- Identifying dependencies between files and packaging files for distribution
- Installation to the target environment
- Configuration and change management
Pruning the project
As a project grows old, there is a tendency for superfluous files and resources to remain as part of the deployment, despite not being used or invoked anywhere in the application. Pruning an application from time to time is always a good idea. Look over the files, directories, modules, and any other resource related to deploying, using, maintaining, and running the application. If it’s not being used, don’t include it. Some IT project managers recommend getting rid of all old files and directories as well as deleting old versions from production systems.
Document, document, document
Documentation is your friend. Make sure there is detailed, accurate documentation of the code itself, how all the components fit together, the deployment plan/policies/process/protocols, troubleshooting, maintenance and training/instructions for use. You’ll probably find that you can reuse much of this information in the future. Your team will be glad they don’t have to re-invent the wheel every time and your stakeholders will be impressed at your quick, trouble-free deployments.
Furthermore, if the person who initially setup the deployment process ever leaves, you want to be able to retrace their steps and reproduce the process they created. Don’t let the intellectual property associated with the deployment process disappear because the employee who maintained it leaves the company.
Know when to stop
And of course, you should always be prepared for the worst, which means never deploying without a plan for rolling back the installation if it doesn’t go well. This includes writing and testing uninstall scripts. Be sure to communicate this plan to stakeholders so they understand that if something is broken during deployment, you can at least go back to the latest working version for the interim.
In the same vein, sometimes it’s not smart to boldly forge ahead in the face of uncertainty. As part of a pre-deployment strategy, identify points along the path where you stop and evaluate whether you are really ready to move forward or if you should delay or stop the process. It’s always better to identify and fix problems before deploying to production. The foot tapping of impatient stakeholders is something you can manage much better than the hailstorm of complaints caused by a faulty deployment that interrupts key business processes and torpedoes customer good will.
