1. Critical capability
1.1. A pivot in DORA
2. IS
2.1. What
2.1.1. be able to release software
2.2. When
2.2.1. on demand
2.3. How
2.3.1. quickely
2.3.2. safely
2.3.3. sustainability
2.4. Where
2.4.1. Any kind of software context changes
2.4.1.1. Complex modern distributed systems update
2.4.1.2. Infrstructure & config change
2.4.1.3. Database schema change
2.4.1.4. Firmware auto update
2.4.1.5. Mobile app new version
2.4.1.6. Mainframe update
2.4.1.7. ...
2.5. aka
2.5.1. perform low risk release during business hours
3. Misunderstanding
3.1. Continuous delivery vs Continuous deployment
3.1.1. Continous deployment
3.1.1.1. What
3.1.1.1.1. deploy EVERY code change
3.1.1.2. When
3.1.1.2.1. asap
3.1.1.3. Where
3.1.1.3.1. to prodction
3.1.1.3.2. usually WebApp
3.1.2. So
3.1.2.1. Is great
3.1.2.2. Is different from continuous delivery
3.2. Contiuous delivry vs Regulated and safety domains
3.2.1. Continuous Delivery reduce software risk
3.2.1.1. Is about reducing software RISKs
3.2.2. So, works weel with Regulated and safety domains
4. Requirements
4.1. From DORA findings
4.2. DevOps tech capabilities
4.2.1. Continuous testing
4.2.2. Deployment automation
4.2.3. Trunkbased development
4.2.4. Shift left on security
4.2.5. Losely coupled architecture
4.2.6. Empowering teams to choose tools
4.2.7. Continuous integration
4.2.8. Version control
4.2.9. Test data management
4.2.10. Data base change management
4.2.11. Code maintenability
4.3. DevOps measurement capabilities
4.3.1. Monitoring and observability
4.3.2. Proactive failure notification
5. J-curve
5.1. J-Curve of transformation
6. Pitfalls
6.1. If other DevOps tech capability are missing
6.1.1. Increasing deployment frequence
6.1.2. May lead to more outages
6.2. If J-curve impact are not mitigated
6.2.1. Only quick automation win will be realize
6.2.2. May lead to be stuck into Medium perf
6.2.3. Value stream mapping helps to prioritize efforts
7. Measure
7.1. 4 DORA key metrics
7.1.1. Throughput (dev)
7.1.1.1. 1 Deployment frequency
7.1.1.1.1. To production
7.1.1.1.2. Or public release
7.1.1.2. 2 Lead time for changes
7.1.1.2.1. From code commit
7.1.1.2.2. To
7.1.2. Stability (ops)
7.1.2.1. 3 Change failure rate
7.1.2.1.1. % deployment or release leading to degraded experience
7.1.2.2. 4 Time to restore
7.1.2.2.1. Unplanned outages