in Asia the last 7 years → 25 years in the software industry → ISAQB certified instructor and certified Azure Solution Architect → Enthusiast for all kinds tech, software (-architecture and -development), DevOps, Thought-leadership and much more About me
is short for DevOps Research and Assessment → Research program by Google, established around 2014 in cooperation with Puppet → DORA publishes yearly State of DevOps reports (DORA | DORA Publications) → Many of the initial DORA members co-wrote the book “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”, which is considered the “Bible of DevOps” DORA is…
State Of DevOps report, DORA also publishes various guidelines to improve developer productivity software delivery and operations performance. → Among those is the DORA Core Model, which functions as basis for the infamous DORA Metrics → Find a very detailed overview over those model categories here (DORA | Research) DORA does…
delivery metrics—the four keys—that provide an effective way of measuring the outcomes of the software delivery process DORA’s 4 basic metrics Change Lead Time measures the time it takes for a code commit or change to be successfully deployed to production. Reflects the efficiency of the delivery pipeline Deployment frequency measures how often application changes are deployed to production. Higher deployment frequency indicates a more agile and responsive delivery process. Change fail percentage measures the percentage of deployments that cause failures in production. A lower change failure rate indicates a more reliable delivery process. Recovery time from failure measures the time it takes to recover from a failed deployment. A lower recovery time indicates a more resilient and responsive system.
their silo, and provides just output for the next silo to work with → The silo must check itself how it best can fulfill the requirements that it needs to perform well → Often processes to deploy and operate software include several instances of people and separate processes → Still nowadays a lot of companies work like this…(most probably the also hire a lot of DevOps engineers) In the Dev-Ops world…
mindset (“You build it, your run it) → From early stages you plan how to deploy and deliver in a fast way, but good quality software → Instead of silos you create a fast flow organization with lots of collaboration and automatization to enable high throughput and good quality Transitioning to DevOps means… DORA metrics REQUIRE you to have DevOps processes and mindset and ENABLE you to measure how well you are doing in your journey
Check page, where you can enter the values for the 4 categories provided. (DORA | DORA Quick Check) → They offer also to compare your values to other people who have entered their numbers in the same sector → Keep in mind that the DORA metrics ultimatively define WHAT to measure, not if this is good or bad (in your context) → It is shown that those 4 metrics correlate, rather than exclude each other. → So to improve, improve all 4 metrics. Measuring DORA metrics…
the name says, metrics…not goals… → DORA metrics should not be compared between different application types or business fields. → They may seem easy, but require a lot of change usually in an organization and the minds of the involved people. → Avoid using your context (processes, regulations…) as excuse for not changing. → Avoid to focus only to make them LOOK good, but forget to focus on the changes in your process and organization to make them BECOME good Be careful not to…
janmoser
sansan33
maguroalternative
bengo4com
sat
frievea
techniczna
takano0131
gree_tech
kaminashi
lycorptech_jp
brettharned
cromwellryan
geoffreycrofte
jcasabona
zakiyama
kevinliebholz
bluesmoon
gr2m
yeseniaperezcruz
eileencodes
notwaldorf
swwweet
