In my organisation people regularly have 3K+ emails in their inbox. They're swamped and non-important email is ignored and lost. (Think big Corporation). Email ceases to be a useful medium in this environment. For a while on our CI Server (eg Jenkins) we ran builds that you could view the status of on the Jenkins site. This drove an ownership culture - if you did a commit - you would watch it go through on the server. If you didn't watch it, and it broke and someone else saw it - they would simply revert your commit. A consultant to our team came and said:It's an industry standard that build failures generate email notifications. You need to configure your CI server to email people when the build fails. This seemed a little strange, for something that is a configurable toggle on most CI servers. I'm happy for individual teams to say they want an email for their build, but to say everyone has to do it because it is an industry standard feels like they've misread our organisation's culture. (Fair call that we have a broken culture - but I'm just trying to change one thing at a time.)My question is: Is there evidence to suggest that email notifications of build-breakage from a ci-server are industry standard?
Is there evidence to suggest that email notifications of build-breakage from a ci-server are industry standard?
continuous integration;build system;culture;failure;notifications
Yes, it's an industry standard to notify not everyone, but only those whose changes are in the build when the build breaks.  The reason is that in any organization of reasonable size you have a certain percentage of people who do not conscientiously follow a build through CI.  If you don't do this, when a build breaks, whoever needed a clean build at the time will figure out whose change broke the build and do what? Manually send the culprit an email.Eventually people get annoyed at tracking down people that broke the build.  Having the CI server do it saves time and cuts out the middleman.  You only get the emails when your changes are in a broken build, so they are relatively low volume and you don't get conditioned to ignore them.  If you believe your company culture is fine how it is, then there's no reason to follow the standard, but you might want to consult with your most frequent broken build bounty hunters before making that decision.A lot of organizations now take it one step further and run CI on pull requests before they get merged as well as after, which is what I would consider the real industry standard.  I can't tell you how happy it made me when we finally got the infrastructure in place to do this.  It puts all the responsibility back on the person making the change and lowers the risk of broken builds to practically zero.