Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps From a Different Data Set

DevOps From a Different Data Set

What can you learn about DevOps and software delivery practices by looking at data from a platform with more than 300,000 developers, 25,000 organizations and 25+ million builds per month? I wanted to find out. As an author of State of DevOps Report in 2018, I was very interested in this new data set from a large SaaS developer platform. What items pop out from the data? Are they different than what is seen through surveys where responders opt-in to participating vs. being aggregated through platform usage? Additionally, does the data validate assertions from State of DevOps Reports of years past about batch sizes, trunk development, and team size?

I’ll cover a view into anonymized team data to share insights, behaviors, and metrics that help teams build better software, faster from millions of builds, and look into characteristics of success that we can measure through our data. Then I’ll overlay that onto what we’ve found through survey data and point out confirmed actions that improve delivery flow, and open up some counter points to what we’ve seen so far.

Michael Stahnke

October 09, 2019
Tweet

More Decks by Michael Stahnke

Other Decks in Technology

Transcript

  1. @stahnma hard hitting stats the most common length of a

    repository name is 17.6 characters
  2. @stahnma hard hitting stats the most common project name is

    api, followed by terraform, infrastructure, and web
  3. @stahnma hard hitting stats after environmental names (e.g dev, test,

    stage) the most common branch name is update-readme
  4. @stahnma hard hitting stats if you take out GitHub-generated branch

    names, and environmental names, the most common branch name is fixes
  5. @stahnma hard hitting stats 0.01% of workflows have English curse

    words in the name of the branch chances are, this isn’t you, as it was only 359 orgs, or 0.001% of orgs
  6. 29

  7. @stahnma 25 number of runs per day per project number

    of projects building this many
 times per day deployment frequency
  8. @stahnma 50p 95p 99p Max workflows per day per project

    3 29 74 2488 workflows per org per day 6 85 250 3036 workflows per project on master branch per day 1 13 39 2443 deployment frequency
  9. @stahnma 50p 95p 99p Max workflows per day per project

    3 29 74 2488 workflows per org per day 6 85 250 3036 workflows per project on master branch per day 1 13 39 2443 deployment frequency
  10. @stahnma • fastest recovery < 1 second • absolute max:

    30 days • median workflow recovery time 1044 min (17.5 hours) mttr
  11. @stahnma Language Fail rate on master Median branches Median users

    PHP 7.0% 5 2 JavaScript 9.5% 5 2 Python 10.6% 5 2 Ruby 10.9% 9 3 Go 12.4% 4 2 Java 13.1% 4 2
  12. @stahnma Language Fail rate on master Median branches Median users

    PHP 7.0% 5 2 JavaScript 9.5% 5 2 Python 10.6% 5 2 Ruby 10.9% 9 3 Go 12.4% 4 2 Java 13.1% 4 2
  13. @stahnma Language Fail rate on master Median branches Median users

    PHP 7.0% 5 2 JavaScript 9.5% 5 2 Python 10.6% 5 2 Ruby 10.9% 9 3 Go 12.4% 4 2 Java 13.1% 4 2
  14. conclusions few organizations look like what we hear in conference

    talks and see in cases studies and books.
  15. conclusions if you’re actively using CI (or at least CircleCI),

    you’re likely a high medium/ high performer or better
  16. Summary • Surveys are great, and data is great. •

    Everybody is not doing this better than you. • Few organizations look like what we hear in conference talks and see in cases studies and books. • If you’re actively using CI, you’re likely a high medium/high performer or better • The data show master/trunk based development tends to move faster • You should be writing PHP