DevOps is the process by which you identify and streamline your application development and release processes. The process part of DevOps begins with the identification of the parts of the development and release process that take the longest to complete, creating a bottleneck. Often, the database change process is the bottleneck.
That’s not surprising, because there are fewer tools to support DevOps for the database than for other applications. That doesn’t mean such tools don’t exist; it’s just more important than ever to pick the right ones for the job.
You can’t get the job done without the right tools for database development, application release automation (ARA), test data management (TDM), and database release automation (DRA).
DATABASE DEVELOPMENT TOOLS
You think of database development tools as DevOps tools, but it’s important that all of your tools are “DevOps-y.”
Agile begat DevOps. Without the speed and efficiency we received from agile software development, we wouldn’t have needed to create DevOps. Thus, bringing agile to the database is key to DevOps for the database.
Good database development tools reduce the time needed to implement and manage new and existing database platforms, and they leverage the expertise of database professionals by using extensive collaboration and automation features. This shortens development cycles while maintaining quality and security. Database development tools help database administrators (DBAs) support an overall business model that requires getting to market faster with more innovative and customer-focused products.
APPLICATION RELEASE AUTOMATION
Applications are complex, with many components. As you adopt microservices, containers, and other technologies that let you provide functional isolation and avoid single points of failure, you need ARA to orchestrate this complex process. As you move from “tribal knowledge” to scripts to deploy your applications, use ARA to tie all these steps together and ensure that they are completed successfully.
ARA automates the various parts of the application release process; it speeds the process while mitigating risk. It also ties together all the application release steps and ensures that each is completed successfully. That gives application developers visibility into deployment status, enabling self-service application deployments and reducing application deployment errors and costs.
That’s why ARA tools are an absolute necessity for DevOps.
TEST DATA MANAGEMENT
Now that you’re deploying your application faster, you need to ensure that your testing efforts are valid. The biggest problem with application testing is the lack of real-world data. Today’s applications change functionality based on the data stored in the database. So providing data that mirrors (or actually is) production data is key to having valid testing efforts. After all, your entire testing cycle could be invalidated by testing against improper data. And if that’s the case, there is no point in testing at all.
The solution is to use TDM tools. Since applications change their functionality based on the data in the database, TDM provides data that either mirrors or actually is production data, without requiring a database administrator or risking compliance issues. A TDM tool not only ensures greater development and testing efficiencies but also helps organizations identify and correct defects early in the development process, when they are easier and less costly to fix.
With TDM tools, application developers can populate test databases with production data, making them an integral part of their DevOps process.
DATABASE RELEASE AUTOMATION
Applications get all the glory, but what are they without the database? You will not be successful in a DevOps initiative if you neglect it. In fact, several DevOps leaders who have successfully implemented DevOps point to the database as a key post-mortem learning item. “In retrospect, I wish we had automated database deployments first,” is a common refrain.
As you evaluate your DevOps tooling, automating database releases is critical. A herd can only move as fast as its slowest member. For companies that use databases—and all do—the database deployment process is the slowest.
Automating database processes ensures that applications will actually work—no stored procedures that call to tables that don’t exist, and no changes that point a foreign key to a primary key that is not there. A DRA tool also addresses those pesky reconciliation issues created by TDM tools when changes are made to production data. They ensure that the original, correct version of the data has an up-to-date schema in which it can reside.
To bring DRA into your DevOps process, you need to follow four simple steps.
1. PICK THE RIGHT APPLICATION FOR YOUR FIRST DEPLOYMENT.
Choose one application project for the first deployment of your DRA too—but don’t pick just any app. Choose one that is representative of your other applications, but not the largest or the smallest. If the app is too large, it’s likely that it will be burdened with many organizational dependencies that may create a level of discomfort when targeting the app for change. But if it’s too small, you won’t learn much from the DRA implementation that you can apply to other applications.
You’ll also want to choose an app where the project is already inflicted with cadence mismatch—a situation in which the development team works at a pace that the database team can’t match. Choosing such a project provides a great demonstration of the benefits of DRA, since cadence mismatch will be eliminated. And if your organization is like most, you’ll have no problem finding a project that suffers from this problem.
2. ADDRESS THE MOST COMMON RULE VIOLATIONS.
Look for the rules, or standards, applicable to database changes that are most commonly violated and that frequently result in application release slowdowns. Then use DRA to eliminate those rules violations.
Here’s an example: Let’s say that you have a rule that restricts indexes to no more than three per table. Now envision a scenario where four applications use a shared database. One application team makes a change that requires adding a fourth index to a table—a rules violation that nobody catches. That change makes it to production, and application performance suffers. Your first deployment of DRA can be used to catch the most frequently deployed, chaos-causing violations before they can wreak havoc.
3. DON’T DEVIATE FROM YOUR ROUTINE.
One of the most important things to take into consideration when choosing a database release automation tool is the adaptability of the tool. The tool should adapt to you; you shouldn’t have to adapt to it.
Choose a tool that provides this adaptability and you’ll be able to carry on with your usual routine for making application changes. The tool won’t force the entire organization to change. If you routinely check changes into the same repository that your development team is using, continue to do so.
As for the tools you currently use for developing database change scripts, continue using them. You can keep using the same source code control, the same build server, the same test automation, and so on. The point is that, assuming you choose the right DRA tool, it will not force you to change how you currently do software builds and releases. The DRA tool will speed the process and eliminate chaos-causing database errors, but you will not be forced to deviate from your accustomed routines.
4. TRUST BUT VERIFY.
Once you’ve introduced DRA, you’ll be instantly relieved of burdens that routinely bring project timelines to a standstill. Automation will take over the chore of performing processes such as error detection, rules enforcement, change auditing, and others that were previously done manually. Human hands will no longer be performing these routine tasks, although humans should provide oversight.
While manual oversight of database deployments is no longer necessary, it can provide an additional level of comfort during the early days of DRA implementation. As you monitor the performance of DRA over a period of time, the team will gradually grow to trust that the tool always catches errors, enforces rules, and does everything it’s designed to do. Once the team reaches that level of trust, manual oversight will no longer be necessary, and you will have achieved true database release automation.
There are many DevOps tools out there from which to choose. Finding the ones that work for you will require evaluation and consultation with all of your team members. DevOps is a process to constantly improve and move faster. If you make a bad tool decision or simply forget key parts of your release process, you will not be able to improve or accelerate your application release process. And if the going is slow, why go at all?