1

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?

hawkeye
  • 4,819
  • 3
  • 24
  • 35
  • Generally if the company is willing to pay for the advice of a consultant, that means they value the advice of the consultant over that of an employee which is a cheaper sunk cost. We perceive value largely on how much it costs us to obtain. With that being said, it is a good idea to at least give benign consultant advice a shot and not try to belabor the point. You should always at least appear to be open minded to a consultant advice even when you think they are wrong. – maple_shaft Dec 08 '16 at 13:36
  • 3
    "They're swamped and non-important email is ignored and lost." Don't we have email folders and rules for this? – Ben Aaronson Dec 08 '16 at 14:10
  • 1
    Consider bringing in a consultant who can deal with the "3K+ emails in their inbox" lossy communication stream – Caleth Dec 08 '16 at 14:25
  • 3
    `If you didn't watch it, and it broke and someone else saw it - they would simply revert your commit.` This is a process smell - you should be using branches so that untested commits don't break other people's builds. There's no reason to revert commits if it's on a branch that doesn't affect anyone but you – Daenyth Dec 08 '16 at 14:38
  • One more email is the less of your problems here. You have 2999 more ahead. I barely can deal with 10 a day – Laiv Dec 08 '16 at 18:23

4 Answers4

7

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
5

It is beside the point. Industry standard is a bit of a problematic term, since it does not necessarily indicate that the practice is good. The consultant probably just use this term because it is a lot easier than making a lengthy argument of the justification and benefits of a particular practice. But most likely the consultant indeed believe that the email notification is a good idea and would recommend you adopt it. Therefore, a discussion whether the practice is "industry standard" is irrelevant.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
0

Email notifications were the standard way, years ago. Some people use chat notifications, but they have the same problem. Instead of having 3000 emails you now have 3000 chat messages.

Tools like CatLight build notifier try to solve this problem. This app will show current build status in one icon. Now, instead of reading through thousands of emails, developer can just look at tray and immediately know if he needs to fix a build.

CatLight build notifier tray icon

You can also read more about difference between email notifications and CatLight

alex
  • 261
  • 1
  • 4
-1

I think its more common to send the alert to slack these days.

However.

  • You have hired a consultant to advise you
  • You don't like the advice and are asking random people on the internet what they think

Do you not think that's a bit odd?

Ewan
  • 70,664
  • 5
  • 76
  • 161