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

Definitions

• 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

Principles

• 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