我怎样才能说服我的部门实施版本控制系统?

时间:2009-07-14 09:28:10

标签: version-control

我最近加入了一家大型保险公司的IT部门。虽然该部门的标题是“IT”,但很多代码都写在这里; Java,JSP,JavaScript,COBOL甚至是我听过的一些C ++。所有允许保险公司,经纪人和其他领带白领工人签发新合同并与客户打交道的计划都依据该部门制作的代码。我被告知,根据母公司的标准,该部门相当不错,我们甚至还获得了一两个内部奖励。我们这个部门有17个人,分成2个或3个小组。正如你可能从COBOL部分进一步猜测的那样,平均年龄超过40岁(作为参考点,我是29岁)

目前,还没有版本控制系统(虽然存在一般的备份方案)。需要时,文件将通过共享文件夹传递。通常每个组中都有一个人负责将文件的“最终”版本复制回生产服务器。我觉得这很荒谬甚至有点危险。

我怎样才能说服管理层我们应该在我们的部门实施VCS计划?我自己从未部署过VCS,但我工作的其他地方都有一个。我想我会说“到目前为止我们一直很好,为什么还要打扰”第一步的墙,再加上大多数同事的年龄,我觉得这一步是不必要的障碍。

我知道VCS的基本优势(可追溯性,粒度备份,问责制等)。我希望通过实际案例和实际成本实际附加价值的例子支持我的案例,不仅仅是“但是 - 但是,我们必须有一个你傻瓜的VCS!” : - )

12 个答案:

答案 0 :(得分:28)

您不一定需要他们的许可。

在您的计算机上安装svn,开始使用它,然后开始说服您的团队成员也使用它。

然后观察并看看会发生什么。

编辑

  • 这个的基本思想是,它比表示更容易展示。
  • 通过可行的实施/解决方案来支持您的想法是一个好主意。
  • 当然,如果您成功,并且他们希望系统使用部门/公司范围,您必须准备好支持转换,了解软件的安装和使用方式。
  • 继续使用行业中接受的东西比讨论应该使用什么系统更快。
  • 这会让你注意到一个很好的变化。您也可以得到同行的尊重和支持。

正如所建议的那样,可以在其他方面采用相同的方法:

..任何可明显增加工作质量的项目,但不会(但)破坏现有的方法和实践。

答案 1 :(得分:12)

Joel Spolsky有一篇很好的文章:Getting Things Done When You're Only a Grunt

引用

  

您团队中没有人想要使用   源控制?创建自己的CVS   存储库,在你自己的硬盘驱动器上   必要。即使没有合作,   你可以查看你的代码   独立于其他人的。   然后当他们遇到问题时   源控制可以解决(某人   不小心输入rm *〜而不是   rm *〜),他们会来找你帮忙。   最终,人们会意识到这一点   他们可以有自己的结账,   太

答案 2 :(得分:7)

管理?我会大胆地使用你应该使用的表达和词语:

如果发生某些错误/错误或灾难,您应该展示VCS如何防止赔钱给公司的​​一些示例。解决所有问题会更快,因此保持系统不会那么懒惰,人们变得更高效

您还应该提到实施VCS 无成本

VCS还可以为备份所有现有代码提供优势。因此,所有代码都是安全

答案 3 :(得分:3)

我对如何做到这一点的看法是,你应该首先说服你的开发人员。我看待它的方式,有两种可能的方式:

  1. 你给其他开发者提供正确的论据(可能只有主管开发人员就足够了),他们喜欢这个想法,并建议管理层。管理很容易说服,所以每个人都很高兴。

  2. 你给管理层提供了正确的论据,他们都很兴奋(太棒了!)并且要求每个人都必须安装和使用版本控制。事情就是这样:如果此时其他开发人员已经没有出售这个想法,那么(a)他们可能对管理层强迫他们的想法持怀疑态度,并且(b)他们可能不喜欢你因为这个原因这一切。

  3. 那么说服其他开发者的好理由是什么?作为使用颠覆的人(顺便说一句,这是我在这种情况下推荐的那个),即使对于他的个人项目,这里有一些我能想到的优点:

    1. 使用版本控制迫使人们根据一系列小的,自包含的更改来考虑代码修改。这是一种非常有益的工作方式:否则人们会倾向于在整个地方进行大量更改,使代码陷入混乱,版本控制有点迫使他们以一口大小改变代码,易于使用吞下比特,始终保持代码编译,降低与其他模块集成的成本等。

    2. 版本控制使得每次代码中的更改变得非常容易。这可能听起来微不足道,但是当你开始修改代码时,很快就会失去跟踪。但是对于VC来说,它总是一个“svn diff”(或等价物)。

    3. 版本控制可让您轻松查看每次都更改了代码。因此,例如,当某些事情发生时,你就会知道应该责怪谁。 (显示谁最后改变每一行的subversion命令被称为“svn blame”并不是偶然的。)

    4. 版本控制可以很容易地看到为什么更改了一段代码。如果使用得当,提交消息基本上可以持续记录正在进行的开发过程。 否则将无法编写的文档

    5. 版本控制可以很容易地追踪回归并查看它们的出现位置。在简单的情况下,您只需跟踪提交消息并发现罪魁祸首。在一般情况下,你也必须参考差异。在困难的情况下,你必须使用相当于二进制搜索的方式对以前的版本进行回归测试,这仍然比没有VC的情况更好,在那里你根本就没有线索。

    6. 当然,这份清单并非详尽无遗,但这些是我们现在想到的主要好处。显然,正如其他人已经提到的那样,向同事展示这一切比向他们描述它更容易,并且首先为自己设置它(但是导入每个人的代码,头脑)听起来很棒想法。

