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.

Types of change

  • Standard: low risk, repeatable and pre-approved.
  • Normal: assessed and authorized before it is applied.
  • Emergency: applied fast to restore service, authorized and recorded anyway.

The change advisory board (CAB)

A change advisory board reviews normal changes with real risk. It works best when it decides on evidence — tests passed, rollback plan, affected systems — instead of on a verbal summary, and when each decision is recorded with who made it and when.

Evidence and rollback

Every authorized change should carry its install evidence and a rollback plan written before the install. When a rollback happens, it should leave a record that feeds the next review, not a quiet revert.

How DevGob applies it

In DevGob a Deployment goes through eleven phases with two committee authorizations, one for pre-production and one for production, each recorded with its approver and its minutes.

Read it in the documentation

Related topics

Continuous delivery Continuous delivery keeps every change ready to release: built, tested and deployable at the push of a button, in small and frequent batches. 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. DevOps frameworks Scrum, Kanban, ITIL 4 change enablement and CALMS answer different questions. Most teams combine them: one to plan the work, another to govern the change.

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