Agile Data Logo

Configuration Management of Database Assets: An Agile Core Practice

Follow @scottwambler on Twitter!

Data, and the assets surrounding the lifecycle of that data, are valuable assets for your organization. As valuable assets, they should be created, evolved, managed, and eventually retired appropriately. Or at least they should be. Configuration management is a critical aspect of treating database assets like true assets. This article overviews the technique of database configuration management.

This article is organized into the following topics:

  1. Definitions
  2. Why database configuration management?
  3. The process of database configuration management
  4. What database assets should be put under configuration management control?
  5. Database configuration management in context
  6. Related resources

1. Definitions

Let's begin with a few definitions:


2. Why Database Configuration Management?

There are several reasons why you want to put your database assets under configuration management control:

  1. Integrity. All work products should be stored in a versioned repository so that you know what assets are used to create the database and you have actual copies of them. This maintains the integrity of the database definition and all supporting work products as it evolves.
  2. Safety. You want to be able to restore your database to a known state. Not only does this include restoring the database itself, but all the accompanying assets associated with that version of the database.
  3. Evolution. Facilitates change in a controlled fashion, enabling you to safely evolve your database.
  4. History. All revisions are kept, including indications of who made the changes and hopefully why they made them.

3. The Process of Database Configuration Management

Figure 1 summarizes the primary activities of configuration management. Database configuration management is the CM of database assets. Note that a database asset may be comprise several component assets, which in turn may be composed of further sub assets. For example, the database model may be composed of a logical and physical model. The physical model in turn may be composed of a schema definition and source code files for each stored procedure/function within the database.


Figure 1. Configuration management activities.

Database configuration management

There are four primary activities of DCM:

  1. Asset change management. Control changes to a database asset and its configuration information. This includes the ability to check database assets in, check database assets out, and track any changes to database assets.
  2. Configuration identification. Define a database asset and its configuration information. Configuration information describes all of the aspects of an asset. This may include, but not be limited to, a description, change history, links to related (sub) assets, expiration date, references to where the asset is used, and more.
  3. Configuration status accounting. Provide status and information about an asset, including its configuration information. This should include the ability to provide the status of an asset at any given point in time, not just the current state.
  4. Configuration audit. Verify the consistency of an asset's configuration information.

4. Potential Database Assets to Put Under Configuration Management Control

To enable evolutionary database development you need to put the following items under configuration management control:



5. Database Configuration Management in Context

The following table summarizes the trade-offs associated with database configuration management and provides advice for when (not) to adopt it.

Advantages
  • Enables you to manage versions of databases, and the assets they are comprised of, across environments.
  • Enables you to rollback portions of a database to previous versions.
  • Enables you to modify work products in parallel and then merge the work.
  • Makes it easier to identify the source of defects injected due to the change history maintained about assets.
Disadvantages
  • Requires database developers to be trained in CM-related skills.
  • May require new tooling, in particular the CM system itself.
When to Adopt This Practice
  • For the development of any database that is expected to be evolved over time, particularly when this will occur over a long period of time, or by different people.
  • It is mandatory in regulatory environments that explicitly call out CM control of your assets.


6. Related Resources