Database change management

Changes to production data need their own control: a reviewed script, a backup, separate business and technical authorization and an execution window.

Why data changes are different

A code deployment can be rolled back by installing the previous version. An UPDATE or DELETE on production data often cannot: only a backup taken right before can undo it.

The essential controls

  • The script reviewed by a peer before anyone authorizes it.
  • A validation in a test database with the expected row counts.
  • A backup confirmed right before execution.
  • A scheduled execution window, and a check after applying it.

Two authorizations, two questions

The business decides whether the change should happen at all; the database team decides whether the script is safe to run. Keeping those two decisions apart prevents either side from approving alone.

How DevGob applies it

DevGob's Data Change flow has Level 1 and DB authorizations, a confirmed backup, an execution window and on-time compliance in its own report.

Read it in the documentation

Related topics

Change management in DevOps Change management decides which changes need authorization, who gives it and what evidence is kept — without slowing down the changes that don't. DevSecOps: security in the pipeline DevSecOps builds security into every stage of delivery: scanning code and dependencies, limiting access and keeping an audit trail of every change. Continuous testing Continuous testing checks every change as early as possible and keeps the results as evidence for whoever has to authorize the release.

DevOps with governance, on one record

DevGob plans the work and governs every change on its way to production: backlog, sprints, committee authorizations, install evidence and an audit trail.

Request a workspace Documentation