DEV Community: dband drm

Deploy to Oracle with drm-cli + Flyway: A Step-by-Step Guide

dband drm — Wed, 22 Apr 2026 12:06:13 +0000

Oracle deployments have a reputation. They're slow to set up, painful to automate, and the tooling ecosystem tends to assume you have deep pockets. If you've tried to build a reliable Oracle deployment pipeline, you've probably hit at least one of these walls:

No consistent audit trail of what was deployed, when, and whether it succeeded
Pre/post deployment steps scattered across runbooks and tribal knowledge
Connection strings with credentials in environment files and CI/CD config
Multi-schema releases stitched together with shell scripts

drm-cli layers on top of Flyway or Liquibase — adding release tracking, encrypted credentials, retry logic, and pre/post deployment scripting. It's free and open-source, which means Oracle-grade deployment management without an extra licensing cost on the tooling layer.

This tutorial walks through a complete Oracle deployment using drm-cli + Flyway.

Prerequisites

Before you start, you'll need:

Python 3.7+ installed on the host running drm-cli
git to clone the repo
Flyway installed and on your PATH — download here
Oracle JDBC driver (ojdbc11.jar) — available from Oracle's driver download page
An Oracle database you can connect to (Oracle XE works fine for testing)

Step 1 — Install drm-cli

Clone the repository and run the installer:

git clone https://github.com/dband-drm/drm-cli.git
cd drm-cli
python3 ./install.py

The installer is interactive — it will prompt you for:

Installation path — where drm-cli will be installed (defaults to your home directory)
Encryption key — to encrypt sensitive data like connection strings at rest (optional but recommended)
Storage type — json (file-based, no extra dependencies) or sqlite

For a non-interactive install:

python3 ./install.py -d json -p none

(-p none means no encryption — use only for local test environments)

Once complete:

INFO - DRM installation finished successfully!!!

Step 2 — Prepare Your Flyway Migrations

drm-cli works with your existing Flyway migration scripts. Standard Flyway naming conventions apply — nothing needs to change:

my-oracle-migrations/
├── V1__create_accounts_table.sql
├── V2__add_account_status.sql
└── V3__create_transactions_table.sql

Example migrations:

-- V1__create_accounts_table.sql
CREATE TABLE accounts (
    account_id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    account_name VARCHAR2(100) NOT NULL,
    created_at   TIMESTAMP DEFAULT SYSTIMESTAMP
);

-- V2__add_account_status.sql
ALTER TABLE accounts
ADD status VARCHAR2(20) DEFAULT 'ACTIVE';

Note the path to this directory — you'll need it in the next step.

Step 3 — Configure Your Release

drm-cli stores all release configuration in a central database. Depending on the storage type you chose at install, this is either drm_db.json or drm_db.sqlite inside the db/ folder in your drm-cli installation directory.

JSON style

Open <install-path>/db/drm_db.json in any editor. Find the releases array and add your release with a solution and connection:

{
  "id": 10,
  "name": "oracle-release-v1",
  "solutions": [
    {
      "name": "core-schema-flyway",
      "solution_type_id": 3,
      "path": "/path/to/my-oracle-migrations",
      "connections": [
        {
          "name": "oracle-prod",
          "connection_type_id": 2,
          "connection_string": "url=jdbc:oracle:thin:@//127.0.0.1:1521/XEPDB1;username=deploy_user;password=your-password;"
        }
      ]
    }
  ]
}

Key fields:

solution_type_id: 3 — Flyway (use 2 for Liquibase)
path — the directory containing your Flyway migration scripts
connection_type_id: 2 — Oracle
connection_string — the JDBC connection string Flyway uses

SQLite style

Insert via SQL:

-- Add the release
INSERT INTO releases (id, name) VALUES (10, 'oracle-release-v1');

-- Add the Flyway solution
INSERT INTO solutions (id, name, release_id, ordinal, solution_type_id, path)
VALUES (100, 'core-schema-flyway', 10, 1, 3, '/path/to/my-oracle-migrations');

-- Add the Oracle connection
INSERT INTO connections (id, name, solution_id, connection_type_id, connection_string)
VALUES (1001, 'oracle-prod', 100, 2,
        'url=jdbc:oracle:thin:@//127.0.0.1:1521/XEPDB1;username=deploy_user;password=your-password;');

Step 4 — Run Your First Deployment

Navigate to your drm-cli installation directory and run:

python3 ./drm_deploy.py -c oracle-prod -r 10 --deploy

Parameters:

-c oracle-prod — the connection name you defined in the config
-r 10 — the release ID
--deploy — execute the deployment (use --dryrun to generate scripts without running them)

