Ways to make the application deployment process clear and flexible

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

Think of the application deployment checklist as work instructions. It will change based on what is being assembled.

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.