What are the DORA metrics, and how have you used them?
CI/CD & GitOps · Basic level
Answer
DORA metrics are deployment frequency, lead time for changes, change-failure rate, and time to restore service. I use them to see whether delivery speed is improving without sacrificing reliability, then connect pipeline improvements to real outcomes like faster feedback and lower rollback or incident rates.
Technical explanation
DORA metrics are outcome metrics; they should be interpreted with service context rather than used as vanity numbers.
Improvement work should connect pipeline bottlenecks to business impact, such as faster recovery and smaller change batches.
CI/CD should optimize both speed and safety: fast feedback for developers, controlled promotion for environments, and clear evidence for operations.
The deployable artifact should be built once, versioned, scanned, and promoted by immutable version or digest rather than rebuilt per environment.
Use automated gates for tests, policy, security, and health checks; use human approval only for risk decisions that automation cannot make reliably.
Track delivery health with lead time, deployment frequency, change-failure rate, MTTR, pipeline duration, queue time, and flaky failure rate.
Hands-on example
1. Create or update a Jenkinsfile for the scenario: What are the DORA metrics, and how have you used them.
2. Use a Declarative Pipeline skeleton: pipeline { agent { label 'linux && docker' } options { timestamps(); disableConcurrentBuilds() } stages { stage('Checkout') { steps { checkout scm } } stage('Test') { parallel { stage('Unit') { steps { sh 'make unit' } } stage('Lint') { steps { sh 'make lint' } } } } } post { always { junit 'reports/*.xml'; cleanWs() } failure { echo 'notify team' } } }.
3. Inject secrets only in the narrowest stage, for example withCredentials([string(credentialsId: 'scanner-token', variable: 'TOKEN')]) { sh 'scanner --fail-on critical' }; do not echo TOKEN or write it into archived artifacts.
4. Publish the immutable result: tag the image with the Git SHA, push to ECR/Nexus, archive test reports, and record build URL, commit SHA, artifact digest, approver, and deployment status.
5. Prove the design by rerunning the same commit twice: the second run should reuse safe caches, produce the same artifact version or detect it already exists, and avoid duplicate side effects.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More CI/CD & GitOps interview questions
- What is CI/CD, and what is the difference between continuous delivery and continuous deployment?
- What are the goals of a CI pipeline beyond just running tests?
- What is Jenkins, and what is the difference between a controller and an agent?
- What is the difference between a freestyle job and a pipeline job in Jenkins?
- What is the difference between a declarative and a scripted Jenkins pipeline?
- What is a Jenkinsfile, and why keep your pipeline as code in the repo?
- Explain the structure of a declarative pipeline (agent, stages, steps, post).
- What is the post section used for, and what are its conditions (success, failure, always)?