Application Deployment 101

Learn all you need to know about application deployment with our comprehensive guide.

Table of contents:



1. What is an Application Release?

An application release involves the deployment of an entire application or its components to production, ready to be used by end customers. The completion of this process is a significant milestone for any business.

Application releases vary dramatically in complexity. A release can be as simple as one configuration change or a database update on a single server. However, a single release can also be extremely complex, necessitating the upgrade of an entire infrastructure for a multi-tier application which need to be distributed across global datacenters.

Releases pose a major source of risk for any business due to the alterations and instability that they bring into a production (IT Operations) environment. The production environment is vastly more complex than development and QA; various application components that are integrated in production are not even tested in other environments (for example: security considerations, load and external systems). This can lead to bottlenecks in production and costly errors.

Application releases are a critical business process which must be protected by the organization. Special considerations must be made due to the complexities of the release process and production environment. Solid communication is vital, as is the establishment of a reliable, standardized release process that can be easily documented, audited and rapidly performed.

Back to top

2. What is the difference between application release and application deployment?

As outlined above, an application release is the entire end-to-end release process and represents a significant business milestone.

An application deployment is a sub-set or a major part of this release, with elements which include where the files are moved and which parameters are configured. Application deployments comprise specific technical attributes that link back to build numbers and software versions, enabling traceability and audibility.

Application deployment processes are optimal for automation due to their repetitive nature. When executed manually, application deployments are excessively time-consuming and error-prone, thus further accentuating the necessity of automation.

Back to top

3. What is the staging area within an application lifecycle?

Most large businesses will implement a staging area in the application lifecycle, which typically runs from development through to QA, staging and production. The staging area (a subset of the pre-production environment) is designed to resemble the production environment where organizations can implement user acceptance testing activities. This enables businesses to identify potential problems before they go through to production.

The staging area is the final step before production and there is a solid barrier between the two environments. Applications can only be deployed to production during specified maintenance windows and after an update has been successfully tested in the staging environment.

Application releases should always be drawn from the staging environment to production. As applications can only be deployed during extremely limited time slots offered by maintenance windows (which are often just a couple of hours a week) and due to perpetually increasing changes in today’s agile environments, bottlenecks can often build up in staging. Establishing an effective, speedy and reliable release deployment process via automation is essential. If automated correctly, the bottleneck is relieved and application release processes are streamlined for even the smallest updates.

Back to top

4. How efficient are build tools in managing application releases?

Build tools construct and test software in multiple locations across the organization, facilitating fresh builds and the integration of changes into projects. Advanced build tools are referred to as continuous integration (CI) tools. Continuous integration tools can also monitor the execution of externally run jobs. In such cases, continuous integration tools execute consolidated software compilations, enabling easy management and a clear monitoring system. However, while some build tools do offer mechanisms for moving and copying files and directories, they do not provide a sophisticated and comprehensive automated release deployment management platform. Build tools do not provide built-in actions for heterogeneous environments. Many software applications run on numerous machines and there are many subtle variables when it comes to installation (i.e. configuring ports and permissions). Therefore, even with build tools, production teams must still manage different versions and ensure that scripts are written and properly maintained.

The staging environment is the final step of the lifecycle in which a build tool can be used. As it is primarily used as a development tool, it doesn’t respond to any of the production teams’ requirements. Build tools also do not offer advanced visual facilities, such as operations screens or dashboards, which enable users to clearly view and monitor the entire process.

Back to top

5. How are provisioning tools used for application deployments?

In contrast to build tools, provisioning tools are only used by production. Production teams primarily manage infrastructures and, as such, they are required to access servers from various locations in order to identify and configure relevant servers. In the past, this was done manually on every server - which was both time consuming and prone to errors.

Provisioning tools enable production to manage the servers through images. Each image (or ISO file) packages together various software components. The use of images in provisioning has been widely adopted and companies typically use standard images (also known as ‘golden images’) to ensure consistency and reduce errors in server provisioning to production.

However, although images are considered safe from a deployment perspective, they are inadequate for the agile requirements of the application lifecycle. As they offer a standardized ‘snapshot’ of numerous components, they do not provide a solution for constantly changing updates. These provisioning tools are designed to stay constant and static and are therefore unsuitable for dynamic processes. In this sense, although they are effective for infrastructure requirements, they are not suitable for application maintenance.

Back to top

6. What are application release parameters?

Parameter values relate to the specific, configurable data of any deployment that cannot be generalized (i.e. email addresses, IP addresses and server names). These parameter values must be added to every application release - either manually or automatically. Entering these values manually can be time-consuming and error-prone and an automatic system is therefore preferable. However, an effective automatic system must provide a robust way of both storing and distributing parameter values reliably and seamlessly.

Back to top