04 / Enterprise engineering & technical operations
Oracle Delivery & Change Systems
Making complex Oracle database delivery safer, more visible, and easier to operate — across 11g, 12c, and 19c environments, dozens of schemas, a 20-year-old configuration-management stack (Scopus / PVCS), and a change process where a single careless script can take a client down.
- Role
- Database change authorship, delivery tooling, production diagnostics
- Period
- 2021 — present
- Technologies
- Oracle 11g / 12c / 19c · SQL · PL/SQL · C# / WPF / .NET · Python · PVCS / Scopus · Azure DevOps · CI/CD · PowerShell · Oracle Instant Client · Anthropic Claude API
What was actually broken
Database change is where enterprise delivery risk concentrates. Scripts written by many hands, applied to environments at different patch levels, touching schemas with tangled grant-and-synonym dependencies — orchestrated through a configuration-management system old enough to vote, with production support waiting on the other end when something drifts. The challenge was never writing SQL; it was building the discipline and tooling that makes hundreds of changes boring.
- Environments span Oracle 11g, 12c, and 19c with real behavioral differences
- Scripts must be idempotent and rollback-safe — client DBAs run them unattended
- Cross-schema dependencies (grants, synonyms, triggers) fail late and non-obviously
- Patch assembly and check-ins run through legacy Scopus / PVCS systems that cannot be replaced overnight
- Delivery happens through an established pipeline: Azure DevOps, artifacts, SFTP to on-prem clients
What I owned
- Author and maintain change scripts to a strict internal standard: idempotency, rollback paths, version-control headers, trigger handling
- Manage cross-schema access, grants, and synonyms across the product suite
- Build and maintain the patch tooling suite: WPF/C# patch-builder and check-in tools driving PVCS and the CM Oracle schema (modern rewrites of a legacy VB.NET tool I also maintain)
- Build and distribute a Python patching utility with revision-diff tooling, packaged for the team
- Investigate query performance and diagnose production-support incidents
- Build drift-tracking tooling that snapshots and validates schema state across environments
- Prepare and deliver build artifacts as backup Configuration Manager — full backend and frontend builds via the Azure artifact pipeline or SFTP
Surface & System
Surface
What safe delivery looks like from the outside
To the teams downstream, good database delivery is invisible: a patch arrives, applies cleanly the first time, and the release notes match reality. Every convention in the internal standard — headers, idempotency guards, rollback blocks — exists so that the person applying a script needs no context the script doesn't carry itself.
Visibility tooling turns 'what state is this environment in?' from an investigation into a lookup: drift snapshots, patch-level tracking, and schema validation that catches divergence before it becomes a support ticket.
- Change scripts that apply cleanly, unattended, on the first run
- Version-control headers making every script self-describing
- Drift and patch-level visibility across client environments
- Delivery artifacts that bundle everything a deployment needs
System
The machinery under the standard
The internal standard is enforced by tooling, not memos. A drift collector snapshots schema state across Oracle environments and validates it against expectations, including tip-vs-tip build comparison against the QA baseline. An AI-assisted generator drafts standards-compliant scripts from ticket text and an automated validator scores them against the conventions — every script still crossing a DBA's desk before deployment.
The delivery machinery itself is a suite I build and maintain: a WPF/C# patch-builder that drives PVCS (PCLI) and the CM Oracle schema with product/version/client routing, a companion check-in tool for file deliverables, and a Python patching utility with revision-diff tooling distributed to the team — modern rewrites of a legacy VB.NET tool that I also keep alive. Downstream, Azure DevOps assembles full build artifacts for on-prem or SFTP delivery, and Oracle Instant Client integration lets modern Node.js applications speak to legacy database environments.
- Strict script standard: idempotency, rollback safety, VC headers, trigger handling
- Drift collector with schema snapshots and QA-baseline build comparison
- WPF/C# patch-builder and check-in tools driving PVCS (PCLI) + the CM Oracle schema
- Python patch utility with revision diffs, packaged and distributed to the team
- Claude-assisted generation + automated convention validation, DBA-reviewed
- Azure DevOps pipeline → artifacts → on-prem / SFTP client delivery
- Oracle Instant Client bridging modern Node.js to legacy environments
Database change delivery pipeline
A change request arrives as a ticket. The AI-assisted generator drafts a standards-compliant script, the automated validator scores it against internal conventions, and a DBA reviews and finalizes it. The patch tooling suite — WPF patch-builder and check-in tools driving PVCS and the CM Oracle schema — assembles approved changes, Azure DevOps builds artifacts, and delivery reaches client environments on-prem or via SFTP. A drift collector snapshots schema state across environments and feeds validation results back to the DBA.
Decisions that mattered
Standards enforced by validators, not vigilance
Conventions that rely on humans remembering them decay. Encoding the standard into an automated validator made compliance the path of least resistance and turned reviews into judgment calls instead of checklists.
Snapshot drift instead of assuming state
Environments diverge — silently, always. Regular schema snapshots with validation replaced 'it should be at patch level X' with evidence, and moved drift discovery from production incidents to routine reports.
Modernize the pipeline from inside
The legacy VB.NET tooling wasn't ripped out; it was rewritten piece by piece — WPF rewrites for patch-building and check-ins, web modules inside VisionHub — while the original stayed maintained. Delivery never stopped while its machinery was rebuilt.
Where it landed
Routine database change tickets flow through a generate-validate-review pipeline; drift is tracked instead of discovered; patch assembly and check-ins run through modern rewrites of the legacy tooling; and delivery to on-prem clients runs through a repeatable artifact process with a documented backup Configuration Manager.
What I'd explore next
Fuller automation of drift remediation proposals and completing the retirement of the legacy VB.NET tooling.
- Strict script standards add authoring overhead per change, repaid at every unattended deployment
- Supporting 11g through 19c simultaneously constrains which SQL features can be used
- Maintaining legacy tools alongside their rewrites doubles surface area, in exchange for uninterrupted delivery