答案 4 :(得分:2)

正如Joel在他的一篇文章中所指出的那样,开始使用你自己的单人版本控制系统,并在你获得的每一个机会上推广它的好处。向您展示单个实例的可追溯性,粒度备份等的好处。无论年龄大小,人们都会开始意识到它的好处。

答案 5 :(得分:2)

我同意那些指Joel Guerrilla文章的答案。

  1. 以低开销安装/使用某些东西。 Hg(Mercurial)在混合环境中很容易,因为你可以轻松地拯救并使用其他东西。
  2. 你必须分享你的东西,而不是弄乱它。当有人需要您的代码时,将其导出并使用“标准”公司方法(共享文件夹或其他)
  3. 当你获得代码时,总是把它导入到一个仓库中,如果你认为它是你已经拥有的一个仓库的新提交,试着把它放进那个。
  4. 迟早你会有几个项目的代码,希望有些回购。然后你可以使用mercurials webserver接口公开它们(hg serve -p XXXX)。
  5. 当时代到来的时候,有人不知道为什么突然之间不能正常工作,并试图找出为什么因为它在上周一工作...而且你知道你有一个代码在一个repos升级并询问您是否可以提供任何帮助。获取falty代码,将其提交到您的repos并使用hg serve进行公开。在浏览器中查看它。
  6. 我的观点是,你必须向你的大学证明这些东西有价值。 如果多年后你没有自己想出来的话,那么你可以攀登一座山,但它可以完成。你必须耐心等待。转换一个人(老狗)可能需要一年的时间。如果你有任何年轻的同事尝试一起做这个,你可以获得的代码越多越好。

答案 6 :(得分:1)

我会指出没有丢失代码的危险,开发人员互相编写更改,回滚问题的能力等等。

此外,由于Subversion和其他一些人都是免费的,因此指出购买没有实际成本,这就是实施的时间。

作为新人,你将遇到的最大问题是你将被视为摇摇欲坠的船,如果他们迄今没有任何问题,他们将难以说服。也许开始在本地jsut使用它,也许他们会喜欢他们所看到的并开始采用它。

我会尝试一些小步骤,也许会问其他人是否曾经使用过一个,指出好处,当出现一个系统会阻止或帮助指出它的问题时。

答案 7 :(得分:1)

从纯粹的业务角度来看,根据您母公司的规模和性质,IT审核员可能会认为您缺少VCS 发现(即需要修复的东西)。我相信你可以通过告诉他们任何CVS是一种很好的方式来表明你的部门尊重其资源并以结构化的方式和有效的方式工作,这是审计师总是喜欢看到的。

我不知道你的企业文化是如何运作的,但是我要小心推出你自己的CVS,因为如果确实看到了它,那么即使你没有错,它也会在出现问题时突然变成你的责任。为了掩盖你的屁股(并让上述审计员更加满意),我将推出一套完整的书面程序,以便使用和维护。

最后,虽然我自己是企业任何级别的主动粉丝,但不要指望人们在弄清楚它有多棒时会记得说声谢谢。有些可能,但在大多数情况下,你这样做是为了让自己的生活更轻松,也为了自己的业力。

答案 8 :(得分:0)

请记住,有很多版本控制系统是完全免费的。安装和维护版本控制系统所花费的时间应该接近0(它们不需要任何维护)。大多数系统甚至没有空间损失,因为它们可以在内部压缩内容。

您列出了一些优势,还有其他优势。但更重要的是,我无法想到一个单一的劣势。

答案 9 :(得分:0)

我还建议首先为自己实施VCS(版本控制系统)。我建议使用分布式VCS (Git,Mercurial,Bazaar)而不是集中式Subversion,因为通过克隆创建中央存储库(或存储库)比将Subversion存储库移动到中央更容易地点。分布式SCM也可以在较小的组中用于交换想法。

(现代)版本控制系统的一些优点:

  • 您可以随时恢复(返回)代码的最后一个工作版本(前提是您遵循一些理智的版本控制约定,例如至少只标记经过测试的代码)。通过文件夹共享代码,可能会发现没有一个版本可以正常工作,备份副本被删除以节省空间,从备份中恢复代码很繁琐/从未测试过。

  • 由于分支(以及存储/搁置未提交的工作)。

  • 如果您遵循版本控制的良好实践(小而且经常提交,更改是关于一件事,编写描述更改和改变的好的提交消息),您将有更多,更容易发现错误,无论如何通过平分历史记录来查找引入错误的更改,或者使用版​​本控制系统查找谁负责给定的代码区域(注释/责备)。

答案 10 :(得分:0)

开始与其他开发人员讨论过去曾经遇到的问题,以此来了解系统及其演变方式(偷偷摸摸,鬼鬼祟祟,偷偷摸摸,但嘿,这些信息可能会在某些问题上派上用场除版本控制问题外)。你迟早会发现一些已经发生的事情的精彩例子,如果你有版本控制,那就不那么痛苦了。当您将想法提交给管理层时,请使用这些示例。

我同意你可以开始使用你自己的版本控制并且最终能够帮助解决问题的想法,但我敢打赌他们已经在其中的一些修复程序中获得了金钱,如果他们已经记住之前的问题是多么痛苦,它将有助于推销新想法。

答案 11 :(得分:-1)

寻找另一份工作。

严重。

那里有更好的工作,不需要你教授现有员工 在那里你可以开始工作,只是,你知道,工作

另外,请记住30不远。那是大多数人的年龄  快乐地停止傻瓜。

只是抬头。

修改

有人建议辞职是为了戒烟。

也许是这样,如果你愿意,可以投票,但请记住,你应该这样做 在你接受工作之前,让你的雇主参加乔尔测试,而不是之后。