dband drm

Posted on Apr 10 • Edited on Apr 22

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

#postgres #opensource #database #devops

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.

DEV Community