You'll see output as drm-cli invokes Flyway, captures the result, and records it:

INFO - DRM Deploy started
INFO - Running solution: core-schema-flyway
INFO - Executing Flyway migrate...
INFO - Flyway: Successfully applied 3 migrations to schema "DEPLOY_USER"
INFO - Deployment recorded successfully
INFO - DRM Deploy finished successfully!!!

That last line is what makes drm-cli different from running Flyway directly. Every deployment is written to the release history — timestamp, connection, release ID, outcome.

Step 5 — View Deployment History

After a deployment runs, drm-cli records the full event.

JSON style

Browse to <install-path>/deployments/. Each deployment creates a log file named:

Deploy_{GUID}_C{connection-name}_R{release-id}.json

Open it to see the full deployment record: every step, its start/end time, status, and any error messages. This audit trail lives entirely in your own infrastructure — no cloud service, no external dependency.

SQLite style

Query the deployments table:

SELECT d.*, ds.name AS status
FROM deployments AS d
INNER JOIN deployment_statuses AS ds ON ds.id = d.deployment_status_id
ORDER BY d.start_time DESC
LIMIT 10;

Step 6 — What Happens When a Migration Fails

If your network connection to Oracle drops mid-deployment, drm-cli retries automatically. Retry behavior is configured in drm_deploy.config inside your drm-cli installation:

"retry_attempts": 3,
"retry_delay_seconds": 10

With this config, a failed step will retry up to 3 times with a 10-second delay. If all retries are exhausted, the deployment is marked failed and the full error is recorded in the deployment log — so you know exactly what ran, what didn't, and when.

Step 7 — Encrypting Your Oracle Credentials

Storing plaintext connection strings is a habit worth breaking. If you installed drm-cli with an encryption key, use drm_crypto.py to encrypt your connection string:

python3 ./drm_crypto.py

The utility prompts you for your encryption key and the value to encrypt, then returns the encrypted string. Replace the plaintext value in your connection config with the result:

"connection_string": "url=jdbc:oracle:thin:@//127.0.0.1:1521/XEPDB1;username=deploy_user;password=ENCRYPTED_VALUE_HERE;"

drm-cli decrypts credentials at deploy time — they never appear in logs or trace output.

Using Liquibase Instead of Flyway

Swap solution_type_id: 3 for solution_type_id: 2 and set path to your Liquibase changelog directory. The connection config is identical:

{
  "name": "core-schema-liquibase",
  "solution_type_id": 2,
  "path": "/path/to/liquibase/changelogs",
  "connections": [
    {
      "name": "oracle-prod",
      "connection_type_id": 2,
      "connection_string": "url=jdbc:oracle:thin:@//127.0.0.1:1521/XEPDB1;username=deploy_user;password=your-password;"
    }
  ]
}

The deployment command is identical:

python3 ./drm_deploy.py -c oracle-prod -r 10 --deploy

What's Next

Week 6 — Pre/post deployment scripts: automating steps that always run before and after every deployment
Week 7 — Multi-database releases: SQL Server, PostgreSQL, and Oracle in a single coordinated release

The full source and documentation is at github.com/dband-drm/drm-cli. Open issues there if you hit anything unexpected.

drm-cli is free and open-source. No license tiers, no paid features.

Deploy to Oracle with drm-cli + Flyway: No Enterprise License Required

dband drm — Wed, 22 Apr 2026 04:23:07 +0000

Flyway's Oracle support is locked behind Flyway Teams
Liquibase's Oracle features are split across free and commercial tiers
Rolling your own with SQLPlus scripts works — until it doesn't, and there's no audit trail when something goes wrong
Connection strings with credentials scattered across environment files and CI/CD config

drm-cli doesn't replace Flyway. It layers on top of it — adding release tracking, encrypted credentials, retry logic, and pre/post deployment scripting. And it's free and open-source, which means Oracle-grade deployment management without an Oracle-grade price tag.

This tutorial walks through a complete Oracle deployment using drm-cli + Flyway.

Prerequisites

Before you start, you'll need:

drm-cli installed — installation guide here
Flyway CLI installed and on your PATH — download here
Oracle JDBC driver (ojdbc11.jar) — available from Oracle's driver download page
An Oracle database you can connect to (Oracle XE works fine for testing)
Python 3.10+

Project Structure

drm-cli works with a straightforward directory structure. Here's what a minimal Oracle project looks like:

my-oracle-project/
├── drm.yml
├── migrations/
│   ├── V1__create_accounts_table.sql
│   ├── V2__add_account_status.sql
│   └── V3__create_transactions_table.sql
└── drivers/
    └── ojdbc11.jar

