Breaking Barriers to Continuous Deployment
Whatever your app, break free of traditional approaches so you can get more done, easily.
Continuous Deployment is a key requirement of your continuous delivery pipeline. The ability to deploy code continuously across development, test and production environments makes or breaks your continuous delivery strategy.
But getting started is hard.
Most organizations struggle with defining a continuous deployment process that supports testing and production as easily as it does development. This article discusses major challenges that block a successful continuous deployment strategy, and shares must-have requirements to support all lifecycle states for continuous delivery.
Business-As-Usual Falls Short
Traditional approaches to both compiling and deploying code are neither fast nor frequent. Using the traditional approach, software build and release might occur monthly at the development state, six times per year at the testing state, and two times per year at the production state.
With such a slow cadence, developers, testers and production teams had the time to write one-off scripts and tweak the scripts as they moved to test, while production maintained their own one-off scripts for the production move.
Agile Changes Everything
With Agile comes the goal of shifting from bi-annual monolithic software updates to iterative and frequent software releases — a big change for all teams. Developers embraced these lean practices with open arms. Continuous integration servers like Jenkins replaced the need for an individual to stare at a monitor and run a set of checkout, build and deploy scripts, while reading the execution order from an Excel spreadsheet.
The calling of scripts is now built into a job to ‘automate’ their execution in the correct order and to centralize the logs. Some testing teams have adopted their own continuous integration workflows to checkout binaries, copy binaries to test servers, and execute more complex testing processes. Greater ‘automation’ is possible when using continuous delivery on top of your continuous integration process to execute the test workflow after completing your development workflow.
Progress indeed, but much remains wrong
Although script execution methods are now automated, scripts themselves remain the same processes used in waterfall. Only a small handful of developers manage the build, deploy scripts, and handhold testers to make sure scripts are up-to-date. Often, production teams continue to manage their own production release processes. These build-and-deploy steps are not repeatable between the mixed environments.
The result: Great code languishes in production staging areas, and the full benefits of agile are not recognized.
Mastering Agile’s Last Mile
Recognizing the full benefits of agile means production teams get code updates to end users at a pace that matches development release cycles — or come close, at a minimum. For this to work developers must push their ‘release candidates’ to test faster. Testing must quickly push approved versions to production. Continuous testing helps, but the real bottleneck organizations face is deployment.
Why is this?
Reasons are many. Deployments are complex, and become more so as they move through the life cycle. Test and production environments are intricate, so database updates and IT configuration management must be coordinated.
Moving to full continuous deployment requires moving away from waterfall scripts that your current processes use. Across the lifecycle, all teams must be able to execute the same deployment process — and scripts are a big barrier. While scripts may move code from point A to B, they don’t have the intelligence that Application Release Automation (ARA) solutions offer. Testing and production teams need ARA features to quickly approve code across the continuous delivery pipeline with full transparency and shared control.
Minimum Requirements for a Continuous Deployment Solution
Safe Agentless Architecture
Your continuous deployment solution should support a rollout of just one project team at a time. Legacy solutions that use a ‘one ring to rule them all’ approach are anything but agile.
Since Agile practices should make it easy for testing and production teams to adopt the developer-defined release logic, your continuous deployment solution should not require that testing or production environments be re-configured with special endpoint agents.
Endpoints are often a showstopper at the testing and production levels. Agentless solutions place dramatically less demand on testing and production teams so a standard release process can be adopted across all environments.
No One-Off Scripting
Any viable ARA solution should minimize one-off scripting. Scripts should be reusable between similar development teams, and across testing and production. Tools with graphical blueprint designers make it easy for everyone to understand how an application is deployed.
In this world, variables needed to support mixed environments must be separated from the application package to eliminate need for manual intervention.
Collaborative Release Process
Yes, this word is overused, and it should be. Agile principles can be hard to achieve, especially in larger enterprises. For example, a project team might not include a full-time tester or production manager, sharing the resource with others. These groups often sit outside of the development organizational structure.
Your ARA solution must give developers a ‘self-service’ experience, while still allowing testing and production teams to share deployment knowledge, control and responsibility. This early collaboration gives both testing and production teams more confidence in which code updates are coming.
While continuous integration and delivery are important steps forward, critical barriers prevent deploying code updates to testing and production.
ARA solutions are useful antidotes, but many fall short of requirements needed to master agile’s last mile. Specific capabilities must exist, like agentless architecture, graphical blueprint designer, and support for a collaborative release process for developers, testers and production teams.
Only then can you release great new code to your end user faster.
About the Author
Tracy Ragan — COO and Co-Founder, OpenMake Software
Ms. Ragan has had extensive experience in the development and implementation of business applications. It was during her consulting experiences that Ms. Ragan recognized the lack of build and release management procedures for the distributed platform that had long been considered standard on UNIX. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution, and DeployHub the first Open Source ARA solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.