Continuous Delivery strategy (see Glossary) takes its origin in start-up companies. The benefits of adopting Continuous Delivery principles are clear and plentiful. Continuous Delivery improvements in productivity are achieved through increased software deployment frequency and delivering new features to production in small increments, thus reducing the risks of production failures. The way Continuous Delivery is adopted in start-ups is organic and straightforward due to the greenfield nature of the development processes and the focus on a specific product or service. Enterprises, however, are a different story (see Figure 1). Enterprises, which often emerge as a result of numerous mergers and acquisitions, have decades-long lifespans, established cultures, policies and processes, and utilize diverse sets of software and hardware. There are concerns about how quickly enterprises can adopt new software development philosophies and strategies [Ref. 3]. Clearly, enterprises would get tangible benefits from adopting a Continuous Delivery strategy as start-up companies do. It is just that the path to adopting disciplines such as Continuous Delivery in enterprise organizations is likely to be different, transformational.
Additionally, an enterprise Continuous Delivery toolbox would likely reflect a more diverse set of requirements. I wrote “toolbox” and could immediately hear voices of many IT folks expressing their disagreement and pointing out that DevOps and Continuous Delivery are processes that require cultural and organizational changes rather than tools. That is certainly correct; however, enterprise IT initiatives must be aligned with business goals and organizational priorities. Hence, in enterprise environments, it may be more practical to start from introducing tools and technologies that alleviate existing enterprise pain points, deliver immediate ROI and lay out the foundation for adopting new collaborative strategies and methodologies rather than aiming for instant reorg and cultural changes. Extending your toolbox and adding new capabilities to expand automation of application deployments to improve speed of application releases and agility in order to get new features to production faster may be sensible steps toward starting the transition to Continuous Delivery. This article focuses on one specific area in the Continuous Delivery toolkit known as Application Release Automation (ARA) that helps you build continuous delivery pipelines by enabling quick and consistent deployment of complex, multinode and multiservices applications. (See Glossary for Gartner definition of ARA.)
Evolution of Application Delivery Automation
J. Humble and D. Farley stated that Continuous Delivery enabled by deployment pipelines should address “how all the moving parts fit together: configuration management, automated testing, continuous integration and deployment, data management, environment management and release management.” [Ref 2]. Consequently, enabling and optimizing Continuous Delivery processes requires a pretty extensive Continuous Delivery tool chain (see Figure 2). Continuous Integration servers such as the very popular open-source Jenkins are in the heart of these tool chains. Continuous Integration servers do a good job as the backbone of Continuous Delivery pipelines by providing automation for monitoring changes in source control systems, triggering new builds and scheduling testing activities. But the more we test, the more frequent we need to deploy. On top of that, real-life enterprise application releases are typically complex, time-consuming and often manual procedures. To meet business expectations and support agile development teams, we must transform manual, hard-to-maintain release procedures into automated processes that are tied to business needs rather than operational constraints. Also, we need to take into account that typical enterprise application portfolios consist of a wide variety of application architectures, ranging from plain vanilla, three-tiered applications to modern, microservices that run on various middleware, open-source and commercial platforms.
There is no shortage of technologies that may help to automate application deployments and releases. The earlier approaches were centered on utilizing various deployment and release scripts. The scripts were typically static and hard to maintain. In advance cases, scripts were parameterized, but nevertheless they remained specific to one technology platform. Additionally, scripts had to be supplemented by some sort of spreadsheets that mapped scripts to specific environments. Consequently, the next generation application delivery approach included Continuous Integration servers that acted as an orchestration point and triggered deployment and release scripts. Nevertheless, even with the introduction of Continuous Integration servers, IT organizations continued to be challenged to address the problems related to supporting:
• Consistent deployment and release processes across various platforms: Java and JEE, Microsoft, databases
• Deployment throughout the entire application life-cycle, across all environments ranging from Development into Test, Performance and Production
• Deployment of complex distributed applications, that consist of multiple modules or services developed and deployed separately across various environments or servers.
The latter is a particularly significant consideration since application architectures have a profound impact on deployment automation. Traditional multitiered applications (presentation, business logic and database) require deployments across multiple hosts. Service-oriented architectures and architectures that are based on service-oriented principles, such as micro services architecture (MSA), further increase the demand and complexity of deployment automation. Deploying service-oriented applications that consist of numerous services implies the following:
• Ability to deploy a large set of services in a particular order. The order of service deployment is often important.
• Ability to deploy/handle service endpoints configuration
• Ability to redeploy some of the services in case of a failure.