Intro to Application Release Automation
Application release automation (ARA) provides automation and orchestration to package and deploy application code as it transitions from development through to production.
Businesses are being pushed to respond to market feedback and deliver new experiences to end users faster than ever. To remain competitive in these new market conditions, teams have turned to application release automation software to speed up delivery. By leveraging application release automation, organizations can easily handle fast software delivery and updates and decrease human error, missed steps and potential production issues.
ARA tools seek to bring visibility and speed to the slow and complex software release process. While there are many build automation, test, and deployment tools available, modern software delivery remains slow and difficult to track. This is because build automation, test, and deployment tools are loosely – if at all – integrated with each other. There are review and approval processes, as well as and sign-offs between steps. It is easy for teams to lose sight of the state of the overall application release in these handoffs. ARA is needed for teams looking to bring visibility into approvals processes while tying together different platforms and tech. By using ARA software, it is hoped that teams can improve the quality and delivery of applications and software.
An exceptional application release automation solution will do more than just improve the delivery process. It should be a fundamental piece in ensuring continuous delivery by allowing teams to maintain audit records, manage deployment access rights and more.
Application Release Automation Guide
Step 1: Database code is developed and checked into source/version control systems like Git, SVN, TFS, or similar.
Step 2: Jenkins (or other CI tool) calls Liquibase Enterprise to validate database code against rules in the Rules Engine. When validation succeeds, Jenkins calls Liquibase Enterprise to produce an artifact that is then stored in a repository like Nexus Sonatype or JFrog Artifactory.
Step 3: XL Deploy pulls the latest artifact and uses Liquibase Enterprise to deploy to DEV using XL Release as the orchestrator.
Step 4: After XL Release validates the DEV deployment, XL Deploy uses Datical to deploy the artifact to QA.
Step 5: After XL Release Validates the QA deployment, XL Deploy uses Datical to deploy the artifact to Prod.
How Can ARA Speed Up My DevOps Team?
DevOps teams need transparency and automation to deliver high-quality application code faster. Application Release Automation tools orchestrate the entire software lifecycle to provide all application team stakeholders with the transparency they need. Without an ARA tool, organizations can fall prey to optimizing individual segments of the software lifecycle and ultimately still fail to realize the velocity
and quality benefits of DevOps.
Additionally, by orchestrating the steps in each stage, ARA solutions foster greater collaboration between teams and necessitate a clear definition of the inputs and outputs of each stage of the software lifecycle. Effectively, ARA tools bring transparency to otherwise tribal processes and reshape the entire software release process. Teams can no longer keep a myopic perspective of their specific area – be it the build process, automated validation, or something else – but instead, start to think in terms of their contribution to the larger pipeline. By using ARA, DevOps can work alongside other teams with a collaborative and unifying tool to automate processes across the whole lifecycle and transform software delivery into a high-performing solution. ARA brings the much-needed structure and visibility required to accelerate release velocity.
Application Release Automation Tools and Vendors
There are many ARA vendors and tools available. Some popular tools include:
| ARA Tool | Vendor |
|---|---|
| XL Deploy & XL Release | digital.ai |
| Visual Studio Release Management | Microsoft |
| Deployment Automation (formerly Serena Deployment Automation) | Micro Focus |
| CA Release Automation and Automic | CA Technologies |
The Evolution of Application Release Automation
Quick. Draw the simplest diagram of your application architecture.
I bet it looks like three blocks: one connected to another with lines. Those boxes represent the
presentation layer, application layer, and database layer. It probably looks similar to this:
When we started to think about Application Release Automation (ARA) we wanted to speed moving the compiled code to a server. As applications have become more complex and interdependent, the term ARA has expanded to comprise many other tasks. As our deployments have changed, so should our concept, idea, and definition of ARA. These new tasks include (virtual/cloud) server provisioning, automated testing post-release, network changes (putting servers in and out of load-balancer rotation), and database change.
Just like the rise of Agile led to the need for ARA (frequent releases begat frequent deployments), Application Release Automation tooling itself is now leading to the need for database change functionality. With the increased need for collaboration between Dev teams, Release Managers and DBAs, it has become more important that tooling in processes are able to provide transparency and ease communication for all. If all team members can easily work together, your release and deployment cycle becomes a seamless, efficient machine.
ARA Vendors are starting to get it, but are still woefully behind
Additions to automation release tools have benefited a large number of users in customer installs. Things such as server provisioning, rolling updates, and even the beginnings of canary deployments leveraging automated testing tools and more. But there is one area completely neglected: the database.
Of course, there is some messaging around database change management. IBM’s UrbanCode describes their Deploy tool as: “IBM UrbanCode Deploy orchestrates and automates the deployment of applications, middleware configurations and database changes into development, test, and production environments.” Inedo BuildMaster does the same. When performing a demonstration, every ARA vendor will say they manage database change. However, look around the room and note the number of DBAs. It will be zero. The DBAs are not part of the DevOps Inner Circle. No one will perform a demo to the DBA team. Moreover, no one pushes to production using ARA tools today. As one Liquibase Enterprise customer put it: “Using ARA to execute our SQL scripts helped us destroy the database much faster than if we had done it manually.”
Top 4 Reasons to Combine Database Release Automation with ARA
Software is reshaping industries, from healthcare to finance to retail and beyond. The pace of change is accelerating, and companies must master their applications to survive in the digital era. In the software economy, speed is the new standard
To get a faster time-to-market, companies are adopting quicker, more iterative development methodologies. They have replaced age-old waterfall development methodologies with agile practices. From an infrastructure perspective, they have also invested in modern architectures and cloud technologies to achieve higher efficiencies. Some companies have even combined these 2 approaches by adopting DevOps—investing in new tools and processes such as infrastructure automation and continuous integration—to clock even faster speeds.
As companies have adopted application release automation (ARA) technologies to help increase software delivery rates, a new constraint has emerged: data. Data has long been the neglected discipline, the weakest link in the tool chain. In fact, most companies are still managing and deploying DB changes manually, anchoring development teams. Many organizations attempt to support modern, agile development environments with decades-old database management processes. The result is like mounting a modern Ferrari on Model T tires. It’s a great way to get nowhere fast.
The costs of ignoring the database release process accrue on many fronts. For your organization to survive, you must employ database automation. Let’s examine the impact upon four key areas.
1. Cost of Adding DBAs
Are you relying on DBAs for all release-related upgrades? Then you’ll need more DBAs as you increase the rate of application releases. If 10 DBAs can handle 100 changes per week, then you’ll need at least 20 DBAs to handle 200 changes per week.
And, as you hire more DBAs to keep up with the work, you’ll also have to hire more managerial people. You’ll have to devote more resources to support infrastructure. You’ll have to invest more in training. And you’ll have to account for the months/years of on-the-job experience that the 10 new DBAs will need to become as efficient as the original 10. The costs add up fast, especially compared to the substantially lower cost of scaling through automation
2. Mistakes and Increased Risk
No matter how large your staff of DBAs, you’re always just one human error away from a mistake. Every DB schema change review and deployment relies upon the skill, reliability, and dedication of a human.
The result is the inevitability of mistakes and less-than-machine-like reliability. The carryover can be an application that significantly underperforms or mis-performs, or that crashes altogether.
The human touch also increases the risks to data integrity and security. For example, grants embedded in stored procedures offer a huge opportunity for human error. Either that or malicious intent will happen to derail an application and expose its data.
