Share →
Buffer

What is the difference between an application deployment and environment deployment? To some, it sound like the same thing.

The purpose of this blog post is to clarify the difference between “application deployment” and an “environment deployment”, as well as answer the question of “how each deployment practice fits into continuous delivery and improvement processes”.

Applies To

  • Release Management
  • Configuration Management
  • Build and Deployment Specialists
  • Operation

Prerequisite

  • Understanding of Team Build and Deployments
  • Understanding of continuous delivery and improvement
  • Working knowledge of Release and Configuration Management

What is Application Deployment?

This may be a straight forward questions to some, but without defining what an application deployment is, teams and individuals can become confused on where the application deployment begins and the environment deployment ends.

The application deployment is where a set of code (web, services, database etc…) is being installed onto a configured system(s) by some type of process. The process can be manual or automated. Automated deployment is preferred for a continues delivery model. Tools to help companies obtain an automated release process are Team Builds, NuGet, and Octopus deploy.

Where does the Application Deployment fit into a continues delivery and improvement flow?

It falls within the release management practices. When code is ready to be deployed to a configured environment, then the testing of that deployment process begins. The release notes for the application deployment begin at this point and matures as the release code is tested, adjusted, and prepared for a production release.

What is an Environment Deployment?

In the below explanation, environment deployment is used is the same way as an environment build out. In my experience the development and QA team expect target systems to be ready and assume that the system build-out would just be there.

An environment deployment (build-out) is where a server or a set of servers (environment sets) has the features, roles, applications and configuration installed manually or automated. Most of the time the operation teams are responsible for this build-out activity.  One problem I see over and over again is that application, database, and other teams do not notify the operations team of new settings and visa-versa. This leads to bugs and major blocking issues during a release.

Where does the Environment Deployment fit into a continues delivery and improvement flow?

The configuration and setup of the core systems fall within… yes you guess it… Configuration Management! Having tools, scripts, and workflow to build out an environment is key to continuous delivery and improvement.

Environment and configuration changes start at deployment and move through the release cycle in the same way as the application deployment.  In the reverse direction, operation, configuration management teams, or individuals can create a build-out script and workflow that creates a production like environment with the correct setting, features, and version of applications. 

The bi-direction exchange from development with the new environment build-out changes and the latest changes from production systems, provides each team the fast-feedback and transparency that helps improve the process. 

Conclusion

I realize that these two deployment types sound very simple and straightforward. However, often basic or simple concepts get assumed – we all know the saying about assumptions…. It is best to “nip it in the butt” before it gets to a more critical and costly state.

Having a clear definition of an application and environment deployment in your organization and each team can help reduce confusion between teams. Clarity provides the operation, build engineer, or whomever that is creating the environment build out with a better set of requirements needed for the application installation.

Who wants to be up at 2 AM trying to fix a bug after a release, to only find out that your missing the updated version of some 3-party software.  And, what team wants to be blocked by not having the correct version of the .NET Framework in Production.

The clear handoff and correct requirements for an environment build, reduces bug and blocking issues for the application deployment. It is also the beginning of best practices for release and configuration management.

Print Friendly
Tagged with →