Software Delivery: Deployment Events, Guardians and Quality Gates
Software Delivery tests how Dynatrace closes the loop with CI/CD: making deployments visible, comparing versions, and blocking or approving a release automatically using observability data.
Making deployments visible
- Send deployment events through the events ingest API using a custom deployment event type, scoped to the affected service or entity, with version and remediation details.
- Correct scoping creates the version and release context that later comparisons rely on; an unscoped event produces an orphan marker that no comparison can use.
- Release views compare error rate, response time and throughput before and after the event, so a canary can be judged against its own baseline rather than a global average.
Automated quality gates
- Site Reliability Guardian defines objectives as DQL queries evaluated over a specified timeframe with validation thresholds. It is invoked from a pipeline (directly via API or orchestrated by Keptn) and returns pass or fail, which the pipeline uses to promote or roll back.
- Keptn provides lifecycle orchestration: metrics providers, evaluations and tasks that sequence pre- and post-deployment checks and can call Dynatrace objectives.
- Scorecards and developer portals surface service maturity and SLO status to delivery teams rather than to operations alone.
Worked example
A canary receives five percent of traffic for ten minutes. The guardian evaluates error rate and p95 latency for the canary entity against the same metrics for the stable version over an equivalent preceding window. Error rate exceeds the threshold, so the pipeline halts and rolls back automatically. Reasoning: the timeframe must match the canary duration and the entity selector must target the canary, otherwise the guardian validates the wrong population and passes a bad release.
Traps that cost marks
- Comparing against a noisy or unusually quiet baseline window and trusting the result.
- Omitting the service entity from the deployment event, losing version comparison entirely.
- Reusing one guardian objective across environments without adjusting thresholds and filters.
- Assuming rollback happens on its own - the pipeline must act on the returned result.