6 Best Practices for Application Deployments

Many software development teams are now working in an Agile/Scrum way and that’s great! One of the cornerstones of the Agile way of working is “Deliver value fast and often”. The real value is delivered only when the software is running in production (not Dev, not QA J).

Having right deployment principles and practices in place is all the more important in Agile environments because new increments are produced by scrum teams at the end of each sprint. A right deployment strategy is a key factor to have faster and effective feedback loops from each environment. Below are some of the best practices for application deployments.

You may also like: Deploy Your App in One Click

DeBuild Once Deploy Anywhere

Do you run into situations such as “Hey! It works on QA but not UAT or Prod”. One of the root causes of such situations is creating build artifacts for each environment. It is key to promote the same package which was tested in lower environments (Dev/QA) to later environments (UAT/Prod).

You will introduce unwanted risk if you build codebase every time to deploy to different environments as there is always a hidden danger of introducing unwanted changes. Automated deployments are very effective only when the same deployment package goes through different quality gates. If you change/build a deployment package for each environment, you are bypassing lower environment quality gates.

Hint: Use the same build package and promote it through all environments.

It Should Be a People First Process

Using the right tools for application deployments is important; however, focusing on tools alone will not help. Deployments are smooth when there is better collaboration between people who build the software and people who deploy the software.

When work is done in silos, the focus is narrowed which leads to expensive and time-consuming handoffs. Improving the speed of the slowest member of a convoy increase the speed of the whole convoy. In the same way, having better collaboration and elimination of waste during handover improves the deployment process.

Hint: Improve collaboration between Dev and Ops to minimize handovers.

Make Deployments Boring

Deploying to production needs not to be a ceremony. Production deployments need to be routine, boring events because the same process is used all along for each environment. New features you deploy to production should give you excitement but not the deployment process J. You will add unnecessary complexity if you customize the deployment process for each environment.

Hint: Use the same repeatable and reliable way of deployments to each environment.

Automate, Automate, Automate

Automate your build process, automate your application/component configuration (configuration as code), automate your infrastructure (infrastructure as code), automate your deployment process. A good rule of thumb: “Everything that does not require human judgment/intervention is a candidate for automation.”

Hint: Visualize your current end to end deployment process and identify quick wins and low hanging fruits to automation or to identify bottlenecks.

The Architecture Drives the Build

Batch size has a great deal of influence on flow and architecture influences batch size. If you modify or add one line of code, how big is the impact on testing, building and deploying the package? Follow standard design principles such as separation of concerns, Single Responsibility principle, Principle of Least Knowledge, Don’t repeat yourself and minimizing upfront design. As depicted below, if you have a spaghetti architecture deploying a change is expensive and time-consuming, so choose Ravioli

Hint: Choose a loosely coupled architecture and focus continuously on architecture refactoring

Manage Your Dependencies

One of the key challenges working in a distributed, multi-team environment is dependency management. There is a high need to ensure the easy distribution of artifacts produced by different teams as they share dependencies between them. Using a repository manager comes in handy in this situation.

It is also useful to define access rules for users and groups that consume artifacts so the consumer uses the right artifacts/versions. Other benefits of using a repository manager include the reduction of build time as a significantly reduced number of downloads off remote repositories. You can also use a repository manager in case you want to roll back to a previous version.

Hint: Always use a repository manager to manage your dependencies and version control your build artifacts.

Further Reading

The Next Generation of Java Application Deployments

DZone's Guide to Containers: Development and Management