The Database is Your Number 1 Bottleneck to Agile Development — Here’s 4 Reasons Why
Yaniv Yehuda provides four solid reasons why the database is your number bottleneck to agile development.
Join the DZone community and get the full member experience.Join For Free
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?
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 from Daniel Norwood 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 deploy 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 tests and staging environments to avoid invalidating tests in those environments. This further complicates and slows an already complex and tedious process.
It’s not enough to enforce source control for database objects, ignoring the meta-data that influences application behavior, and can create equally frustrating conflicts in different environments and deployment phases. DBmaestro TeamWork enables enforced source control for the entire database–schema objects (table structure, columns, indexes, foreign keys, etc.), database code (procedures, functions, etc.) and meta-data (parameters tables, lookup content, dictionary tables etc.), all using the same check-in, check-out process that prevents out-of-process changes and conflicts resulting in the overriding of objects or data that should be protected. DBmaestro ensures that due process and development best practices are followed.
This process allows you to leverage a single source of truth for database safe deployment automation. And by correlating the check-in with a specific task, it’s no longer a mystery which database changes relate to which tasks. Information regarding changes is saved in the repository, allowing the retrieval of only relevant changes and objects when building a list of tasks.
Download our white paper: Database Version Control- The Cornerstone of Continuous Delivery
By utilizing SQL Server version control, development teams are able to perform comprehensive roll back and keep track on object versions and revisions, seamlessly and efficiently.
Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.