在我的组织里,人们经常在收件箱里发3K+电子邮件。他们被淹没,不重要的电子邮件被忽视和丢失。(想想大公司)。在这种环境下,电子邮件不再是一种有用的媒介。
在我们的CI服务器(如Jenkins)上,我们运行了构建,您可以查看Jenkins站点上的状态。这驱动了一种所有权文化--如果您进行了提交--您将看到它在服务器上运行。如果你不看它,它坏了,其他人看到它-他们只会恢复你的承诺。
我们小组的一位顾问前来说:
这是一个行业标准,构建失败会产生电子邮件通知。您需要配置您的CI服务器,以便在构建失败时发送电子邮件给用户。
对于大多数CI服务器上的可配置切换来说,这似乎有点奇怪。我很高兴单个团队说他们想要一封电子邮件来构建他们的构建,但是说每个人都必须这样做,因为这是一个行业标准,感觉他们好像误解了我们的组织文化。(公平地说,我们有一个破碎的文化--但我只是试着一次改变一件事。)
我的问题是:是否有证据表明,来自ci服务器的构建破坏电子邮件通知是行业标准?
发布于 2016-12-08 14:20:10
是的,这是一个行业标准,不是通知每个人,但只有那些在构建时,其更改是在构建中断。原因是,在任何合理规模的组织中,都有一定比例的人不自觉地通过CI进行构建。如果你不这样做,当一个构建崩溃时,谁在当时需要一个干净的构建,就会发现谁的改变破坏了构建,并做了什么?手动发送一封电子邮件给罪犯。
最终,人们对追踪破坏了构建的人感到恼火。让CI服务器来完成它,节省了时间,减少了中间人。只有当你的更改在一个坏的版本中时,你才会收到电子邮件,所以它们的音量相对较低,而且你不会习惯于忽略它们。如果你相信你的公司文化是如此的好,那么没有理由遵循这个标准,但是在做出这个决定之前,你可能想要咨询你最常见的坏掉的“赏金猎人”。
许多组织现在更进一步,在合并之前和之后对请求执行CI,这就是我认为真正的行业标准。我无法告诉你,当我们最终建立起这样的基础设施时,这让我有多高兴。它把所有的责任都推给了做出改变的人,并将破坏建筑的风险降低到几乎为零。
发布于 2016-12-08 14:00:58
这不是重点。行业标准是一个有问题的术语,因为它不一定表明实践是好的。顾问可能只是使用这个术语,因为它比长篇大论地论证某一特定实践的理由和好处要容易得多。但最有可能的是,顾问确实认为,电子邮件通知是一个好主意,并会建议你采用它。因此,讨论实践是否是“行业标准”是不相干的。
发布于 2017-03-31 18:48:33
几年前,电子邮件通知是标准的方式。有些人使用聊天通知,但他们也有同样的问题。而不是有3000封电子邮件,你现在有3000条聊天信息。
像CatLight生成通知程序这样的工具试图解决这个问题。这个应用程序将在一个图标中显示当前的构建状态。现在,开发人员不必阅读数千封电子邮件,只需查看托盘,立即知道是否需要修复构建。

您还可以阅读有关电子邮件通知与CatLight的区别的更多信息。
https://softwareengineering.stackexchange.com/questions/337758
复制相似问题