DevOps attempts to bridge the gap between an enterprise's development and operations teams. But DevOps is not just about breaking down the silos between these two. For DevOps to be successful, you must evaluate each manual operation in the delivery pipeline for potential automation. This includes how you work with databases.
Fortunately, there are things you can do to facilitate collaboration between developers and database administrators (DBAs), to pave the way for database DevOps. Here are key strategies for—and challenges with—integrating database changes into a DevOps process.
Why you need database DevOps
Developers often must wait for database changes (done by DBAs) to be complete before they can proceed with their work. Such hold-offs—or time lapses, to be more precise—are costly and detrimental to the team's overall productivity.
This is exactly where database DevOps comes in.
A proper, planned approach toward integrating database changes as part of a DevOps process can accelerate the delivery of database changes and promote agility across the entire IT ecosystem.
Failure to include database changes as part of the DevOps practice may slow down your processes. DevOps practices facilitate shorter iterations and faster releases. In bringing DevOps to the database, you can have a leaner and faster development process.
Strategies and challenges
The objective of integrating database changes as part of a DevOps process is to increase the speed of delivery of any database changes. However, there are challenges also.
Deal with tightly coupled systems
Tightly coupled architectures with a central database pose challenges to database DevOps. Database coupling can be eliminated using a microservices architecture. Microservices are a suite of independently deployable services that are scoped to a business function, with each microservice having its own database.
These services interact with one another through well-defined interfaces rather than directly interacting with the database.
Version-control the database
In the traditional approach, the developers make the changes to the database when needed and write those changes, typically, in SQL scripts. DBAs then conduct reviews much later in the workflow, just before deploying those changes to production.
The painstaking process of deploying database change scripts just ahead of the release can create a problem, because it becomes too costly to make changes at this point in the cycle.
Version- or source-controlling database changes is the first and foremost step in introducing databases to the DevOps process. If your database changes and application code are in source control, you can have a working build anytime, you always have a version to roll back to, and you can maintain an audit trail.
When you are using an automated deployment pipeline, the deployments are typically linked to the source code in the source control. This helps associate the changes in the development branch of the source control to what has already been deployed.
Incorporating database development workflow as part of source control reduces task switching and improves efficiency. It also ensures that the database teams communicate changes with other teams. Hence it opens the door to continuous integration and, as a result, to productivity gains.
Use continuous integration and continuous delivery
Continuous integration is a practice that ensures that code and any related resources are placed into a shared repository at regular intervals of time. These check-ins are then verified using automated builds; this helps the teams detect problems (if any) early in the cycle.
Once source control is in place, continuous integration can trigger an automated build as soon as changes are checked in. This will enable you to get the errors (if any) from unit tests. If the builds fail, defects can be fixed and then retested, and then the changes can be checked in to ensure that a stable build is always available.
Continuous delivery is a practice in which the changes are built automatically, tested, and are ready for release. This implies that the software is always ready for release. Once the developers and the database teams work collaboratively and in parallel, it might well pave the way for more stable and consistent builds.
Implement release management
Making changes in a development environment may be easy, but pushing these changes to production is often challenging. This is exactly why a staging environment is used.
The staging environment hosts a staging database; it is nearly a true replica of the production database. This is where any database changes are pushed to before they are pushed to the production environment.
DBAs then review the changes and confirm whether they are production-ready. Once these changes have been approved by the DBAs, release-management tools can deploy the changes to the production environment.
Review changes early
Database changes should not be reviewed at the end of the workflow. Rather, DBAs should be involved early on to review the database changes. Also, the developers and DBAs should work together to make changes in the database when needed, review the changes, and incorporate them as part of the release.
Hence, there needs to be a well-defined process to which both developers and DBAs must adhere.
Use the right tools
When embracing DevOps, you should have the right tools in place to enforce the above best practices. There are plenty of open-source tools available, including Jenkins and TeamCity.
These tools can build and validate database scripts, run tests, and even sync a database with the source-control version. These tools can also be configured to publish the database package to a repository for deployment.
More best practices
A monitoring tool is a must-have; you need it to track what's happening with your databases in production. Monitoring databases is imperative to ensure that deadlocks or blocking processes don't affect database performance. Configure customized alerts to ensure that you are notified of any problems.
Maintaining persistent data while upgrading a database is also a challenge; you cannot just drop the connection and then re-create your database. For this, you'll need migration scripts that allow you to preserve data while the schema are updated.
Remember the database
Continuous delivery, continuous integration, automated release management—all these terms might sound complicated when you are first thinking about database DevOps. But there is no need for fear. Organizations can embrace database DevOps by encouraging collaboration between the developers and DBAs, choosing the right tools, and using strategies and tools for monitoring and version-controlling the databases.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
