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