Your migrations follow standard Flyway naming conventions — drm-cli doesn't change that. It just takes responsibility for the release lifecycle around them.

Step 1 — Configure drm.yml

drm.yml is the project configuration file drm-cli reads at runtime. Here's a working example for an Oracle deployment:

project: my-oracle-project
version: "1.0.0"

release:
  history_db: release_history.db    # SQLite file — stores your full release audit trail
  retry_attempts: 3
  retry_delay_seconds: 10

targets:
  - name: oracle-prod
    tool: flyway
    database_type: oracle
    migrations_path: ./migrations
    drivers_path: ./drivers
    connection:
      encrypted: false
      url: "jdbc:oracle:thin:@//localhost:1521/XEPDB1"
      user: "deploy_user"
      password: "your-password-here"

A note on the connection block: encrypted: false here for clarity, but drm-cli supports encrypting credentials at rest using a key you manage. We'll cover that in a follow-up article — for now, plain credentials are fine for a local test environment.

Step 2 — Write Your Migrations

Standard Flyway SQL migrations. Nothing unusual here:

-- V1__create_accounts_table.sql
CREATE TABLE accounts (
    account_id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    account_name VARCHAR2(100) NOT NULL,
    created_at   TIMESTAMP DEFAULT SYSTIMESTAMP
);

-- V2__add_account_status.sql
ALTER TABLE accounts
ADD status VARCHAR2(20) DEFAULT 'ACTIVE';

-- V3__create_transactions_table.sql
CREATE TABLE transactions (
    transaction_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    account_id     NUMBER NOT NULL,
    amount         NUMBER(15,2) NOT NULL,
    posted_at      TIMESTAMP DEFAULT SYSTIMESTAMP,
    CONSTRAINT fk_account FOREIGN KEY (account_id) REFERENCES accounts(account_id)
);

Step 3 — Run Your First Deployment

With your config in place, deploy with:

drm deploy --target oracle-prod

You'll see output like this:

[drm-cli] Starting deployment → oracle-prod
[drm-cli] Tool: flyway | Database: oracle
[drm-cli] Running Flyway migrate...
[drm-cli] Flyway: Successfully applied 3 migrations to schema "DEPLOY_USER"
[drm-cli] Recording release to history...
[drm-cli] Deployment complete — Release ID: 001 | Status: SUCCESS

That last line is what makes drm-cli different from running Flyway directly. Every deployment is written to the local release history database — timestamp, target, release ID, outcome.

Step 4 — Check Release History

drm history --target oracle-prod

Release History — oracle-prod
─────────────────────────────────────────────────────────────────
ID   Version   Status    Started              Completed
001  1.0.0     SUCCESS   2026-04-20 09:14:32  2026-04-20 09:14:38
─────────────────────────────────────────────────────────────────
1 release found.

This audit trail lives in the local SQLite file (release_history.db). It's yours — no cloud service, no external dependency.

Step 5 — What Happens When a Migration Fails

This is where retry logic matters. Let's say your network connection to Oracle drops mid-deployment — a perfectly ordinary thing to happen in production.

Configure retry_attempts and retry_delay_seconds in drm.yml (already set above), and drm-cli will automatically retry the deployment up to 3 times before marking it as failed.

[drm-cli] Starting deployment → oracle-prod
[drm-cli] Tool: flyway | Database: oracle
[drm-cli] Running Flyway migrate...
[drm-cli] Connection error — retrying in 10 seconds (attempt 1/3)
[drm-cli] Connection error — retrying in 10 seconds (attempt 2/3)
[drm-cli] Flyway: Successfully applied 1 migration to schema "DEPLOY_USER"
[drm-cli] Recording release to history...
[drm-cli] Deployment complete — Release ID: 002 | Status: SUCCESS

If all retries are exhausted, the failed attempt is still recorded in release history — so you know exactly what ran, what didn't, and when.

Encrypting Your Oracle Credentials

Storing plaintext database credentials is a habit worth breaking. drm-cli supports encrypting the connection block in drm.yml using a key you control.

Switch to encrypted mode:

connection:
  encrypted: true
  url: "gAAAAABk..."       # encrypted value
  user: "gAAAAABk..."      # encrypted value
  password: "gAAAAABk..."  # encrypted value

Encrypt your values with:

drm encrypt --value "jdbc:oracle:thin:@//localhost:1521/XEPDB1"

drm-cli prompts for your encryption key and returns the encrypted string. The key never touches drm.yml — you pass it at runtime or load it from an environment variable.

Full encryption setup is covered in the drm-cli docs.

Using Liquibase Instead of Flyway

