Overview

Deployment automation helps drive faster feedback to developers and minimize the risk of errors during production releases. When rolling out deployment automation, start with quick wins in lower environments while keeping an eye on eventual use in production. 

Choosing the right Applications to Automate

Most rollouts will start with a handful of pilot applications. Through the automation and early use of deployment automation, the rollout team can understand what works and what doesn’t early in the process.
 
An ideal application will meet many of the following criteria:

• Development will be active: Changes will be occurring in the application with enough frequency to drive and exploit frequent use of deployment automation.
• Technology stack is “normal”: Ideally, your early applications will be representative of many of your other applications. This way, your pilot work can be leveraged towards rapid rollout of similar apps.
• Deployment process is understood: Eventually, you will have to figure out how to deploy applications whose processes are poorly documented and understood. For a quick win, start with one that is more known.
• The team is eager: Often when word of a deployment automation project gets out, some teams volunteer to go first. Those are good candidates as they are more likely to provide experts to help out.

Start with the Production Deployment Process in Dev Test

Frequent deployments to test environments not only facilitate the testing of the code, but they should also test the deployment process itself. For that to be meaningful, any automation that is created should be designed with production deployment in mind. Deployments to a development test environment or early QA environment are generally simplified versions of a production deployment. Conversely, a production deployment is generally not the same as a development deployment applied to more servers. There may be load balancers, additional middleware, third party content providers and more than need to be considered. 

• Initial deployments in early test environments: Run your initial deployments in early test environments to test the process. Begin deploying to production servers once you have gained confidence.
• Virtualize missing components: Parts of your application that are not present in lower testing environments are good candidates for Service Virtualization (link to practice) to support early integration testing.
• Easy Components First: Often it makes sense to start with web application and content tiers of applications. Then expand to BI tools, Mobile and Mainframe.
• Use Manual Steps to include un-automated components: To orchestrate changes across manual and automated components, use a manual step in place of the automation for components you haven’t got to.
• Avoid automating bad practices: An automation effort is an ideal time to evaluate your deployment processes and make changes. Scale Configuration with Templates.
• Version control automation: Establish a change control system for the configuration of automated deployment configurations, processes, environments and resources.

Expanding your roll-out

• Configuration with Templates: As you become comfortable with pilot applications, convert components that are similar to others in the organization into component templates. See Component Templates in IBM UrbanCode Deploy v6.0.
• Incorporate remediation: If there common failure points in some of your deployments such as an application server that won’t shut down, consider having frequently failing steps automatically trigger remediation steps.
• Trigger testing at the end of a deployment: When deployments complete, initiate the appropriate testing for the environment. Look to the Switch utility step to help map environment to test type.

Pitfalls to avoid

Beginning with how the developers deploy: As mentioned above, use the desired production deployment process as the baseline. Developers may use short cuts like dropping the database and recreating it from scratch as part of the deployment. That won’t work in production against important, live data. Instead an incremental update is needed. By starting with the production process, you will build your process in a way that can be used across environments from the start.
 
Failing to engage Development, QA, and Release Management: Deployment automation serves many constituencies. Understanding the needs of all these groups is critical to building a solution that will be used rather than circumvented or duplicated.