Your application developers have long been agile, and you’re trying to get your team on the path to agile database development so you can catch up. What’s causing the bottleneck?
Just some apples and oranges.
Most database development teams find their processes slowed down by a few important differences between application development and database development (especially relational database development). Here’s an overview of some of those differences:
- Overwriting. When app developers release a new version, then discover it has defects, it’s relatively easy for them to restore the old version and overwrite the new version temporarily. If you try restoring the previous version of a database and overwriting a more recent version, you’ll likely lose the changes to data (additions, edits, deletions) made in the interim.
- Version control. As a single source of truth, version control is indispensable to app development teams. In database development, however, the database itself is considered the single source of truth, yet there are different instances to manage (dev, test, prod, etc.). So, in a sense, “truth” here depends on context. Unfortunately, in spite of how frequently procedures and functions change, version control does not play the same role in the database world.
- Automation. App developers use tools throughout the deployment cycle and are accustomed to releasing entire code bases several times per week or per day because their deployment pipeline is fully automated. Database developers use scripts to update the database from one state (dev, test, stage, prod) to the next, manually promoting changes to mitigate risk.
- Urgent changes. When the business identifies a change that must be made immediately to a production application, the application team can implement it quickly due to the automation of their deployment pipeline. On the database side, where the deployment process takes weeks, database professionals will likely fast-track the change into production with limited testing. However, this creates upstream challenges for the database team as those changes must now be applied to each of the test and staging environments to avoid invalidating tests in those environments. This further complicates and slows an already complex and tedious process.
The apples and oranges of vastly different environments aren’t going away anytime soon, but you can work around them by automating as many of your traditional processes as possible.
We’ve put together a new e-book, Getting Agile with Database Development, to shed more light on the characteristics of database development that tend to slow it down. As you’ll see, using automation to shorten the database development cycle is the best way to close the gap with other development efforts and realize the promise of agile for the entire organization.