Using Visual Control to avoid broken build problems
- 1. Using Visual Control to avoid broken build problems Jesus Bouzada
- 2. Continuous Integration “… is a practice where members of a team integrate their work frequently. Each integration is verified to detect integration errors as quickly as possible” Martin Fowler
- 3. Problem Unattended broken build Subsequent changes delayed Wasted developer time
- 4. Inspiration: Lean Principles Use visual control so no problems are hidden Build a culture of stopping to fix problems to get quality right the first time
- 5. Solution Display builds status on Screens Group objectives to keep clean builds Imbed culture of stopping and fixing
- 6. Conclusion Before Each build broken for average of 2 hours per week After Each build broken for average of 10 minutes per week
- 7. Thank YOU for your attention!
Editor's Notes
- #2: “Use visual control so no problems are hidden”
- #3: Main practices:Maintain a code repository (Version Control System)Automate build (Continuous build process tool)Visible results of latest build (Green Screens)Keep the build fast
- #4: When developers commit code changes these sometimes break the build. This isoften not immediately noticed or acted upon. When other developers subsequentlyattempt to make further changes they either have to fix the problem themselves ortrack down the original breaker and agree a resolution.There are some opportunities to reduce waste in the development process:1) Ensure problem investigated immediately. 2) Avoid problem investigation and fix by 3rd party. 3) Avoid the complexity of multiple breaking changes.
- #5: Without feedback mediums, builds in a broken state have the tendency to stay broken, which defeats the purpose of Continuous Integration in the first place. Continuous build process tools offer ways of delivering feedback such as e-mail notifications and web dashboard. Unfortunately, these modes of communication are not very compelling as we get dozens of emails every day and web pages require us to actively go and seek the information. We live in an over-communicated society, and every bit of information has to compete for our attention. One of the most compelling ways to deliver feedback was to display the build status in public and make it stand out so developers involved in the breaking change quickly act upon it.
- #6: Full screen grid showing status of every single project of the group in each of the cellsGreen cell:-Fix time: Average of the time since fails until works again-Successful time: Percentage of time that worksRed cell:-Broken time-Breaker(s) name-Broken Build(s) nameGroup StatisticsOther features:Project status visible from 20 ft - Colour coded UK road signs alike to ensure good visibilityUpdate/refresh screens within 1 minuteMost basic hardware (mobile phones, etc)Customizable through a config fileStatistics (group/projects) indicator: when statistics are above required, ok icon shows it next to the number, when they go below, exclamation mark to notify it.Available for CCNet 1.4, 1.5 and 1.6
- #7: There has been a reduction of the wasted time by leaving the build broken from 5 hours (300 minutes) to ½ hour (30 minutes) spent to fix the build every 90 hours, which has brought direct profit to the company.
- #8: What questions do you have?What feedback could you give me?