The only thing standing between an application and its users is deployment on a production platform.
A one-time barrier to application update and deployment speed -- data center infrastructure provisioning -- fell to virtualization and cloud technologies. Internal IT organizations must scramble to keep up with cloud resources and other as-needed infrastructures or risk being left out by impatient application developers. Applications can lose critical pieces when launched without the involvement of systems and network administrators, IT operations or engineers.
The speed of business simply does not allow for the layered application deployment process of the past, so an alternative is needed: a better application deployment manual.
A successful deployment manual shouldn't be a policy or a collection of policies. Policies have a place in IT, but the app deployment process isn't it. View the manual as a living document and not something static. The app will get updates and added functionality, and therefore will have different requirements in terms of resources and interconnectivity to databases and to other applications. Having a static model for application deployment is a good way to ensure that no one will follow it.
Release management best practices
While a comprehensive service management plan, such as ITIL, may be out of reach for some organizations, aligning release management with practical best practices will pay similar dividends.
Think of the application deployment checklist as work instructions. It will change based on what is being assembled, but it should follow certain key guidelines:
- Call out what is needed,
- Highlight the steps to follow,
- Show what the finished product should look like, and
- Document any variance to the instructions.
Application requirements inform deployment
Requirements don't comprise the longest part of an application deployment list, but they are the launching point for everything else to come across various IT teams. For example, the deployment steps of an application differ between Windows, Linux and cloud resource-based apps. Security processes vary depending on the application's need for a web service: .Net or Java. This step helps to define the framework for the steps to follow.
In addition to the obvious questions, such as platform and framework, requirements are also a place to address infrastructure and security questions. For example, what type of data will be transmitted? What are the backup and patching requirements? How important is hardening? Put these questions on a simple form and avoid heavy policies or procedures.
Easy to follow instructions
Work instructions and guidelines are the true bulk of an application deployment process. Simpler is better: If you spend hours upon hours writing steps, your deployment team will gloss over them. It's not because they lack value, it's simply because they are too long. If it takes you longer to read the instructions than to do the tasks, simplify and update the instructions.
Take a cue from physical products. If you look at "some assembly required" goods, usually they offer a collection of images or illustrations with bullet points on key steps. In the app deployment process, a screenshot does the job nicely. Combining an image with a few highlighted points not only conveys a message quickly, it also provides an excellent visual clue on whether the app deployment is on track. Screenshots also reduce the amount of time invested in creating the work instructions.
Screenshot-based deployment instructions can hit a snag when an application runs on multiple platforms. These images showcase the underlying operating system and infrastructure. If the app will use different platforms, reflect that in the checklist: This may require several frameworks of the work instructions to cover each platform.
What does success look like?
At the end of the work instructions, include what the final result of this application deployment process should be. It might be as simple as a configuration screen to verify success, or even a checklist of key items. The purpose is to validate what was done and ensure the instructions that the team followed produced the desired results.
Different isn't wrong
In some deployments, the team must account for variance in the build process. A software build process variance is not an error, it's an adjustment based on the application's needs. Document the variance, so IT operations can track and adjust the deployment if needed. Variances might require validation in a change control process. Even without formal change controls, an organization should have a process to make variance or exception tracking part of the application deployment process.
The application deployment instructions can be as simple or as complex as needed. The keys to a successful manual are flexibility to apply to diverse needs, ease of use so deployment staff doesn't see it as a barrier, and treatment as a living document that adjusts to the needs of developers and the larger business. By following a few commonsense guidelines, you can have a functional application deployment process that everyone values.
Bring apps up to speed with platform as a service
Weighing your cloud app development options
Tips to remember when testing apps