当我的同事认为不需要在PC上进行测试时，他进行更改，提交然后进行推送。然后，他在生产服务器上进行测试，并意识到自己犯了一个错误。它每周发生一次。现在我看到他进行了3次提交，并在5分钟内将其推送到生产服务器。

我几次告诉他，这不是做好工作的方式。我不想再对他无礼，他在公司中的地位与我相同，他在这里的工作比我还要多。

我希望以某种方式惩罚这种行为，或使其尽可能不愉快。

在我开始之前，该公司使用诸如FTP之类的老式方法进行部署，并且没有版本控制。

我强迫他们/我们使用Git，Bitbucket，Dploy.io和HipChat。部署不是自动的，必须有人登录dply.io并按deploy按钮。

现在，如何强制他们不要在生产服务器上进行测试？像HipChat bot这样的东西可以感觉到同一行上有重复的编辑，并向程序员发送通知。

您需要适当的质量保证（QA）流程。

在专业的软件开发团队中，您不会从开发权投入生产。您至少拥有三个独立的环境：开发，登台和生产。

当您认为自己的开发环境中有工作时，您将首先进行阶段化，由QA团队对每个提交进行测试，并且只有在测试成功的情况下，才会将其推送到生产环境。理想情况下，开发，测试和投入生产由单独的人员完成。通过以某种方式配置构建自动化系统，可以确保这一点：开发人员只能从开发阶段部署到阶段，而QA团队只能从阶段部署到生产。

如果您不能说服管理层聘请某人来进行质量检查，那么也许您中的一个可以扮演另一个角色。我从未使用过diploy.io，但是可以以某种方式配置一些构建自动化系统，即用户可以将其从开发部署到阶段，也可以从阶段部署到生产，而不能在同一构建中同时部署，因此始终是第二个人必需的（但请确保在其中一个人不在时，有一些备用人员）。

另一种选择是让您的支持人员进行质量检查。对于他们来说，这似乎是一项额外的工作，但它还可以确保他们知道对应用程序的任何更改，从长远来看可以确保他们的工作安全。

您可能会想要获得一个开发服务器，并且最好是一个暂存环境。除了自己的个人网站，任何人都不应从本地推动生产。您的部署过程应仅支持dev-> staging-> prod。您可能希望有人负责签署新版本-根据组织的不同，这可以是项目负责人，专门的质量检查人员或每周轮换的职责（有形的提醒，例如，只有那个星期拥有蓬松玩具的人才能推）。但是，请先与您的团队讨论以取得支持（请参阅下文）。

我希望以某种方式惩罚这种行为，或使其尽可能不愉快。

您可以让您的测试套件（您有其中一个，对吗？）包括一张支票，该支票确定您是否在生产服务器上，如果有，则向办公室中的每个人发送一封电子邮件，说Looks like $username is testing on prod, watch out。也许公开羞辱您的同事将是不愉快的。或者，您可以创建技术限制，例如禁止IP团队查看产品（您可以取消，但必须证明理由）。

但是，我不建议这样做，您看起来像是问题，而不是对产品进行测试的人，并且您可能会让自己变得不受团队中那些不在乎的人的欢迎。

当然，您真正想要的不是要对这种行为进行惩罚，而是要制止这种行为？

我强迫他们/我们使用[...]

您一直在倡导改进工作流程，这很好，但是听起来您要么不怎么想您的同事和/或您没有他们的全力支持。这可能会导致同事与工作流程进行半热的交互，进行使代码投入生产所需的最少工作，而不是真正遵循工作流程的精神，这意味着要花费更多的时间进行清理。而且，当您花费越来越多的时间来清理与工作流交互不足的结果时（因为没人关心，对吗？），其他所有人都会质疑工作流本身。

因此，从对话开始。

找出原因（您的同事的机器不适合测试吗？您的同事不确定功能分支还是卡在提交和推送相同的svn心态中？），解释一下为什么未经测试的代码对您来说是一个问题在dev / staging / prod上，看看是否可以做一些改变它发生的原因（如果您只是想更好地在本地进行测试，而不仅仅是指责他们，那么您的同事将更有可能做您想要的事情）。