If your team uses Liquibase rather than Flyway, swap tool: flyway for tool: liquibase in drm.yml and point migrations_path at your changelog directory. The rest of the workflow is identical.


yaml
targets:
  - name: oracle-prod
    tool: liquibase
    database_type: oracle
    changelog_file: ./changelogs/db.changelog-root.xml
    drivers_path: ./drivers
    connection:
      encrypted: false
      url: "jdbc:oracle:thin:

Deploy to PostgreSQL with drm-cli + Liquibase: A Step-by-Step Guide

dband drm — Wed, 22 Apr 2026 04:19:08 +0000

If you're running PostgreSQL with Liquibase or Flyway and you've ever been asked "what exactly was deployed to staging last Tuesday?" — and couldn't answer quickly — this post is for you.

drm-cli is a free, open-source database release manager that layers on top of Liquibase and Flyway. It doesn't replace your migration toolchain. It adds the layer those tools were never designed to provide: release history tracking, encrypted credentials, automated retries, and pre/post deployment scripts.

This walkthrough covers a complete PostgreSQL deployment with Liquibase. The setup for Flyway is identical — just swap the solution type in the config.

Prerequisites

Before you start:

Python 3.7+ installed on the host running drm-cli
git to clone the repo
Liquibase 4.25.0+ installed and on your PATH — download here
PostgreSQL JDBC driver (postgresql-*.jar) — download here
A PostgreSQL database you can connect to

Step 1 — Install drm-cli

Clone the repository and run the installer:

git clone https://github.com/dband-drm/drm-cli.git
cd drm-cli
python3 ./install.py

The installer is interactive — it will prompt you for:

Installation path — where drm-cli will be installed (defaults to your home directory)
Encryption key — to encrypt sensitive data like connection strings at rest (optional but recommended)
Storage type — json (file-based, no extra dependencies) or sqlite

For a non-interactive install:

python3 ./install.py -d json -p none

(-d json selects JSON storage, -p none means no encryption — use only for local test environments)

Once complete:

INFO - DRM installation finished successfully!!!

Step 2 — Prepare Your Liquibase Changelogs

drm-cli works with your existing Liquibase changelogs. No changes to your migration scripts are needed:

my-changelogs/
├── db.changelog-root.xml
├── changes/
│   ├── 001-create-users-table.xml
│   ├── 002-add-email-index.xml
│   └── 003-create-orders-table.xml

Note the path to this directory — you'll need it in the next step.

Step 3 — Configure Your Release

JSON style

Open <install-path>/db/drm_db.json in any editor. Find the releases array and add your release with a solution and connection:

{
  "id": 10,
  "name": "postgresql-release-v1",
  "solutions": [
    {
      "name": "app-db-liquibase",
      "solution_type_id": 2,
      "path": "/path/to/my-changelogs",
      "connections": [
        {
          "name": "postgres-staging",
          "connection_type_id": 3,
          "connection_string": "url=jdbc:postgresql://127.0.0.1:5432/appdb;username=deploy_user;password=your-password;"
        }
      ]
    }
  ]
}

Key fields:

solution_type_id: 2 — Liquibase (use 3 for Flyway)
path — the directory containing your Liquibase changelogs
connection_type_id: 3 — PostgreSQL
connection_string — the JDBC connection string Liquibase uses

SQLite style

Insert via SQL:

-- Add the release
INSERT INTO releases (id, name) VALUES (10, 'postgresql-release-v1');

-- Add the Liquibase solution
INSERT INTO solutions (id, name, release_id, ordinal, solution_type_id, path)
VALUES (100, 'app-db-liquibase', 10, 1, 2, '/path/to/my-changelogs');

-- Add the PostgreSQL connection
INSERT INTO connections (id, name, solution_id, connection_type_id, connection_string)
VALUES (1000, 'postgres-staging', 100, 3,
        'url=jdbc:postgresql://127.0.0.1:5432/appdb;username=deploy_user;password=your-password;');

Step 4 — Run Your First Deployment

Navigate to your drm-cli installation directory and run:

python3 ./drm_deploy.py -c postgres-staging -r 10 --deploy

Parameters:

-c postgres-staging — the connection name you defined in the config
-r 10 — the release ID
--deploy — execute the deployment (use --dryrun to generate scripts without running them)

You'll see output as drm-cli invokes Liquibase, captures the result, and records it:

INFO - DRM Deploy started
INFO - Running solution: app-db-liquibase
INFO - Executing Liquibase migrate...
INFO - Liquibase: Successfully applied 3 changesets
INFO - Deployment recorded successfully
INFO - DRM Deploy finished successfully!!!

Step 5 — View Deployment History

After a deployment runs, drm-cli records the full event — timestamp, connection, release ID, and outcome.

