我的同事在没有测试的情况下进行提交和推送


113

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

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

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

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

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

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


1
评论不作进一步讨论;此对话已转移至聊天
世界工程师

5
由于您使用的是Git,因此在合并到master并部署到生产之前,请使用pull请求来执行代码审查。另外,删除他的凭据以登录到部署服务器。将此权限集中在非开发人员中。(顺便说一下,信用卡行业强制执行的PCI合规性要求这样做。)
Barett

3
从工作场所的角度来看,如果您是此人的同事,而不是以某种方式与其上司联系,则您不可能通过“惩罚”他们而获得任何吸引力。专注于确保代码的质量,而不是为同事的宽松标准提供回报。
Zibbobz

2
推送到“中央”存储库是否总是触发生产部署?绝对不应该。
jpmc26 2015年

3
我读了这个问题,并告诉自己,这个家伙一定是土耳其人,然后您就可以去了:)检查此兄弟:nvie.com/posts/a-successful-git-branching-model。您至少需要有两个分支:master和dev,其中开发人员仅将其推送到dev,并且在测试后将您合并到master和部署。
Cemre

Answers:


92

您需要适当的质量保证(QA)流程。

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

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

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

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


支持进行涉及发布到生产的QA的想法似乎很方便,但由于功能分离的原因而无法实现。在“程序员测试”结束后,负责支持的支持人员应该使他们知道更改。对于四个开发人员,没有其他人,这真的很困难:-)如果您更改了答案,则可以直接应用于OP的设置,那么不会对其他任何人有用...
比尔·伍德格

1
@BillWoodger为什么?对于他们来说,这是一个“即将发生的变化和回滚”系统。它们不仅获得了在“变得真实”之前查看即将发生的事情的好处,而且还可以在情况恶化时轻松地回滚到最新版本。不要忘记暂存环境是程序员的最终测试。
gbjbaanb

1
@gbjbaanb,因为它将支持放在同一位置并重述了原始问题。支持通常可以紧急访问生产。如果他们还有其他访问权限,那么您将遇到审核问题(如果很重要)。如果任何人都可以更改任何内容,那就有问题了。当然,支持人员应该知道一切,他们应该无能为力。这就是我所参与过的每位审计师所说的话,他们很早就说服了我。
比尔·伍德格

@BillWoodger我不确定您在说什么。我知道的生产团队通常都有自己的发布流程,其中包括测试环境(首先要检查傻错误)。在一个小型团队中,没有理由不能由开发人员和支持人员共享此测试系统。无论如何,都不允许对其进行任何更改-它是由开发人员通过自动化填充的,并由支持部门使用的。给他们一个相同代码的邮政编码没有什么不同。审核员关注的是流程,而不是流程的执行(当然要遵循这些流程)
gbjbaanb

1
@gbjbaanb审核员关心有权使用所有内容的人员。如果支持人员可以在开发过程中更改程序并将其投入生产,而无需任何其他人的干预,则该系统将被公开。当然,由OP的四个人组成,没有单独的“支持”,而令人满意的功能划分将非常棘手。
比尔·伍德格

54

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

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

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

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

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

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

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

因此,从对话开始。

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

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


10
为对话+1。必须达成共识,这是一个问题以及为什么是一个问题。只有这样,技术解决方案才能成功。
Patrick

9
+1用于获取开发服务器/暂存环境。除非在自己的机器外面有一个真正的地方来推动事情,否则这种行为并不完全是同事的错。一个人只能在自己的机器上做很多事情,如果没有其他事情,额外的环境通常可以帮助改变测试的思维过程/态度。
Joel

20

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

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

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


17

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

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

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

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

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


1
我真的不清楚SVN的思维方式是“提交/推送,立即部署到生产环境并在那里进行测试,并且没有其他地方”是SVN的心态。即使使用单个分支模型或源代码控制,提交也不一定意味着生产部署。或至少不应该如此。
jpmc26 2015年

@ jpmc26:冒着Git / SVN火焰之战的危险:我们为许多“旧版”代码继承了SVN系统,但一直在使用Git进行较新的工作。我几乎可以保证我们没有正确设置SVN和/或没有正确使用SVN,但是Git处理分支感觉更容易使用。我100%确信SVN能够处理正确的部署,但我还可以(从我不完善的经验中)了解SVN如何“阻止您做正确的事”。无论如何,这仅仅是一个贡献因素,对用户的教育更为重要。
TripeHound

1
@TripeHound没有关于git系统总体上可以更好地管理代码更改的论据。(我对git的异议通常与较高的学习曲线有关。)我的观点是,尽管git可能具有帮助管理发布过程的更多功能,但建立构建基础结构的方式仍然是影响您的主要因素源控制的选择。我在SVN中进行了相当成功的构建和发布自动化,已经有一段时间了,所以我还不清楚“ SVN思维方式”是什么,或者它对发布的负面影响。
jpmc26

2
仅仅因为您致力于掌握并不意味着您应该部署到生产环境。即使您的原始回购/ svn回购托管在产品服务器上,也并不暗示这种情况。
vonPetrushev

12

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

中断构建,加入甜甜圈。

1)每周吃两次甜甜圈,或2)遵守标准。

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

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


2
这仅适用于办公室。当您有一个分散的远程开发人员团队,而这些人员都在家工作时,这是什么等效概念?
aroth

2
@aroth对于某些团队来说,从破坏构建的人那里获得一封简单的团队范围的电子邮件就足够了。将其计划为“持续改进过程的目标”,并要求电子邮件包含足够的信息,以便其他人可以查看出现了什么问题,为什么出错了以及该人将对其过程进行哪些更改,或者他们建议团队进行哪些更改这个过程,以防止它再次发生。大多数人都讨厌报告和报告,这又使他们很烦恼,他们将来可能会更加小心,不要破坏版本。
亚当·戴维斯

8

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

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

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

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

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

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


6

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

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

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


“您是否有足够好的备份”-即使是这样,您的同事是否想成为由于损坏服务器而必须还原备份的笨蛋?也许他会喜欢在原则上部署前进行测试,但因为没有测试环境,他采取最简单的当前可用的选项。然后为测试服务器辩护应该很容易。顺便说一句,“相当长一段时间”未被发现的错误将通过测试进入部署阶段,因为此类错误的问题在于测试的质量,而不是测试的位置。
史蒂夫·杰索普

您不仅拥有备份,而且在还原完成后您的企业还能承受停机时间吗?由于必须执行数据库回滚,它是否会损失几分钟,几小时甚至几天的信息?我会说,在几乎所有不平凡的情况下,答案都是肯定的“不”。即使在琐碎的情况下,您也不希望“还原备份”成为您处理未经测试的代码被检入的方式。必须有一些东西可以确保在检入代码和将其交付生产之间进行测试。
aroth

完全同意,这就是为什么我说“问您的开发人员他对此有何看法”。他要么完全被迷住了,认为自己的代码没有错误,要么没有意识到自己可能造成的损害。还是第三种可能性,他知道而且不在乎。
gnasher729

3

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

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

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

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

设置定期(例如每周)的过程回顾。拥有整个团队:

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

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


回顾是解决和希望以建设性方式改变这种行为的好方法!
greenSocksRock 2015年

1

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

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

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

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

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

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

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

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

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


0

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.