如果您无法解决它，并且确实导致了意见分歧，请在下一次回顾会议中安排全团队讨论，看看同事的想法。提出您的看法，但听听共识。也许您的团队说不要在本地测试文本修复是可以的，并且您只有一条规则，即未经测试的开发人员不得使用任何重大功能。在会议上写下来，然后读出您共同决定的关于每种环境所允许的内容的内容。在几个月后设定一个日期进行审核，也许是回顾性的。

在工作中，我们通过使用Gerrit来避免这种情况。Gerrit是一个代码审查系统，可以充当主/生产Git分支的大门，该分支通常称为“主”。您有代码审查，对不对？听起来您个人非常出色。使用Gerrit，您可以进入一个暂存分支，在您和您的同事令人满意地执行了代码检查过程之后，该分支便会合并到您的master分支中。您甚至可以在任何人收到一封电子邮件以查看更改之前，将Gerrit挂接到CI服务器上以执行单元测试。如果没有服务器，则可以设置CI工具，Codeship有一个不错的免费计划，可以用作概念证明。

最后，当然是仅从经过代码审查和单元测试后获得批准的构建产品中自动化生产部署。为此，出现了一些很酷的技术，我不会提及这些，因为这会引起火焰诱饵。

向老板寻求解决方案。这甚至适用于您，并且是一种提高每个人的代码质量的方法，而不仅仅是惩罚您的同事。

我认为这是一个主要的人为问题-流程在那儿，工具在那儿，但流程并未得到遵守。

我同意其他人在这里所说的话，即有关开发人员很可能只是停留在SVN思维方式中，并且很可能以为他正在遵循该程序。

我发现解决此类问题的最佳方法，尤其是在可能没有明显的上级领导的情况下，并不会围绕惩罚或取消访问权限而行-这只会导致怨恨，而且听起来您是追随者的强烈拥护者这个过程（总是有一个过程，而我以前一直是“那个家伙”），您是最有可能应对的过程。它围绕着使人们首先就流程达成共识而展开。

在这里，组织性会议（如生产中的重大事件后的“经验教训”型会议）非常有用。尝试使所有人（包括有问题的开发人员）都同意每次都需要进行代码审查，单元测试，全面测试等（并且您也可以在此处开始介绍暂存环境的想法）。这不应该很难，而且非常明智。然后要求团队共同制定一些可靠的规则，以决定应如何执行。导致问题的开发人员贡献的越多，他们越会遵守规则，并开始明白为什么他们的行为成为问题。

最后一点，是永远不要陷入“好，它比以前更好了！” 陷阱。总有改进的余地。根据我的经验，IT行业的人们通常会在经过一些改进后开始着手解决自己的问题。然后继续解决，直到您突然再次处于危机点。

这并不罕见，尤其是在小型团队中。对此不要做太多事情，但要制定一个非正式规则：

中断构建，加入甜甜圈。

1）每周吃两次甜甜圈，或2）遵守标准。

在会议上提出来。毫无疑问，不要提任何人的名字，而是类似，“自从我们引入了版本控制和部署标准以来，事情变得更加容易，服务器的运行时间也比以往更多。这太好了！但是，尝试通过捷径提交而不进行适当的测试仍然很诱人，尽管这是一场赌博，但是我们的服务器已经上线了。我建议从现在开始，如果我们中的任何人提交了破坏服务器的代码，负责人都会带进来第二天为团队准备甜甜圈。”

如果需要，可以用其他东西代替甜甜圈，并且不要太贵-整个团队的午餐会太多，但是5美元一盒的甜甜圈或水果/蔬菜托盘，薯条和蘸酱等可能会令人讨厌足以使他们真正权衡风险与跳过测试的便利性之间的联系，而又不会使其负担加重，从而使他们脱离团队或公司。

现在，我该如何强迫他们...

与其强迫您的同事，不如让他们从您的角度看待事情。这将使每个人都容易得多。导致我进入...