JSON style

Browse to <install-path>/deployments/. Each deployment creates a log file named:

Deploy_{GUID}_C{connection-name}_R{release-id}.json

Open it to see the full deployment record: every step, its start/end time, status, and any error messages.

SQLite style

Query the deployments table:

SELECT d.*, ds.name AS status
FROM deployments AS d
INNER JOIN deployment_statuses AS ds ON ds.id = d.deployment_status_id
ORDER BY d.start_time DESC
LIMIT 10;

Step 6 — What Happens When a Migration Fails

If a deployment step fails — network hiccup, lock timeout, transient error — drm-cli retries automatically. Retry behavior is configured in drm_deploy.config inside your drm-cli installation:

"retry_attempts": 3,
"retry_delay_seconds": 10

A failed step will retry up to 3 times with a 10-second delay. If all retries are exhausted, the deployment is marked failed and the full error is recorded in the deployment log.

Even when a deployment fails, the record is there. You know exactly what ran, what didn't, and when.

Step 7 — Encrypting Your PostgreSQL Credentials

If you installed drm-cli with an encryption key, use drm_crypto.py to encrypt your connection string:

python3 ./drm_crypto.py

The utility prompts you for your encryption key and the value to encrypt, then returns the encrypted string. Replace the plaintext value in your connection config with the result:

"connection_string": "url=jdbc:postgresql://127.0.0.1:5432/appdb;username=deploy_user;password=ENCRYPTED_VALUE_HERE;"

drm-cli decrypts credentials at deploy time — they never appear in logs or trace output.

Using Flyway Instead of Liquibase

Swap solution_type_id: 2 for solution_type_id: 3 and set path to your Flyway migrations directory:

{
  "name": "app-db-flyway",
  "solution_type_id": 3,
  "path": "/path/to/flyway/migrations",
  "connections": [
    {
      "name": "postgres-staging",
      "connection_type_id": 3,
      "connection_string": "url=jdbc:postgresql://127.0.0.1:5432/appdb;username=deploy_user;password=your-password;"
    }
  ]
}

The deployment command is identical:

python3 ./drm_deploy.py -c postgres-staging -r 10 --deploy

What's Next

Week 5 — Oracle deployments with drm-cli + Flyway or Liquibase
Week 6 — Pre/post deployment scripts: the pattern for automating steps that run before and after every deployment
Week 7 — Multi-database releases: SQL Server, PostgreSQL, and Oracle in a single coordinated release

The full source and documentation is at github.com/dband-drm/drm-cli. Open issues there if you hit anything unexpected.

drm-cli is free and open-source. No license tiers, no paid features.

drm-cli v1.1 is out — PostgreSQL, Oracle, Liquibase & Flyway now supported

dband drm — Fri, 10 Apr 2026 05:15:31 +0000

We shipped drm-cli v1.1 this week.

If you haven't heard of drm-cli before: it's a free, open-source database release manager that layers on top of your existing tools — Liquibase, Flyway, SSDT — and adds release history, encrypted credentials, automated retries, and multi-solution deployments. It doesn't replace your migration toolchain. It wraps it and fills the gaps that migration tools were never designed to fill.

v1.0 supported SQL Server via SSDT and sqlpackage. That covered a lot of ground for us, but it wasn't enough.

Here's what changed in v1.1.

What's new in v1.1

PostgreSQL support

drm-cli now supports PostgreSQL deployments via Liquibase or Flyway. You configure your solution in the drm-cli database (drm_db.json or SQLite) with solution_type_id: 2 (Liquibase) or 3 (Flyway), point it at your changelog or migration directory, and drm-cli handles the rest — connection string encryption, release history tracking, retry logic, pre/post scripts.

Same release model you'd use for SQL Server, now for Postgres.

Oracle support

Oracle deployments via Liquibase or Flyway are now supported. If you've ever tried to wrangle Oracle connection strings, schema differences, and deployment sequencing across environments, you know why this matters. drm-cli treats Oracle the same as any other database in the release — same config structure, same audit trail, same retry behavior.

No separate toolchain for Oracle. No separate release process.

Liquibase and Flyway integration

v1.0 relied on sqlpackage for SQL Server. In v1.1, Liquibase and Flyway are first-class execution engines.

You configure which engine to use per solution. drm-cli invokes it, captures the output, evaluates success or failure, and records the result. If something fails, the retry logic kicks in. The audit trail captures what ran, when, and what the outcome was — regardless of which engine executed it.

If your team already uses Liquibase or Flyway, drm-cli doesn't ask you to change that. It sits on top of what you already have.

Pre/post deployment scripts

This one came directly from operational pain.

