Continuous deployment

Continuous Deployment – The Final Step of Continuous Delivery

Next Story

Social Media - The Teenager's Dilemma

We are almost there.  Agile practice has driven the adoption of continuous build orchestrated by a continuous integration workflow.  Continuous build has led us to continuous test now driven by the continuous delivery pipeline.   The final piece of the puzzle is continuous deployment.

Continuous build and continuous deployment have some factors in common.   The build and deployment steps of CI are often driven by one-off scripts crafted by a developer who really understands how the application is assembled.  If you know how to compile your application you have a clear understanding of how to deploy your application.  For this reason developers will often add deploy logic into the build script that is called by the CI workflow.  Alternatively, they will create a separate build script that is called after the build. But this is not a continuous deployment solution.

Solving the challenge

Solving the continuous deployment challenge requires an unbiased analysis at the script driven deployment process.  Developers who create deployment scripts often invest a good amount of blood, sweat and tears in the process. So taking a step back and really analyzing the process can be difficult.  No one wants their ‘baby’ to be called ugly.  The most critical part of this unbiased analysis is to look at the complete deployment picture, from dev through prod, and how that picture changes across the life cycle.

Important in addressing continuous deployment is to stay mindful that development, testing and production environments are ‘mixed.’  None of these environments look the same.  Development teams will add ‘deployment’ logic to their build scripts to support a limited number of end points, possibly a database server and an application server.  When the CI workflow executes, the ‘build’ script creates the binaries and on success moves the binaries out to the end points.  The build and deploy process is one in the same. This is completely adequate and quite efficient for development.

Testing requirements

Next up is the testing team. Testers are beginning to embrace continuous test and therefore want the continuous delivery pipeline process to ‘push’ new updates on a more frequent basis. Tester’s will often call on the development team to write the testing deployment scripts.  This environment can look very different from development in terms of size and often technology.  The use of Docker containers or VM images are favored by testers as it accelerates the ability to start up a ‘clean’ environment and support many testers working in independent silos.  Seldom does testing re-compile the code so the development script is modified to only execute the ‘deploy’ step and adjusted to conform to the testing environment requirements.

And finally, the continuous delivery pipeline needs to ‘push’ the deployment to the production environment upon a successful test workflow.  This is ultimately the goal of agile and purpose of the continuous delivery pipeline.  Some organizations do not believe this to be possible because neither the development nor testing scripts can support the production environment.  So yet again a new script is required.  And this is where agile stops and the waterfall practice persist.  Production deployments require the coordination of multiple applications, running on multiple end points, database updates, router configurations, IT stack updates scheduled around routine end point maintenance. Production teams will develop their own process mixed with scripts and manual steps to deploy the application on their own time frame, which is most often not iterative.  The result is great code languishes in ‘staging’ areas.

Continuous deployment needs more

In essence a scripted deployment process is static.  Continuous deployment needs more.  A continuous deployment process should be dynamic and adapt to changes across the lifecycle without impacting or modifying the underlying logic.  To do this, your deployment process must manage the IT stack, the database and the application stack without binding the environment variables and configurations (number of end points and type) to the scripts themselves.  Tooling is the best way to achieve this.

Continuous Deployment

Automating the continuous deployment process with tooling vs. scripting is key to a successful continuous delivery pipeline. But it is also critical to consider the human and cultural elements.  Because the production team has all of the responsibility in managing the production environment, it is important to understand what will drive them to adopt improved automation.  Production teams who are faced with supporting agile teams are being asked to substantially increase their work load.  In the waterfall approach, production teams could expect a new application release every 2-3 months. In agile they are being asked to push a release on a much more frequent basis, weekly for example.  If you do the math you will quickly see their challenge.  For a mid-size company with 50 agile application teams, production must support 50 application releases per week but they are only staffed to support 50 application releases every 2-3 months. Their timeline has been seriously compressed.

Moving towards agile

In order to help move the production team towards agile, they must see the benefits of tooling a continuous deployment process driven by the continuous delivery pipeline.  The best way to achieve their buy-in is one application team at a time. Moving production to a continuous deployment cadence can seem overwhelming if the problem is looked at as an ‘all or nothing’ solution. This is a very common mistake.   Like the idiom, ‘how to eat an elephant’ this problem is best approached in smaller pieces.   For this reason the continuous deployment solution should itself be light weight and low cost in order to reduce the risk of entering this level of corporate process change.  Reassuring the production team that they will continue to manage the production environment with added visibility and control of what is coming down the pipeline is ultimately what they will need to move them to leaner datacenter methods.  Small successes will get you there.

The following two tabs change content below.

Tracy Ragan

Tracy Ragan is COO and Co-Founder of OpenMake Software. Tracy has extensive experience in the development and implementation of business applications. It was during her consulting experiences that Tracy recognized the lack of build and release management procedures for the distributed platform that had long been considered standard on the mainframe and UNIX. In the four years leading to the creation of OpenMake Software she worked with development teams in implementing a team-centric standardized build to release process.