Abstract: Does your organization frown upon Build Breakers? Do you see a lot of “Who broke the build now?” emails? Do your team members hesitate to commit their code for the fear of causing a build failure?
If you wish to know what you can do to make the situation better, this session is for you.
Continuous Integration (shortly CI) is a powerful way to identify and eliminate certain risks, particularly when multiple teams are rallying towards a planned release. Even if you are not working on a planned release, Continuous Integration will help you to cut-out a release sooner than you would if you did not have CI.
When organizations or teams start adopting Continuous Integration for the first time, they develop an untold habit to chastise the build breaker, whenever a build breaks. Most of the time, the reprimanded build breaker is a person and not a thing, a machine or a process. This session aims to create a dialogue around the level of control a developer has on the build failures and how we can create meaningful outcomes by not blaming the developer who broke the build.
Learning Outcomes: - Effects of blame on effectiveness of CI
- Ideas and Techniques to avoid blame while implementing CI
- Tried and tested Metrics to build a Blameless CI culture