Before deploying, you might need to run a notification script, disable a job, or snapshot something. After deploying, you might need to re-enable that job, run a smoke test, or hit an API. These steps are easy to forget, easy to skip under pressure, and expensive when missed.

v1.1 introduces pre and post deployment scripts at the project level. You define the scripts once in the release config. drm-cli runs them every time, in order, before and after the main deployment — regardless of which database or execution engine is involved.

Encrypted connection strings (extended)

Credential encryption was in v1.0, but v1.1 extends it to cover PostgreSQL and Oracle connection strings. The mechanism is the same — use the drm_crypto.py utility to encrypt your connection strings, store the encrypted values in the release config, and drm-cli decrypts them at deploy time. No plaintext credentials sitting in your release config.

What stayed the same

The core model hasn't changed. drm-cli reads the release database, executes solutions in order, tracks the result of each one, and writes the history to deployment logs. If a solution fails, it retries. If it fails past the retry threshold, it stops and reports.

v1.0 users can upgrade without changing their existing config. Existing SQL Server solutions default to their previous behavior.

We'll write the full upgrade guide in Week 8. The short version: run the installer against your existing installation and it handles the rest.

Quick look at the v1.1 config

Here's what a v1.1 multi-database release looks like in drm_db.json:

{
  "id": 1,
  "name": "Q2-2026-release-01",
  "solutions": [
    {
      "name": "core-schema",
      "solution_type_id": 1,
      "path": "/ssdt/CoreSchema"
    },
    {
      "name": "analytics-db",
      "solution_type_id": 2,
      "path": "/liquibase/analytics",
      "connections": [
        {
          "name": "analytics-postgres",
          "connection_type_id": 3,
          "connection_string": "url=jdbc:postgresql://db-host:5432/analytics;username=deploy;password=encrypted-value;"
        }
      ]
    },
    {
      "name": "reporting-oracle",
      "solution_type_id": 3,
      "path": "/flyway/reporting",
      "connections": [
        {
          "name": "reporting-oracle",
          "connection_type_id": 2,
          "connection_string": "url=jdbc:oracle:thin:@//ora-host:1521/ORCL;username=deploy;password=encrypted-value;"
        }
      ]
    }
  ]
}

SQL Server, PostgreSQL, and Oracle. Three different execution engines. One release. One audit trail.

How to install or upgrade

New install:

git clone https://github.com/dband-drm/drm-cli.git
cd drm-cli
python3 ./install.py

Upgrade from v1.0:

Run the installer against your existing drm-cli installation path. It detects the existing version and walks you through the upgrade steps.

python3 ./install.py

Follow the prompts and point it at your current installation directory when asked.

The full release notes are on the drm-cli GitHub repo. Open issues and feature requests there.

What's coming in the next few weeks

Over the next several posts we'll go deep on each of the new capabilities:

Week 4 — Step-by-step: deploying to PostgreSQL with Liquibase or Flyway
Week 5 — Oracle deployments with Flyway or Liquibase
Week 6 — The pre/post script pattern in detail

If you're already using drm-cli and upgrade to v1.1, let us know how it goes. If you hit anything unexpected, open an issue. We read them all.

And if this is the first time you're hearing about drm-cli — the Week 2 post covers the problem we built it to solve. Start there if you want the full context before diving into v1.1.

drm-cli is free and open-source. No license tiers, no paid features, no freemium model. Everything described here is available to everyone.

The Gap Between Database Version Control and Release Management

dband drm — Thu, 02 Apr 2026 16:15:00 +0000

If you've been using Liquibase or Flyway for a while, you already know they solve a real problem. Migrations are tracked. Schema changes are repeatable. Your database evolves in lock-step with your application code.

So why does deploying a database change still feel fragile?

We asked ourselves the same question. We were running Liquibase in production across multiple environments, with a reasonably mature pipeline. Migrations were clean. The versioning worked. But the release — the actual act of getting a change from dev to test to production, with confidence — still had gaps we were plugging with shell scripts, spreadsheets, and hope.

This is the problem drm-cli was built to solve.

What Liquibase and Flyway Actually Do

Let's be precise here, because nothing in this post is a criticism of either tool. Liquibase and Flyway are excellent. We still use them.

What they do: track and apply schema changes. Given a target database and a set of migrations, they work out which changes haven't been applied and apply them in the right order. That's the core job, and they do it well.

What they're not designed to be: a release management layer.

The distinction matters. Version control is about tracking what changed. Release management is about controlling how and when that change reaches each environment — with history, error handling, credential management, and coordination across multiple systems.

The Gaps We Kept Running Into

