Guardrails for CI/CD: Database governance for consistency, quality, and security

This is one section of our complete 12-part guide to CI/CD for databases - get your copy.

Database changes must be handled safely and with minimal human intervention to maintain their steady flow through the CI/CD pipeline. That requires a plan to ensure changes stay within known parameters and don’t clash with other changes or integrations, or otherwise misbehave and slow down the workflow - wherever they happen in the pipeline. 

By creating automated checks throughout the pipeline, you can ensure changes occur safely within the technical and business policies governing application and database development in your organization. This section will be talking about applying checks on both change batches and environments as changes are promoted through the environments on the path to Production. To be clear, these checks are looking at different, context-specific things that cannot be checked in the initial quality checks associated with CI that we discussed earlier. 

That requires constructs within the pipeline itself that channel the flow without constricting it. It can be helpful to think of this kind of database governance as procedural guardrails – like the metal barriers that signify a road’s edge and prevent catastrophe.   Unlike gates – another common industry metaphor – which can lead to backups as work piles up awaiting review, guardrails indicate and maintain the right direction without slowing momentum. 

Governance of databases and their change management processes is critical to achieve consistency, quality, and security while maintaining speed and efficiency. 

Creating a governance strategy

The trick with setting up governance for database change workflows in the CI/CD pipeline is to know where your delivery process needs them and where it does not. Given the variability among apps, architectures, technology stacks, businesses, and industries, you will have to do some analysis work to figure out the tricky parts of your particular CI/CD pipeline. 

That said, there are two common types of database governance that will almost certainly factor into your effort: Path Markers and Problem Stoppers. Path Markers, as the name implies, provide direction to the team members and create a clear delineation of the easiest and smoothest workflow that leads to successful change delivery. Problem Stoppers serve as safety points that ensure that if new changes deviate from the standards, they will be blocked from proceeding farther down the pipeline, made visible for the team to address, and will not be allowed to continue until remediated. 

Path Markers

In CI/CD terms, Path Markers will take the form of well-defined automation points or the handoff points between automation systems. For example, you might have only one source code branch that feeds the CI job that produces deployable artifacts in the rest of the pipeline. Path Markers should be clear and very simple to explain. 

Examples of CI/CD Path Markers include:

• If your changes are ready to be part of a batch progressing toward PRODUCTION, put them in this location
• If you do not put your changes in this location, they will never become part of any batch
• This is what the CI system will do with your change
• This is how you identify the post-CI artifact that includes your change
• Templatizing your standard automated processes with something like Liquibase Flows

With a clear set of statements, it is easy to communicate tasks and expectations — each of which are bounded by a set of procedural and technological constructs. Further, because the path is well defined, it is easy to identify where the flow of changes slows or encounters bottlenecks in the process. Those slow points and bottlenecks can be systematically improved over time based on measurable data about which ones will yield the greatest benefit.

Problem Stoppers

Problem Stoppers take a more active role along the workflow. Since their job is not so much to define the path as to ensure that people do not deviate from it. The mindset here should not be ‘enforcement’ - as most deviations will be unintentional. Instead the approach should be one of safe redirection back toward the correct change workflow or to the exception handling process. 

Examples of CI/CD Problem Stoppers include:

• Code scans or other quality inspections during the CI process
• Validating that batches of changes work before creating a deployment artifact for them – Verifying the checksums of deployment artifacts before deploying them
• Using Liquibase Policy (Quality) Checks to ensure the safety and compliance of your changes against your rules
• Actively refreshing environments to make sure they are representative of PRODUCTION

Problem Stoppers, largely because they are active, can be more visible and therefore perceived as more important

in the pipeline than Path Markers. However, the better outcome is that people should almost never encounter them because they have been given the tooling in the change creation process to create safe changes from the start. This is an important benefit of ‘shift left’, because when people do encounter a problem stopper, the rest of the people in the workflow will also experience delays while the problem is fixed. 

In fact, a closely related concept is that, if changes do keep triggering specific Problem Stoppers, the proper solution is to rethink the workflow so that the frequency of those problems decreases - ideally, to the point that the Problem Stopper becomes redundant due to a better “Path Marker” type mechanism earlier in the workflow.

Database governance places protective constructs along your CI/CD pipeline to ensure a smooth and safe path from change creation to eventual deployment into production. By carefully considering how to guide changes through a reliable workflow and redirect them when they get off course, this governance ensures trustworthy pipelines and  ensures that when trouble inevitably happens, it does not get out of hand.

Ready to dive into all 12 parts of the complete CI/CD for databases guide? It covers:

1. The goals & challenges of designing CI/CD pipelines
2. Batching database changes
3. Automating database “builds”
4. Ensuring quality database changes
5. Reliable and predictable database deployments
6. Trustworthy database environments
7. Sandbox databases
8. Database governance for consistency, quality, and security
9. Observability for database CI/CD
10. Measuring database CI/CD pipeline performance
11. Handling and avoiding problems with database changes
12. Bring CI/CD to the database with Liquibase

‍

‍