Skip to Main Content

Database CI/CD with the Oracle Database Operator for Kubernetes, GitHub Actions, and Liquibase — Take 2

Posted by [email protected] on December 03, 2025

Topics: Decision Making

Can you provision a database for my feature branch?”

This simple request used to trigger a 2–3 day process: create a ticket, wait for the DBA team to pick it up, manual database creation, configuration, connection details sent back, inevitably something is misconfigured, back to the DBA team…

By the time the database was ready, the developer had moved on to something else, context was lost, and momentum was dead.

We decided to fix this. What started as a simple automation project became a deep dive into Kubernetes internals, authentication patterns, and the challenges of managing stateful applications in cloud-native environments.

This is the story of that implementation — the problems we faced, the solutions we found, and the lessons we learned.
I presented this with a live workflow at the recent Oracle AI World in Las Vegas. See my slides.

The Problem: Development Database Bottleneck

Our development workflow was broken. We had three teams working on different features of our application, all needing their own database environments for testing. But our infrastructure couldn’t keep up:

For Developers:

  • Shared development database meant constant conflicts — your schema change broke someone else’s work
  • Manual provisioning took days, killing momentum
  • No two development environments were configured the same way
  • “Works on my machine” problems were constant

For DBAs:

  • Managing 15+ manual database requests per week
  • Tracking which database belongs to which feature in spreadsheets
  • Forgotten test databases are consuming cloud resources and budget
  • No standardization — every database was a snowflake

For the Business:

  • Features are taking 20–30% longer due to infrastructure delays
  • Monthly cloud bills included $5,000 in orphaned test databases
  • Production issues from schema changes that weren’t properly tested
  • Developer frustration leading to retention concerns

We needed a better way.

The Vision: Database-as-Code

The initial implementation was performed by Norman Aberin’s work; we envisioned a simple workflow:

  1. The developer creates a feature branch: feature/user-authentication
  2. Developer pushes code
  3. Magic happens
  4. 15 minutes later, they have a fully configured Oracle database with schemas deployed
  5. A developer works on their feature with an isolated database
  6. The developer deletes the branch
  7. The database automatically cleans up

No tickets. No waiting. No manual intervention.

Infrastructure-as-Code, but for databases.