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 likely looks like 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, 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 Datical customer put it: “Using ARA to execute our SQL scripts helped us destroy the database much faster than if we had done it manually.”
Why did they neglect the Database?
Simply put: managing databases is hard. It’s even harder if you subscribe to a DDL/SQL only view of the world. Though, SQL is a programming language. It can be parsed and broken down into an object. That’s why Datical is superior to just throwing in SQL scripts into ARA.
Additionally, there tends to be some friction for different teams (DBAs, Devs, Administrators, etc) to collaborate with SQL, databases and servers. As the need to overcome bad institutional habits in favor of a highly collaborative environment rises, so does the need for tooling that can facilitate this shift.
Finally, DBAs don’t buy ARA tools, but they are impacted by them. It comes as a surprise that DBAs have not been included in product evaluations until recently. Had DBAs been included on these early on, the problem of leveraging databases in ARA tools would not be an issue today.
What happens if you continue to ignore the Database?
Complete. Stand. Still.
There are only so many SQL scripts DBAs can review manually and only so many they can execute manually. So, it becomes an issue of potentially needing to hire more skilled DBAs. In the current labor market, it might take a lot of time and effort to find the skills you need.
The other way you get a stand still is if you miss an error in SQL. You’re now down because you need to perform a full restore. Ugh! The time to modernize your database deployment practices is now.
What do you get when you bring the database into ARA?
Simply put, you get the full promise of ARA. See the recent Gartner ARA Magic Quadrant report to see the benefits of ARA. Of course, all of these benefits do not materialize until you have full stack automation, and that includes the database. Once completed, you will have push button deployments that speed your entire organizations drive to a digital future.
Learn more about the evolution of application release automation in our white paper.