Here's what we found missing when we tried to treat Liquibase alone as a full release management solution:

1. No release history

Liquibase maintains a DATABASECHANGELOG table per database. That's a migration history. It tells you what migrations have been applied to that database. It doesn't tell you who ran the release, when, from which version of the release package, or whether the release across all your environments succeeded. There's no audit trail at the release level.

2. No encrypted credential management

Your connection strings contain passwords. If you're running migrations from a CI pipeline or a deployment server, those credentials need to live somewhere. Liquibase and Flyway accept them as arguments or environment variables — but they don't provide a mechanism for encrypting them at rest. The moment your pipeline config ends up in a screenshot or a log, you have a problem.

3. No automated retry or failure recovery

A migration fails at step 4 of 12. Now what? Liquibase will tell you what happened. It won't automatically retry the failed step, skip to a recovery path, or log the failure in a structured way that your team can act on without hunting through console output.

4. No multi-solution coordination

Your release touches a SQL Server SSDT project and a Liquibase changelog and a set of Oracle scripts. These are separate tools with separate invocations. Running them in the right order, capturing failures across all of them, and producing a single release record — there's nothing in any one tool that handles this. You write glue code. We all write glue code. Most of it is fragile.

5. No cross-platform release definition

How do you define a release that runs the same way on a Windows deployment server and a Linux CI agent? With Liquibase or Flyway alone, your answer is usually "a shell script on Linux and a batch file on Windows." drm-cli is written in Python and runs identically on both.

Versioning vs. Releasing: A Concrete Example

Imagine you're deploying a change that does all of the following:

Updates three tables in your SQL Server application database (via SSDT)
Applies a new Liquibase changelog to a PostgreSQL reporting database
Runs a post-deployment script that refreshes a materialized view

With Liquibase and Flyway, you have the migration layer covered for the databases they manage. But you're still answering these questions manually:

What order do these run in?
What happens if the PostgreSQL migration succeeds but the post-deployment script fails?
Where is the record of this release — what ran, when, and with what outcome?
How do I re-run just the failed step without re-running the whole thing?
How do I pass credentials to each tool without hardcoding them in the pipeline?

These are release management questions. Liquibase isn't trying to answer them. It shouldn't have to. That's a different layer.

What drm-cli Adds on Top

drm-cli doesn't replace Liquibase or Flyway. It wraps and extends them.

You define a release in a YAML file. That file tells drm-cli:

