The responses I provided to an "anonymous" media outlet series of queries on May 3, 2017:
Media: The place of databases in DevOps.
My responses addressed the more detailed questions as follows:
Media: How often is the database being changed?
Gfesser: The frequency of database changes will vary. As a general rule, there will likely be a greater frequency of changes earlier rather than later in the lifecycle of a given database. This is mainly due to the need to build out the initial structure of the database at an early stage, and a relatively slower trickle of changes at a late stage.
It is important to understand that there are 2 main types of change for traditional relational databases: (1) schema changes, and (2) data changes. Schema changes involve the structures and definitions of how data is structured, or processed programmatically via database objects such as stored procedures. Data changes involve the data stored in these structures.
Media: How does it fit into the continuous delivery model of DevOps?
Gfesser: I've written a 7-part series on my blog over the last several years as to how a freely available open source library such as Liquibase can be used within the continuous delivery model. This series was started at a time when only myself and someone from IBM had written anything of significance about it.
Since starting this series, I've used Liquibase for database change management on quite a few projects, and every time I've introduced it to a new client we need to go through a process where the client and / or staff (1) is introduced to it for the first time, (2) initially rejects it as being unnecessary or too complex, and (3) eventually progresses to acceptance, support, and oftentimes championing the related processes I have implemented.
Database change management is especially critical when a large number of database tables are expected to be created over time and / or a high degree of agility is needed for the development team. When an abstraction layer is used to access database tables, such as object-relational mapping (ORM), there is an additional concern: making sure this layer is kept in sync with the underlying database tables.
While many development shops still do not version their databases, doing so is critical to achieve team agility. As code is built using a continuous integration tool such as Jenkins, the database schema needs to change when there are dependencies between the code and the database structure. If these two areas of change are not kept in sync, the code will break.
For schemaless nonrelational database products, which are oftentimes considered schema on read rather than write because the data does not need to conform to a formalized structure, changes to the schema do not have this same impact. However, another issue has a potential to enter the picture: modifying queries throughout the code base. While these might not lead to breakage of the continuous integration process during build time, it will likely affect run time as tests are run during the process.
© 2009-2023 Erik Gfesser (Erik on Software)