我希望以某种方式对这种行为进行惩罚。或使其变得尽可能不愉快。
在开始之前，该公司使用诸如FTP之类的老式方法进行部署，并且没有版本控制。他们/我们使用Git，Bitbucket，Dploy.io和HipChat。部署不是自动的，必须有人登录dply.io并按一下部署按钮。像HipChat bot这样的东西可以感知到同一行上的重复编辑，并向程序员发送通知。
#1 楼
您需要适当的质量保证（QA）流程。在专业的软件开发团队中，您不会从开发权过渡到生产。您至少有三个独立的环境：开发，暂存和生产。
当您认为自己在开发环境中有工作时，请首先进行暂存，其中每个提交均由质量检查团队进行测试，并且只有该测试成功后，它才会投入生产。理想情况下，开发，测试和投入生产由单独的人员完成。通过以某种方式配置构建自动化系统可以确保这一点，即开发人员只能从开发阶段部署到阶段，而QA团队只能从阶段部署到生产。
当您无法说服管理时聘请某人来进行质量检查，那么也许你们中的一个可以扮演另一个角色。我从未使用过diploy.io，但是可以以某种方式配置一些构建自动化系统，即用户可以从开发到部署以及从部署到生产都进行部署，但不能在同一构建中同时部署，因此始终是第二个人必需的（但请确保在您一个人不在的时候有一些备用人员）。对于他们来说，这似乎是一项额外的工作，但它还可以确保他们知道对应用程序的任何更改，从长远来看可以保护他们的某些工作。
评论
支持进行涉及发布到生产的QA的想法似乎很方便，但是由于功能分离的原因而无法实现。在“程序员测试”结束后，负责支持的支持应该使他们知道更改。对于四个开发人员，没有其他人，这真的很困难：-)如果您更改了答案以直接应用于OP的设置，则对其他人没有多大用处...
–比尔·伍德格
15年7月11日在8:32
@BillWoodger为什么？对于他们来说，这是一个“即将发生的变化和回滚”系统。它们不仅获得了在“真实”之前看到即将发生的变化的好处，而且还可以在情况恶化时轻松回滚到最新版本。不要忘记暂存环境是程序员的最终测试。
– gbjbaanb
15年7月13日在7:42
@gbjbaanb，因为它将支持放在同一位置并重述了原始问题。支持通常可以紧急访问生产。如果他们还有其他访问权限，那么您将遇到审核问题（如果很重要）。如果任何人都可以更改任何内容，那就有问题了。当然，支持人员应该了解所有事情，而他们却无能为力。这就是我所参与过的每位审计师所说的话，他们很早就说服了我。
–比尔·伍德格
15年7月13日在9:36
@BillWoodger我不确定您在说什么。我知道的生产团队通常都有自己的发布流程，其中包括一个测试环境（只是为了先检查傻错误）。在一个小型团队中，没有理由不能由开发人员和支持人员共享此测试系统。无论如何，都不允许对其进行任何更改-由开发人员通过自动化填充，并由支持部门使用。给他们一个相同代码的邮政编码没有什么不同。审核员关注的是流程，而不是流程的执行情况（当然要遵循这些流程）
– gbjbaanb
15年7月13日在9:41
@gbjbaanb审核员关注有权访问所有内容的人员。如果支持人员可以在开发过程中更改程序并将其投入生产，而无需任何其他人的干预，则该系统将被公开。当然，对于OP的四个人来说，没有单独的“支持”，而令人满意的功能划分将非常棘手。
–比尔·伍德格
15年7月13日在9:43
#2 楼
您可能会想要获得一个开发服务器，最好是一个暂存环境。除了自己的个人网站，任何人都不应从本地推动生产。您的部署过程应仅支持dev-> staging-> prod。您可能希望有人负责签署新版本-根据组织的不同，这可能是项目负责人，专门的质量检查人员或每周轮换的职责（有形地提醒，例如，只有那个星期穿着蓬松玩具的人推）。但是，请先与您的团队讨论以取得支持（请参见下文）。 br />您可以让您的测试套件（您拥有其中的一个，对吗？）包含一项检查，该检查确定您是否在生产服务器上，如果存在，则将所有人发送到办公室的电子邮件说
Looks like $username is testing on prod, watch out。也许公开羞辱您的同事将是不愉快的。或者您可以创建技术限制，例如禁止IP团队查看产品（可以取消，但必须证明理由）。我不建议这样做，尽管您看起来像问题，而不是测试产品的人，您可能会让自己变得不受团队中那些不在乎的人的欢迎。但要停止吗？
我强迫他们/我们使用[...]
您一直在倡导改进工作流程，这很好，但是听起来您要么不怎么想您的同事和/或您就没有他们的全力支持。这很可能导致同事与工作流程进行半热的交互，进行使代码投入生产所需的最少工作，而不是真正遵循工作流程的精神，这意味着要花更多的时间进行清理。而且，当您花费越来越多的时间来清理与工作流交互不足的结果时（因为没人关心，对吗？），其他所有人都会质疑工作流本身。 。
找出发生这种情况的原因（您同事的机器是否不适合测试？您的同事不确定功能分支还是陷入了提交和推送相同的svn心态中？），请解释为什么对您来说，未经测试的代码会在dev / staging / prod上进行是一个问题，看看您是否可以做一些事情来改变它发生的原因（如果您只是想让本地测试比在本地测试更好，那么您的同事将更有可能做您想要的事情如果您刚刚对他们进行了指责）。
如果您不能解决它，并且确实导致了意见分歧，请在下一次回顾会议中安排一次全团队讨论，看看您的同事做了什么想一想。提出您的看法，但听听共识。也许您的团队说不要在本地测试文本修复是可以的，并且您只有一条规则，即未经测试的开发人员不得使用任何重大功能。在会议上写下来，然后读出您共同决定的关于每种环境允许的内容。在几个月后设定日期进行审核，也许是回顾性的。
评论
为对话+1。必须达成共识，这是一个问题以及为什么是一个问题。只有这样，技术解决方案才能成功。
–帕特里克（Patrick）
15年7月11日在9:24
+1用于获取开发服务器/暂存环境。除非在自己的机器外面有一个真正的地方来推东西，否则这种行为并不完全是同事的错。一个人只能在自己的机器上做很多事情，如果没有其他事情，额外的环境通常可以帮助改变测试的思维过程/态度。
–乔尔·科恩（Joel Coehoorn）
15年7月12日在0:57
#3 楼
在工作中，我们通过使用Gerrit来避免这种情况。 Gerrit是一个代码审查系统，可以充当主/生产Git分支的大门，该分支通常称为“主”。您有代码审查，对不对？听起来您个人做得特别好。使用Gerrit，您可以进入一个暂存分支，在您和您的同事令人满意地执行了代码检查过程之后，该分支便会合并到您的master分支中。您甚至可以在任何人收到一封电子邮件以查看更改之前，将Gerrit挂接到CI服务器上以执行单元测试。如果您没有服务器，则可以在其中设置CI工具，Codeship有一个不错的免费计划，可以用作概念验证。仅来自经过验证的构建产品，这些产品在代码审查和单元测试中均幸免于难。为此，出现了一些很酷的技术，我不会提及这些技术，因为这可能会成为诱饵。这甚至适用于您，并且是一种提高每个人的代码质量的方法，而不仅仅是惩罚您的同事。#4 楼
我认为这是一个主要的人为问题-过程存在，工具也存在，但过程并未遵循。有问题的开发人员很可能只是停留在SVN思维方式中，并且很可能以为他正在遵循该过程。我发现解决此类问题的最佳方法，尤其是在可能不是明显的上级，不会围绕惩罚或取消访问权限-这只会导致怨恨，而且听起来您是遵循该过程的大声拥护者（总是有一个，并且我以前一直是“那个家伙” ），那么您就是最会发热量的人。它围绕着使人们首先就流程达成共识的方式进行。尝试使所有人（包括有问题的开发人员）都同意每次都需要进行代码审查，单元测试，全面测试等（并且您也可以在这里开始介绍暂存环境的想法）。这不应该很难，而且非常明智。然后要求团队共同制定一些可靠的规则，以决定应如何执行。导致问题的开发人员贡献的越多，他们越会遵守规则，并开始明白为什么他们的行为一直是问题。变成了“好，它比以前要好！”陷阱。总有改进的余地。根据我的经验，IT行业的人们在进行一些改进后开始着手解决他们的问题。然后继续解决，直到您再次突然处于危机点。
评论
我真的不清楚SVN的思维方式是“提交/推送，立即部署到生产环境并在那里进行测试并在其他任何地方进行测试” ...涉及SVN的过程的唯一部分就是提交。即使使用单个分支模型或源代码控制，提交也不一定意味着生产部署。或至少不应该如此。
– jpmc26
15年7月13日在23:54
@ jpmc26：冒着Git / SVN火焰之战的危险：我们为许多“旧版”代码继承了SVN系统，但一直在使用Git进行新工作。我几乎可以保证我们没有正确设置SVN和/或没有正确使用它，但是Git处理分支感觉更容易使用。我100％确信SVN能够处理适当的部署，但我还可以（从我的不完善的经验中）看到SVN如何“阻止您做正确的事”。无论如何，这仅是一个贡献因素，对用户的教育更为重要。
– TripeHound
15年7月14日在14:05
@TripeHound没有关于git系统总体上可以更好地管理代码更改的论据。 （我对git的异议通常与学习曲线有关。）我的观点是，尽管git可能具有更多功能来帮助管理发布过程，但建立构建基础结构的方式仍然是影响您的主要因素选择源代码控制。在相当长的一段时间里，我在SVN中进行了相当成功的构建和发布自动化，因此我不清楚“ SVN思维方式”是什么，或者它对发布的负面影响。
– jpmc26
15年7月14日在17:42
仅仅因为您致力于掌握并不意味着您应该部署到生产环境。即使您的原始回购/ svn回购托管在产品服务器上，也并不暗示这种情况。
– vonPetrushev
15年7月15日在12:38
#5 楼
这并不罕见，尤其是在小型团队中。没什么大不了的，但是要制定一个非正式的规则：破坏构建，引入甜甜圈。
1）您将获得两次甜甜圈一周或2个），他们将遵守标准。
在会议中提出。毫无疑问，不要提任何人的名字，而是类似，“自从我们引入了版本控制和部署标准以来，事情变得更加容易，服务器的运行时间也比以往更多。这太好了！但是，尝试通过捷径提交而不进行适当的测试仍然很诱人，尽管这是一场赌博，但是我们的服务器已经上线了。我建议从现在开始，如果我们中的任何人提交了破坏服务器的代码，负责人都会带进来第二天给团队吃甜甜圈。”
如果需要的话，用别的东西代替甜甜圈，而且不要太贵-整个团队的午餐会太多，但是5美元一盒的甜甜圈水果/蔬菜托盘，薯条和蘸酱等可能会很烦人，以至于使他们实际权衡风险，而忽略跳过测试的便利性，而又不会给团队或公司带来负担。 >
评论
这仅适用于办公室。当您有一个分散的远程开发人员团队，而这些人员都在家工作时，该概念是什么？
–aroth
15年7月14日在10:18
@aroth对于某些团队来说，从破坏构建的人那里获得一封简单的团队范围的电子邮件就足够了。将其计划为“持续改进过程的目标”，并要求电子邮件包含足够的信息，以便其他人可以查看出现了什么问题，为什么出错了，该人将对其过程进行哪些更改或他们建议团队进行哪些更改这个过程，以防止它再次发生。大多数人都讨厌报告和报告，这再次使他们感到烦恼，他们可能会更加小心，不要在将来破坏版本。
–亚当·戴维斯（Adam Davis）
15年7月14日在14:45
#6 楼
现在，我该如何强迫他们...
与其强迫您的同事，不如让他们从您的角度看待事情。这将使每个人都容易得多。这导致我陷入...
我希望以某种方式惩罚这种行为或使其不愉快
。
为什么在实时服务器上遇到问题对您来说是一种痛苦，而对于这个人却不是呢？你知道他不知道的吗？
如果成功了，您将带给他最好的帮助，他将为您从未想到的问题找到解决方案。
通常，尝试与人们一起解决问题，而不是强迫他们进入不了解的过程。
#7 楼
可能发生的最坏情况是什么？您是否有足够好的备份，以便可以通过恢复旧版本来修复修改数据库中随机记录的错误？比方说，您在使用记录ID时遇到了一个错误，并且错误地将以美分计的帐单金额存储在用于记录ID的变量中。因此，如果我支付$ 12.34，则ID为1234的记录将被修改。如果该软件运行了几个小时直到检测到该错误，您可以从中恢复吗？ （如果正确的记录和记录1234都进行了更新，则只有在使用记录1234时，您才可以检测到此记录，因此可能在相当长的一段时间内无法检测到）。
现在，请问您的积极进取的开发人员对此有何看法。显然，他不能声称自己从未犯过错误，因为他过去曾经犯过错误。
评论
“您是否有足够好的备份”-即使是这样，您的同事是否想成为由于损坏服务器而必须还原备份的笨蛋？也许他原则上希望在部署之前进行测试，但是由于没有测试环境，因此他选择了目前最简单的选项。然后为测试服务器辩护应该很容易。顺便说一句，“相当长一段时间”未被发现的错误将通过测试进行部署，因为此类错误的问题在于测试的质量，而不是测试的位置。
–史蒂夫·杰索普（Steve Jessop）
2015年7月12日14:09
您不仅拥有备份，而且在还原完成后您的企业还能承受停机时间吗？由于必须执行数据库回滚，它是否会损失几分钟，几小时甚至几天的信息？我会说，在几乎所有不平凡的情况下，答案都是“不”。即使在琐碎的情况下，您也不想“还原备份”成为处理未经测试的代码被检入的方式。必须有一些东西可以确保在检入代码和生产代码之间进行测试。
–aroth
15年7月14日在10:25
完全同意，这就是为什么我说“问您的开发人员他对此有何看法”。他要么完全被迷住了，认为自己的代码没有错误，要么没有意识到可能造成的损害。还是第三种可能性，他知道而且不在乎。
– gnasher729
15年7月14日在10:43
#8 楼
您清楚地了解各种可能的过程和技术解决方案。问题是如何管理同事。这本质上是变更管理工作。
首先，我会与创始人保持沉默，以确保他/她同意你的观点。如果发生生产中断，我希望创始人会对此非常关注，并希望改变。在过程改进中。
设置定期（例如每周）的过程回顾。拥有整个团队：
发现问题
自愿者的想法，以改善工作实践
参与实施这些实践
它应该自然地遵循这样整个团队还可以帮助确保遵守改进的实践。
评论
回顾是解决和希望以建设性方式改变这种行为的好方法！
–greenSocksRock
15年7月13日在21:23
#9 楼
我认为您已经发现了两个问题：听起来像任何有权检查代码的人都可以将任何被检入的代码轻而易举地推到生产中。 />
坦率地说，我认为设置太疯狂了。至少可以将能够手动触发生产的人员限制为可以完全信任的一组人员，以便他们在触发该输入之前彻底检查和测试所有出站更改（无论谁编写了更改）。授予任何允许检入代码的权限的人还可以随意触发投产，只是在制造麻烦。不仅来自粗心和/或不称职的开发人员，而且还来自不满的开发人员或恶意的第三方，这些人恰巧损害了您的一个帐户。
如果您要使用按钮式流程要部署所有已签入的更改，则需要有一套全面的自动化测试套件，并且按下按钮需要运行它们（如果任何测试失败，则中止部署！）。您的流程中不应允许未经表面测试的代码就可以首先将其部署到生产系统中。无需先对其进行测试的代码。您的组织通过采用一种部署过程来犯了一个更大的错误，该部署过程允许未经测试的代码在任何情况下都可以投入生产。
因此，首要任务是修复部署过程。要么限制谁可以触发生产，要么将合理数量的测试纳入您的自动部署过程，或者同时限制两者。开发标准/原则。
特别是，听起来好像您缺少一个明确的“完成的定义”，和/或使用不包含“代码已测试”的代码作为检查代码输入/将代码部署到生产环境的主要因素。如果您有这个建议，您可以说“此代码不符合我们都同意的最低标准，而它需要更好，未来”。
您应该尝试建立一种文化，清晰地传达开发人员的期望以及开发人员要坚持的标准和质量水平。建立完成定义至少包括手动测试（或者最好是可以作为构建/部署过程的一部分运行的自动测试用例）将对此有所帮助。可能会破坏构建。或更严重的后果是破坏生产系统。请注意，这两件事实际上应该是独立的，并且完全不可能同时破坏构建和生产系统（因为破裂的构建永远都不能部署）。
#10 楼
您应该在公司中集成持续集成+同行评审流程。使用Bitbucket可以轻松实现。+1其他用户建议的开发服务器。 br />
评论
评论不作进一步讨论；此对话已移至聊天。由于您使用的是Git，因此在合并到master并部署到生产之前，请使用pull请求来执行代码审查。另外，删除他的凭据以登录到部署服务器。将此权限集中在非开发人员中。 （顺便说一下，信用卡行业强制执行的PCI合规性要求这样做。）
从工作场所的角度来看，如果您是此人的同事，而不是以某种方式与其上司联系，则您不可能通过“惩罚”他们而获得任何吸引力。专注于确保代码质量得到保证，而不是为您同事的宽松标准提供报酬。
推送到“中央”存储库是否总是触发生产部署？绝对不应该。
我读了这个问题，并告诉自己，这个家伙一定是土耳其人，然后您就可以去了:)检查此兄弟：nvie.com/posts/a-successful-git-branching-model。您至少需要有两个分支：master和dev，其中开发人员仅将其推送到dev，并且在测试后将您合并到master和部署。