Top Database DevOps Challenges and How to Overcome Them
Data shows that most application teams are not only thinking about DevOps, but actively adopting a DevOps workflow into parts of their business.1 Companies get it. They want to invest in DevOps practices. The latest industry survey shows that 52% of organizations have already adopted a DevOps approach. An additional 30% plan to adopt the approach to at least some projects. That’s 82% of organizations surveyed!1
Then you look at the database team:
- 92% report it’s difficult to accelerate the database deployment process2
- 91% have to rework database changes multiple times before they are ready for production deployment2
- 91% face challenges accelerating database deployment2
- 80% agree it takes longer to deploy database code changes than other changes2
So, what’s the problem? Why do many teams find it so difficult to modernize the full stack in pursuit of a tangible competitive advantage?
Top Database DevOps Challenges
It’s easy to assume that money is the main hurdle. This doesn’t seem to be the case. According to the 2018 State of DevOps survey, only 10% of respondents cited lack of budget as a barrier to DevOps adoption.1 Here are the main challenges preventing end-to-end DevOps at companies of all sizes:
1. Provisioning data for application testing
You’ve got a new feature to developed and you’re ready to go… except you need data. It doesn’t make a lot of sense to use just any old data. You’ve got to get as close the real thing as possible.
Using production data ensures that your code and data work together as intended. But most developers can’t (and shouldn’t) use production data. At least, not before it’s encrypted or masked. Regulatory and compliance requirements (and basic respect for data privacy) demand devs do better. It’s vitally important that all sensitive data is secured in all environments.
For many developers, this is how it goes:
- The developer files a ticket with the IT department, listing the resources needed (such as database access, a virtual machine with a certain operating system and system tools installed).
- The developer meets with IT to justify the resources.
- The developer waits for someone in IT to implement the configuration.
- The developer troubleshoots with IT because someone did something wrong. (For example, the wrong specs were provided).
- Finally, days or even weeks later, the developer has an environment ready for development testing.
- A month later, during the release, the developer discovers that a database change happened and their code doesn’t work.
It’s no wonder why so many developers resort to providing their own resources from the Internet or in-house systems, which is exactly what IT was trying to avoid in the first place.
2. Data persistence
In many companies, application code is in a CI/CD pipeline and is maintained through version control. When a developer submits new code, bam! New code can replace the old code. Then there’s the database. Continuous deployment isn’t as simple for databases. For a data store to be considered persistent, it must write to non-volatile storage. If the new feature in your application requires a change in schema, for example, you’ve got to migrate the data to a new structure. This isn’t done quickly, unless you have the right tools and processes in place.
3. So. Many. Tools.
There are amazing tools available to help make integration of a DevOps process easier. Unfortunately, it’s gotten to the point where there are so many tools, that it gets a bit difficult to keep them straight, make sure that they play well with each other and are future-proof. Adding a new tool over here can break something else over there. Or, maybe something wasn’t integrated properly? This can lead to a lot of churn and not a lot of work getting done.
The biggest challenge? In a word: people. Dev teams and operations teams have to overcome completely different approaches to development within these multi-functional teams. Synchronizing application and database changes is easier said than done. Every company already has a process for merging the two together. It’s usually not pretty, but you get used to it. It becomes part of your job. The thought of adding new tools and processes to an already difficult situation feels wrong. It feels like it’s adding complexity.
And that’s just it; people in this process are already stretched to the breaking point and are barely making their release cadence work as it is. It’s tough to imagine making changes. Feelings, in this instance, are overriding the facts.
How to Overcome Database DevOps Challenges
Implementing a Database DevOps process is proven to speed release cycles and reduce mistakes. So, what can your team start doing to overcome these very real challenges?
Start small (but think BIG impact)
In order to get over the fear factor of change, it’s best to start small. (Bonus points if you can find an application that makes a big impact.) Find or create a small multi-functional team and put them in charge of a small release. Have the team do it the old way first. Track everything.
Then, task the same team with tackling each of the challenges above head-on, starting with the suggestions below. Have the team try the new method for a couple of releases. Track the same metrics. Now, you’ll be armed with data about the speed and agility of this new way of implementing changes that will drop some jaws.
Smart, self-serve data provisioning
Self-service data provisioning tools can help IT admins avoid data breaches and noncompliance issues because it prevents developers from accessing systems they shouldn’t or taking data somewhere that isn’t permitted. And, ideally, the process is so much faster and easier that developers aren’t motivated to look at shadow IT options.
We recommend using a tool like Delphix for data provisioning. Imagine a world where your developers can provision data that’s based on real data, but continuously masked for security, in minutes to any environment—whether on premises or in the cloud. It’s a game-changer.
Smart database automation
Speaking of game changers, let’s talk about integrating database changes into your DevOps process and leveraging database continuous delivery. When some people hear “treat the database code like app code”, the knee-jerk reaction is “no! It’s different!” It’s true. They aren’t the same. But it is possible to put the database into source control and treat database changes in a similar way to application changes. There are a few additional considerations, like adding a migration script to enable existing data to fit in any changed schema, for example. But the idea is to automate these changes and put the database code into source control where continuous delivery is possible. When continuous integration of database changes happen along with the application code, you speed up your application delivery by orders of magnitude. (And it’s more accurate. And you’ve just built in an audit trail.)
New roles to support the new process
It seems like a no-brainer that implementing a completely new way of approaching application releases requires a new way of defining roles, but many teams overlook this step. There is no one-size-fits-all in figuring out which roles are needed for your specific application and industry. It requires a lot of trial and error to figure out what works and what doesn’t. Sit down with your newly formed team and talk about which tasks are needed in order to get this particular application released. Then, sit down and figure out where their skills and knowledge fit the bill and define their role.
Change isn’t easy. It may seem counterintuitive when you’re trying to deliver results faster, but it’s important to take time to listen and empathize with everyone on the team.
Make sure you put a system in place that allows everyone on the team to voice concerns. Everyone on the team needs to understand how the system will work so they understand how to bring up issues they encounter and what will happen next so that there’s a path forward to solving problems.
Some teams do health checks at the end of each sprint, where team members can rate their feelings about various factors including teamwork and support. Consistent negative ratings can tell you that there’s a systemic issue that needs attention. Managers can also specifically ask in 1:1s about how communication is or is not working to identify patterns.
Remember that it’s just the beginning
Transitioning to any new process can take some time. Remember that a journey of a thousand miles begins with a single step. Once you’ve successfully delivered an entire release, share what you’ve learned with other teams at your company. Results speak louder than words.
Want a dedicated team of experts to guide your team to Database DevOps success? Contact us and we’ll let you know how Datical can help your teams deploy database changes faster and safer.
1 2018 State of DevOps Report. Puppet.
2 Survey Results: The State of Database Deployments in Application Delivery. Dimensional Research.