simplify your approach to database change, accelerate the database deployment process

• Treating database code like app code

Problems

• 57% of all application changes require a corresponding database change. all of these changes are typically reviewed by experienced database administrators (DBAs) to ensure that the database changes won’t affect the app’s performance, security, or integration of data.
  • Developers understandably get frustrated because the code they wrote a few weeks ago is still in review.
• SQL is not a developer favorite (consistently making StackOverflow’s Most Dreaded list)
• DevOps ignores data professionals.
  • Reason 1: with the adopting of Agile, companies have ceded that responsibility of deploying database changes to the development and test team. The Data Group being completely cut out of data architectural decisions as they must simply accept the changes as requested by the development team. The release teams use deadline pressure to force the Data Group to make the change anyway
  • Reason 2: To introduce the idea of handling state for the persistence layer is often dismissed out of hand, since it is hard
  • Reason 3: Data professionals have different goals than developers. (maintain stability, integrity and security vs change)
  • Reason 4: Data Professionals do have a well-deserved reputation as Dr. No.

Solutions

• Provisioning data for application testing
  • always latest production (real) with automatically masked data.
  • tool: https://www.delphix.com/
• Data persistence in continuous deployment(CD)

Ref

https://www.liquibase.com/resources/guides/database-devops