As the number of components that organizations have to manage throughout their application delivery process grows, companies are looking to get more from their application release automation (ARA) platforms. These platforms can help organizations automate the process of releasing software applications and may include tools for managing code changes, deployments, testing, and other aspects of the release process.
Today, nearly all (90.5%) organizations are releasing features with a lead time of a month or less, which increased by 26 percentage points from 2020. In addition, organizations that are delivering features in 1-2 weeks doubled between 2020 and 2021, according to IDC’s U.S. Accelerated Application Delivery Survey from January 2022.
Pushing applications through to production has led to many difficulties for organizations, from consuming a lot of time to resulting in a lot of errors, especially when there are a lot of applications to release.
“Enterprises are now looking to automate the deployment of applications that have a hybrid tech stack, as well as multiple microservices with heavy version dependencies,” said Ryley Robinson, product marketing manager at HCL Software. “For example, this can be a single application with some on-prem deployments, legacy deployments on mainframes, IBM iSeries, and some cloud deployments across different hyper scales.”
On top of that, enterprises want to do all-or-none, canary, blue-green, rolling, and/or A/B deployments – all from a single ARA solution.
“Organizations have automated most of their deployment processes, but they still need to understand that organizations always go through modernization initiatives on their business-critical applications to remove the technical debt and to get the benefit of the latest innovations in the technology world,” Robinson said. “So, release automation is not something that is ‘done once and forget it.’ It is an ongoing process that evolves every week, every month. It is still automated, but there is still a lot to do.”
Three areas to start ARA
Despite its name that suggests its position at the end of a pipeline, release automation can excel in three different areas, according to Colin Bowern, senior vice president of product at Octopus Deploy.
The first is the whole non-production flow, which is where a lot of people get started with release automation. Errors here will have a minimal impact if one gets it wrong.
“This is stuff that you do on a very regular basis, and if you’re coming from a world of manual steps, or fragile scripts, it’s like, boy, it would be a whole lot easier if every time I commit a change to source control, it gets deployed out to a test environment,” Bowern said. “So for a lot of folks, this is the safest way that you can get started.”
Production, on the other hand, tends to be the second stage, but it’s also where the greatest ROI on release automation comes from, according to Bowern.
Before release automation, all of an application’s stakeholders had to be on deck for the release in case something went wrong.
The goal of ARA is to make application releases as orderly and stress-free as possible. After all, the process used to deploy to production is the same as the one used to deploy to non-production environments,, Bowern added.
ARA can automate all of the things that happen on an ad-hoc or scheduled basis around an environment, such as running the troubleshooting, resetting databases, or running scripts.
While adoption of ARA still has a long way to go, many organizations that decide to leave their manual ways behind first have a bad deployment and realize that they’re down in the pit with an hours-long, human-error-prone process and think there has to be a better way, Bowern said.
Others decide that they can just use their CI workflow automation tool because it does the builds and the tests. “While it’s a great place to get started when things are very simple, CI tools don’t understand environments. They don’t understand how to do rollbacks. To work around this, teams will kind of get some consistency by creating reusable workflows, but all of that custom logic and variables and stuff like that creeps in, and it becomes really hard to reuse across projects and is hard to maintain,” Bowern added.
The third scenario is that people come from stack-specific CD tools such as Kubernetes or Argo, or any tools that were purpose-built for an environment and do it really well.
“These are great quickstarts to help you do the right thing early inside your stack, but they were designed for that stack and that stack alone, and if you want to deploy your wider enterprise portfolio of apps, you won’t do that on Argo, or if you do, you’ll have to hack around it to make it happen,” Bowern said.
Many organizations have to juggle multiple tech stacks, data centers, and multiple cloud providers, so ARA helps to work around some of those stack-specific tools and ensure compliance on deployment type, whether it’s .NET, Java, node, VMs, containers, or serverless, Bowern explained.
“You can find out whether you need to improve flow just by going and talking to the engineers on the team. The question I love to ask is if I needed you to deploy something to production today, a small change that was blocking the business, is that a big deal?,” Bowern said. “If the answer is yes, which you’d be surprised to find can be ‘I have to go sign off on this form’ or ‘I have to schedule this window,’ that’s the thing you need to first get rid of so you don’t have that friction and can go on your improvement journey.”
Moving forward, ARA vendors are looking to incorporate or expand on existing AI/ML to handle tasks ranging from automatic code generation with tools like GitHub’s Copilot to testing and deployment to help address increased software velocity and the complexity of multi-modal deployment platforms, according to Melinda-Carol Ballou, research director of Agile ALM, Quality, and Portfolio Strategies at IDC.
How microservices affect ARA
ARA has turned out to be particularly useful alongside the growth of microservices, Octopus Deploy’ss Bowern explained.
“We’ve certainly observed and we hear this because teams started asking us for dependency management, ‘How do I make sure project A doesn’t go out the door before project B?’ And so we see people struggling as they adopt microservices to get that true independence model, and they end up trying to orchestrate different components shipping at different times,” Bowern said.
Some companies decide that the added complexity that comes with microservices is not worth it, and they instead embrace the monolith where all dependencies are synchronized because it’s all shipped as one big box, according to Bowern.
Microservices need the concept of snapshots where different versions of different microservices are grouped and tested. A good ARA solution should be able to guarantee that a snapshot containing dependent versions of microservices gets deployed properly and should also be able to assure that what is tested together is deployed together, according to HCL’s Robinson.
ARA is a process within continuous deployment
The process of ARA is a vital part of continuous deployment, which should be treated as a set of philosophies and principles, Octopus Deploy’s Bowern said.
Continuous delivery is all about not letting changes sit idly so that they build up into big batches. It says that you’re reducing risk by releasing regularly into the various environments along the way and getting changes moving.
“And so if you take that as a philosophy, release automation is a really critical tool in that, because you can’t get that speed and do it manually,” Bowern said. “We continually hear from customers that it takes them hours to deploy because it’s not just copying a binary to a server.
It’s all the steps you need to do to migrate to the database, or bring a load balancer down, and these are all the same things you did last week, or yesterday, or last month. And so automation is truly a part of living that philosophy of continuous delivery, not whether you deploy to production every day.”
Effective ARA relies on visibility into what’s happening in requirements, development and testing, according to HCL’s Robinson. On top of that, teams need data from quality assurance products like functional, performance, and application security.
A strong set of plugins can help release managers make the go/no-go decisions. Instead of having multiple manual checklists in spreadsheets, if the release management solution can provide automatic gating based on quality criteria by pulling data from multiple sources, it makes it easy to release software with confidence, Robinson added.
ARA is also a vital component of value stream management (VSM) where there are huge benefits to having one orchestrator across different middleware, Robinson stated. This can make it easy for the development and operations teams to get going on day one using pre-built templates instead of spending time automating release management for each application.
ARA tools come with some challenges
However, release automation tools don’t come without some challenges.
There is a lack of standardization in the field and no one-size-fits-all release automation tool. Each organization has different needs, and no one tool can meet all of them.
Companies that have stalled in the middle of their DevOps journey have failed to address or understand the cultural, organizational, and process changes required to adopt a new way of working with technology.
These companies invested in automation, with 67% of mid-evolution respondents to Puppet’s 2021 State of DevOps report saying their team has automated most repetitive tasks. But, as an organization, they haven’t addressed the silos and misaligned incentives around deploying software to production that gave rise to the DevOps movement, since 58% of companies reported that multiple handoffs between teams are required for deployment of products and services.
However, the biggest barriers are often cultural and organizational, because effective release automation demands a transition to continuous, agile approaches to development and release management, according to IDC’s Ballou.
“That transition involves a significant shift in how people do what they do, and human beings are way more wired for consistency than we are for change,” Ballou said. “The coordination between business stakeholders and those creating the software enabled by effective agile approaches brings greater relevance to what is deployed.”
DevOps engineers have to get the balance right
Whereas developers are usually at the forefront of adopting ARA on the non-production side, when things get more complicated with the service management system, that’s when DevOps engineers typically come onto the scene.
“They’re a little bit developer and a little bit SRE and their job is to come in and be those experts that help teams go faster on this because teams aren’t used to automating, they’re just used to cutting code,” Octopus Deploy’s Bowern said. “So the DevOps engineers have the kinds of skills that say that my job now is not to understand how to architect applications, but how to get things moving faster.”
Many organizations have a centralized DevOps Center of Excellence (CoE) that maintains the templates for different ARA strategies and the individual application teams benefit from these templates with enough space to do their customization when needed. There is also a huge benefit in sharing the learning across teams in an enterprise and CoEs help with that.
