[2019 oracle code one] DevOps Theory vs Practice

DevOps Theory vs Practice: A Song of Ice and Tire Fire

Speakers: Viktor Gamov (@gamussa) & Baruch Sadogursky (@jbarauch)

Deck: https://jfrog.com/shownotes/

For more blog posts, see The Oracle Code One table of contents

Humor from imaginary thought leader (make sure you enjoy sarcasm in this section)

  • “Everybody’s software must be releasable at absolutely any time” – even if drunk?
  • “Everyone must have 100% test automation” – even if release 3-4 times a user to 2-3 users. cost makes sense
  • “We do Continuous Security well” – even if hire security person so have someone to blame
  • “Your greatest threat is an outage. Not an employee; just trust your employees” – even if CIO leaves bus with all data.
  • “VMs are the enemy of DevOps. This is where you must focus your innovation, Docker and Kubernetes” – Even for app just migrated from mainframe and not container ready
  • “You are a beautiful unique snowflake as are your problems. No vendor could possibly understand them.” So should invent own framework b/c written by other people.
  • “Our company is based in SF b/c that’s where the best engineers are”. Expensive b/c rent high

Four Questions

  • Is org/team ready to adopt new tech?
  • Is it even good tech? What do you know besides the demo? Where is it on Gartner’s hype curve? Thoughtworks Technology Radar – https://www.thoughtworks.com/radar
  • What problem do I solve by using this tech? What problem are you trying to solve? Not resume driven development
  • Will solving this problem help my organization?

Random notes

  • You are not NetFlix. Running chaos monkey on your network of ATM machines not a good idea.
  • Master Excel or Google Spreadsheets

Maturity models

  • Think about capabilities when trying to accelerate software development, not maturity models
  • Bad maturity models are bad
  • Bad models – goal driven. Get to goal and then are “done” improving, one size fits all from book, checkboxes for tools, write and forget
  • Good models – process driven, focus on outcomes
  • Components – evaluation factors (ex: is there a CI process), scoring methodology (is there partial credit), self assessment vs 3rd party assessment (how know if good process), progress tracking (of evolution), visualization (to show to people with different levels of involvement)
  • Different levels of detail for capabilities
  • Account for priorities of different teams – engineering, ops, business
  • Only use primary colors
  • Involve team in involving model definition and assessment
  • Partner with forward looking teams
  • Evolve model over time

My take

The intro was hilarious. The content was good as well 🙂

[2018 oracle code one] Better Software, Faster: Principles of Continuous Delivery and DevOps

Better Software, Faster: Principles of Continuous Delivery and DevOps
Speaker: Bert Jan Schrijver

For more blog posts, see The Oracle Code One table of contents

Audience survey

  • Started with a survey on how long doing development. A lot of people 10-15 years. One guy over 30
  • Most people said they were doing CI. Many hands went down when asked if commit daily, if build fals and if fixed within ten minutes


  • Continuous Integration – integrate frequently.
  • Continuous Delivery – build and test so can release at any time
  • Continuous Deployment – every change goes through build/test pipeline and automatically goes to prod
  • DevOps – dev and ops engineers working together; jointly responsible


  • Automate (almost) everything – faster and more repeatable
  • Keep everything in version control
  • If it hurts, do it more often. Bring the pain forward. Get better at it that way
  • Build quality in.
  • “Done” means actually released. It needs to be in a build/deployed
  • Entire team is responsible for delivery process
  • Continuous improvement

Ingredients of CD

  • Culture & Organization
    • agile
    • build the right thing/build the thing right
    • support what you build
    • cross functional teams
    • leave room to experiment/fail
    • Fun approach: biggest screw up of week got to park closest to door
  • Design & Architecture
    • Version control
    • Modularity
    • Branching strategy – don’t have long lived branches
    • Database changes
    • Design for failure
    • Feature toggles
  • Build & Deploy
    • Pipelines – automated sequence of stages to deliver software from version control to your users
    • Types of pipelines: build and deployment – try to roll forward, not back
  • Test & Verification
    • Need a testing strategy
    • Test automation – can’t keep testing manually
    • Non functional requirements – when requirement not met, it makes the system non- functional
    • Security testing
    • Performance testing
    • Verify expected business value is met
  • Information & Reporting
    • Static code analysis
    • Traceable pipelines
    • Automatic change logs
    • Usage metrics – actual data to determine if data is used
    • Dynamic dashboards – let users adapt to what need
    • Data driven decisions – act on metrics
    • Fix problems before users notice

Continuous Delivery vs DevOps

  • The term DevOps came first
  • DevOps is about freedom and responsibility. It is about having empathy. Other teams are neighbors, not blockers.
  • Lack of CD excuses – regulation, not building website, too much legacy code, people not smart enough
  • Actual reasons for lack of CD – culture, architecture

Pattern or antipattern?

  • Continuous delivery without devops – pattern
  • Uniform build pipelines – both. Easy to change, but limits flexibility
  • Long pipelines – anti-pattern. People won’t wait. Feedback slow.
  • Obsess over test automation – pattern
  • Logging and metrics for ops only – anti-pattern
  • Obsess over feedback loops – pattern
  • Manual steps in a delivery pipeline – both. Good to have automated
  • Long living branches – anti-pattern
  • Dev/prod parity – anti-pattern
  • Design for failure – pattern
  • Tests don’t provide business value – anti-pattern. They prevent issues. A working system is definitely is business value.
  • Parallelized pipelines – Pattern
  • Continuous Delivery = Continuous Deployment – anti-pattern. For most companies, deploying to prod every sprint/two weeks is fine.
  • Automate database changes – pipeline
  • Testing NFR’s in the build pipeline – pattern

My take: This was an excellent review. Bert started by saying this was an intro. On some level, he’s right. Although I think this would be a drinking from a firehose thing if completely new. I’m at the point where having the review was a good way of settling in my mind why we do certain things. I missed a couple of the patterns/anti-pattern q & a but they were really good 

[2018 oracle code one] CD/DevOps Live Cooking Show

Continuous Delivery/DevOps Live Cooking Show
Speaker: Michael Huttermann (had trouble making the umlat)

For more blog posts, see The Oracle Code One table of contents


  • Many definitions
  • Shared concepts, goals, tools

Early “DevOps” authors

  • Adam Smith
  • Edwards Demings
  • Eliyahu Moshe Goldratt


  • Short cycle time from workspace to deploy/cloud. Helps to create own definition; doesn’t require a tool
  • Create pipeline – start with a value stream map
  • Need tools to accelerate cycle time
  • Pipeline is a donut, not a tube
  • Glue together existing tools
  • Use quality gates
  • Implement high degree of automation. Doesn’t need to be 100% automation


  • Make up the workflow
  • ex: continuous build, dev build, release candidate build, general availability build
  • Showed about 20 different steps for a pipeline
  • DevOps – contains a number of concerns so no need to say DevSecOps specifically [I have DevSecOps in two of my talk titles here to emphasize security]

Demo (selected stages)

  • Showed in Jenkins a number of jobs each. Many had a green box/description before it. Like a group? [how do you do that?]
  • Commit and push
  • Showed sonarlint giving feedback on code before push.
  • Blue Ocean view in Jenkins to show pipeline
  • Showed quality gate failing in SonarQube

My take: I like that the first half was lecture and the second half was a demo. It was the longest pipeline I’ve seen to date.