Which tools to invoke (Liquibase, Flyway, SSDT's sqlpackage)
In what order
Against which databases (SQL Server, PostgreSQL, Oracle — or all three)
With which credentials (stored encrypted, decrypted at runtime)
With which pre/post scripts to run around each step

drm-cli then executes the release, handles failures with configurable retries, and writes a structured release history entry — regardless of how many tools were involved or how many databases were touched.

Here's a minimal example. A release.yml for a single PostgreSQL deployment using Liquibase:

release:
  name: "v2.4.1"
  solutions:
    - name: reporting-db
      engine: liquibase
      database: postgresql
      changelog: changelogs/reporting/changelog.xml
      connection: connections/reporting.enc

That's it for the definition. drm-cli handles the invocation, the logging, and the history.

A Note on What drm-cli Is Not

We want to be honest about scope:

It doesn't write your migrations for you
It doesn't manage your Liquibase or Flyway configuration beyond invocation
It doesn't replace your CI/CD pipeline — it runs inside it
It's not trying to be an all-in-one database platform

It's a release management layer. Narrow scope, done well.

Getting Started

drm-cli is free and open-source. Installation takes about two minutes.

The interactive installer (the fastest way to get started on any platform) is shown in this walkthrough:

▶️ [drm-cli interactive installation — video]

Or install directly:

pip install drm-cli

The documentation is at [docs link] and the source is on GitHub at [repo link].

What's Next

Next week we'll announce drm-cli v1.1 — which adds full PostgreSQL and Oracle support, Flyway integration alongside Liquibase, and pre/post deployment script support.

If the problem we described here is familiar, the v1.1 announcement is worth watching for.

In the meantime, if you've hit any of these gaps in your own Liquibase or Flyway setup, we'd genuinely like to hear how you've been handling them. Drop a comment below.

drm-cli is built and maintained by d-band. Free. Open-source. No license cost.

We're d-band — Here's Why We Build Open-Source Tools

dband drm — Mon, 23 Mar 2026 16:12:01 +0000

This is the first post from d-band. We're not launching a product today. We're introducing ourselves.

We Built What We Needed

A few years ago, we were running database deployments across multiple environments, multiple databases, and multiple tools. Liquibase for one system, SSDT for another, custom shell scripts to glue it all together, a shared spreadsheet to track what actually deployed where.

It worked. Until it didn't.

The spreadsheet went stale. Scripts diverged between environments. A rollback that should have taken ten minutes took three hours because nobody could say with confidence what state the target database was actually in.

We looked for a tool that could tie all of this together — something that sat on top of the tools we already had, tracked deployment history properly, handled credentials securely, and let us run a full release across multiple databases without stitching together a dozen scripts.

We didn't find one that hit all of those marks without a significant license cost or a full platform migration.

So we built one.

Who We Are

d-band is a small team of data engineers and DevOps practitioners. We do consulting work — helping organizations build and maintain data infrastructure — and alongside that, we build tooling.

We're not a VC-backed startup optimizing for growth metrics. We're practitioners who got frustrated with a gap in the ecosystem and decided to fill it.

That gap is database release management. Not version control — that problem is largely solved. Release management: the process of taking your versioned schema changes and actually getting them deployed, reliably, with a full audit trail, across all the databases you care about.

What We Believe

A few things we think are true about tooling in this space:

Open-source is the right model. Database tooling has a long history of "free tier, enterprise price." We think that creates the wrong incentives. When a tool is fully free and open-source, the authors have to earn trust through quality, not through feature gating.

Don't replace what works. Liquibase and Flyway are good tools. SSDT is genuinely useful for SQL Server shops. We're not interested in building a competitor to those tools — we're interested in building the layer above them that handles the parts they don't.

History matters. Every deployment should be recorded. Not in a log file that someone might or might not check — in a queryable release history that's part of your workflow. When something goes wrong at 2am, you should be able to answer "what changed, when, and where" in under a minute.

Security shouldn't be an afterthought. Connection strings containing credentials shouldn't live in plaintext config files. This is obvious in principle and routinely ignored in practice. We built credential encryption into drm-cli from the start.

What We're Releasing

Our first public tool is drm-cli — a free, open-source database release manager that layers on top of Liquibase, Flyway, and SSDT.

It handles:

Release history tracking — every deployment recorded, queryable, auditable
Encrypted credentials — connection strings encrypted at rest
Automated retries and failure recovery — deployments that recover gracefully when something transient goes wrong
Multi-database releases — SQL Server, PostgreSQL, and Oracle in a single coordinated release
Pre/post deployment scripts — steps that always run before or after every deployment
Cross-platform — Windows, Linux, macOS

We're not going to go deep on any of those today. Each of them deserves its own post, with real config examples and real commands. That's what's coming over the next several weeks.

Why Post Here

We're building in public because we think that's how open-source tooling should work.

Over the next few weeks, we'll be posting technical tutorials, honest write-ups of what we got wrong and had to rethink, and a full walkthrough of what drm-cli v1.1 can do. Not press releases — actual technical content that's useful whether or not you ever touch our tool.

If any of this is relevant to problems you're dealing with, follow along. We'd rather earn readers through useful content than through a product announcement.

Where to Find Us

GitHub: github.com/d-band/drm-cli — the repo, the docs, and the issue tracker
drm-cli docs: full documentation is in the repo
This blog — we'll be posting here regularly

Next week: what drm-cli actually is, what problem it solves, and why Liquibase and Flyway alone aren't enough for release management.

We're d-band. We build things we need. If you need them too, that's a bonus.

What's your biggest database deployment pain point?

dband drm — Sat, 14 Feb 2026 15:17:48 +0000

After spending countless hours debugging database deployment drift across multiple databases on different environments, we decided to build something better.

The problem was simple but painful:
→ Juggling multiple deployment tools for Oracle, PostgreSQL, SQL Server
→ No unified interface for database releases
→ Manual tracking of what's deployed where
→ Deployments failed with no retry mechanism
→ Team wasted hours tracking down issues

So we built DRM-CLI - a unified Python CLI that:
✓ Single interface for Oracle, PostgreSQL, SQL Server
✓ Built-in retry mechanism for resilient deployments
✓ Parallel execution for multiple targets
✓ Complete deployment tracking (SQLite or JSON)
✓ Secure encryption for sensitive configs
✓ Integrates with Flyway, Liquibase, sqlpackage

Built with Python for cross-platform support (Windows & Linux)
Open source under MIT license

The response from our DBA team has been incredible - we're deploying faster and catching issues before they hit production.

If you're managing database deployments across multiple environments, check it out:
🔗 https://github.com/dband-drm/drm-cli
🔗 https://www.linkedin.com/company/d-band
🔗 https://www.d-band.com/

What's your biggest database deployment pain point?

Database #DevOps #DBA #Oracle #PostgreSQL #SQLServer #OpenSource #DataOps