我希望以某种方式惩罚这种行为，或使其尽可能不愉快。

为什么在实时服务器上遇到问题对您来说是一种痛苦，但是对于这个人却不是呢？你知道他不知道的吗？您该怎么做才能使他以您的方式看待事情？

如果您成功做到这一点，您将发挥出他的才华，他将为您从未想到的问题找到解决方案。

通常，尝试与人们一起解决问题，而不是强迫他们陷入无法理解的过程。

可能发生的最坏情况是什么？您是否有足够好的备份，以便可以通过恢复旧版本来修复修改数据库中随机记录的错误？

假设您在使用记录ID时遇到了一个错误，并且错误地将以美分计的账单金额存储在用于记录ID的变量中。因此，如果我支付$ 12.34，则ID为1234的记录将被修改。如果该软件运行了几个小时直到检测到该错误，您可以从中恢复吗？（如果同时更新了正确的记录和记录1234，则只有在使用记录1234时，您才会检测到此记录，因此可能会在一段时间内检测不到该记录）。

现在，请问您有上进心的开发人员对此有何看法。显然，他不能声称自己从未犯过错误，因为他过去曾经犯过错误。

您清楚地了解各种可能的过程和技术解决方案。问题是如何管理同事。

这本质上是一项变更管理工作。

首先，我会与创始人保持沉默，以确保他/她支持您的观点。如果发生生产中断，我希望创始人会对此非常关注，并希望改变。

其次，您在一个小团队中工作，可能值得尝试使整个团队参与流程改进。

设置定期（例如每周）的过程回顾。拥有整个团队：

• 找出问题
• 改善工作实践的志愿者想法
• 参与实施这些做法

因此，整个团队自然也应该帮助确保遵守改进的做法。

我认为您已经发现了两个问题：

1. 听起来好像任何有权检查代码的人都可以将任何被检查的代码轻而易举地推入生产环境。

坦率地说，我认为设置太疯狂了。至少可以手动触发推送生产的人员应仅限于完全值得信任的人员，以便在触发推送之前彻底检查和测试所有出站更改（无论谁编写了更改）。授予任何人允许检入代码的权力也可以任意触发生产，这只是在制造麻烦。不仅来自粗心和/或不称职的开发人员，还来自不满的开发人员或恶意的第三方，这些人恰巧损害了您的一个帐户。

而且，如果您打算使用按钮式流程来部署所有已签入的更改，那么您需要拥有一套全面的自动化测试套件，并且按下按钮就需要运行它们（并在部署失败时中止部署）任何测试都会失败！）。您的流程不应允许未经表面测试的代码就可以将代码首先部署到生产系统。

您的同事在检入代码而不先对其进行测试方面犯了一个大错误。您的组织采用了允许任何情况下未经测试的代码进入生产的部署过程，从而犯了一个更大的错误。

因此，首要任务是修复部署过程。要么限制谁可以触发生产，要么将合理数量的测试合并到您的自动部署过程中，或者两者兼而有之。

2. 听起来您可能尚未设置任何明确定义的开发标准/原则。

特别是，听起来好像您缺少一个明确的“ 完成定义 ”，和/或使用不包含“代码已测试”的代码作为检查代码输入/将代码部署到生产环境的主要因素。如果您有这个建议，您可以说“此代码不符合我们大家都同意的最低标准，而它需要更好，未来”。

您应该尝试建立一种文化，清晰地传达开发人员的期望以及开发人员要坚持的标准和质量水平。建立完成的定义至少包括手动测试（或者最好是可以作为构建/部署过程的一部分运行的自动测试用例），将对此有所帮助。可能会破坏构建。或更严重的后果是破坏生产系统。请注意，这两件事实际上应该是独立的，并且完全不可能同时中断构建和生产系统（因为中断的构建永远不可部署）。

您应该在公司中集成持续集成+同行评审流程。Bitbucket使它变得容易。

并为其他用户建议的开发服务器+1。

不要对他不礼貌，只会伤害你的工作关系。