This changes how a number is computed. Your charts can move without your data moving. Each change is named below with the reason for it.

What changed

A rollback undoes a release, so DORA counts the release it replaced as a failed change. Until now we recognised only one way to roll back: deploying an earlier commit again. Teams that roll back differently were reported as if they never rolled back at all.

We now recognise three ways, with nothing new to set up:

  • A rollback job. A job whose name says it rolls back, for example helm rollback, rollback prod, roll-back or откат. If you picked deploy jobs in Setup, we find it in any pipeline that ran one of them. If you use GitLab environments, the job must deploy your production environment, as GitLab rollback jobs usually do.
  • An earlier commit deployed again, as before.
  • An older version. A deploy of a lower version tag on the same line, for example 2.14.9 right after 2.14.10. Tags on another line never count: 2.2.22-android after 3.3.53 is not a rollback.

What happens to your numbers

  • Change fail rate can go up. The release a rollback replaced now counts as failed.
  • Rework rate can go up. A rollback is unplanned work to fix production.
  • Recovery time gains samples: the failure ends when the rollback finishes.
  • Deployment frequency can go up slightly, because a rollback is a release of its own.

One correction can make the numbers go down. Rolling forward again after a rollback (redeploying the version you had just rolled back from) used to count as a second rollback. It no longer does.

Rollback jobs from the last 90 days are read once after this update, so recent periods are recomputed too, not only new ones.

What is still not seen

A helm rollback run from a laptop or from Argo CD, outside GitLab, leaves no trace in GitLab, so we cannot count it. If your team rolls back that way, run the rollback as a pipeline job instead and it will be counted.

Reverts are unchanged: a revert counts only when the change it undoes had already reached production. A revert merged into the same release as the change it undoes never reached users, so it is not a failure.

← All releases · Subscribe (Atom)