为什么大型金融/保险公司应使用git和/或github


12

我为金融/保险行业的一家大型企业(雇员3万)工作。虽然“ IT”不是我们的主要重点,但老实说,这些都是信息驱动的行业,具有更好技术优势的公司似乎能更快地取得发展。

我公司有很多软件开发团队。它们遍布整个版本,具有版本控制功能,更不用说使用的语言/框架了。有些人不使用任何(我知道),一些人使用PVCS,一些人使用VSS,最开明的人使用SVN。

我想将git带入我的企业。更具体地说,我想引入GitHub(私有存储库)。我知道合适的人可以谈论这个话题,但老实说,由于诸如安全隐患或我们的竞争对手都没有使用它这样的大举动作,通常在大型企业环境中会被击落。仅引用jQuery,Ruby on Rails,Facebook等作为参考)。

所以我的问题是这个。大型企业为何应缓慢而有意识地从PVCS / VSS / SVN切换到托管git解决方案(如GitHub,私有仓库)的最令人信服的原因是什么。当然,我的计划的一部分涉及到一个不必要的开发项目的POC。


2
我正处于同一过程中(大型金融公司,有10万名员工...):请参见stackoverflow.com/questions/3597747/…–
VonC

3
您可以从拥有内部git存储库开始。您可能会说说git不错,但是永远不会允许将代码放到外部。

@VonC:谢谢其他问题。其他人:感谢您迄今为止提供的所有出色答案。不过,我还是要坚持这个问题,尤其是在GitHub上,因为我认为这是一个很棒的UI,并且可以消除git的某些“技术
难题

4
GitHub现在提供了GitHub Enterprise,它允许您将GitHub托管在您的专用网络上,但要准备投入一些精力。
M. Dudley

Answers:


25

作为无私的第三方,我可能会担心一些事情。因此,让我向您提出一些问题,您最好准备向您的IT部门回答:

  • 任何版本控制总比没有好。我们有很多选择,这些有什么问题?
  • 分布式版本控制?那是什么?我们如何控制呢?
  • 费用是多少?不只是软件,还有服务器,许可证,维护等。
  • 我不信任GitHub或任何外包托管。我们需要内部做所有事情。为什么我们不能设置自己的服务器?
  • 我们可以在Windows上运行它吗?您必须知道,我们必须将其保持在当前基准之上。
  • 我们如何固定东西?我们得到了SVN,但这吓到我了。

这些是首先要提出的问题。至于VSS和PVCS,您可能会提出很多合理的参数(例如VSS破坏版本历史)。SVN将更加困难。我强烈建议重点关注GIT的合并功能,也建议对Mercurial保持开放的态度。GIT的每个论点也都是Mercurial的论点-而且Mercurial具有更成熟的Windows支持。

安全对金融和政府机构至关重要。 他们将极力抵抗外部托管的资源。从风险管理的角度,考虑如果有人入侵GitHub并偷走了源代码,或者发现了问题跟踪器中记录的安全漏洞,将会发生什么。那对公司将是毁灭性的。从纯粹的管理角度来看,如果公司合法需要支付您工作的每一小时的费用,当资源不在其VPN网络外部时,他们如何监视您是否在家工作?另一方面,当所有资源都可以从公司外部获得时,它们如何防止您进行某些公司的间谍活动?这些是IT和管理部门反对将托管外包的理由。一家大公司必须以这种方式看待事情。对于一家小公司,您要看底线以及将所有这些服务放在适当位置要花费多少。

对于大公司来说,在内部进行安装实际上更便宜。 他们已经拥有IT资源,只需要稍微改掉责任即可。而且,如果该解决方案在很大程度上仅需要定期维护(备份和用户管理)就可以自行解决,那么更有理由将其保留在公司内部。

对于Windows托管,这是一个逐个组织的问题。几家公司吞下了Windows koolaid。其他人吞下了Linux koolaid。其他人则逐案考虑。您必须遵循IT部门为您的组织设置的规则。只要您的解决方案可以托管在任一托管解决方案上,您就很聪明。

最终,在如此庞大的组织中,肯定会有所有人都想以自己的方式做事。 他们都有令人信服的论据,为什么选择VSS,PVCS,SVN或您选择了什么。对于IT来说,它们都是一样的。在规模如此之大的组织中进行整合的唯一方法是让命令由上而下命令。这样的订单总是会遇到阻力,除非您拥有标准化的版本控制系统具有明显的总拥有成本(TCO)好处,否则您的公司可能不想这样做。


1
+1:即使此处提出的论点无效,我也会对其进行+1,以创造性地使用“ fief”一词。
乔尔·埃瑟顿

1
我只是想介绍大公司看待事物的方式。没有人假装它们都是有效的,但是您必须为它们提供答案。
Berin Loritsch 2011年

1
我对以上几点都没有异议。它们可能并非对每个组织都有效,但对许多组织都有效。
乔尔·埃瑟顿

1
在过去5年中,随着时代的变化,您可以在内部托管BitBucket或其他一些变体。为了进一步解决问题,Microsoft Team Foundation Server似乎在其核心上使用了GIT,而Visual Studio现在已经内置了对GIT的支持。现在,对GIT的争论比以前更加强大。在所有工具供应商集成方面,GIT似乎也超过了Mercurial。好消息是,所有这些都可以与公司基础架构集成(例如使用ActiveDirectory或公司LDAP进行身份验证)
Berin Loritsch 2016年

GitHub不再需要外部托管。
UpAndAdam

8

我也曾在一家金融/保险企业工作(尽管没有您目前所从事的公司那么大)。我们也有多个开发团队,尽管企业选择了专门的Microsoft产品进行开发,但仍然没有主体系结构,语言或源代码控制。我们都使用.Net,但我们有多个项目使用不同版本的框架和不同的语言。一些项目使用VSS,而其他项目则使用TFS。现在,我们有一个新的更高级别的架构师作为质量检查经理,他率先进行了更多的企业过渡,从我们的杂物箱缺陷跟踪,源代码控制,框架使用到所有这些的更通用的TFS实现。只有通过以下事实,他才能做到这一点:a)对软件的性质非常有经验,

在您自己的组织中解决此问题时,您必须首先考虑一些事项:

  1. 为什么您如此迷恋GitHub?您是在寻找通用的源代码控制,还是在寻找实现自己喜欢的东西的理由?我不知道答案(坦率地说,不在乎),但是当您开始关注别人的业务时,这个问题就会出现。
  2. 您目前隶属于其中一个软件团队吗?如果是,您可能需要找到一个独立的,定位良好的个人来拥护这个概念。否则,其他开发团队可能只会觉得您正在尝试将自己的想法打上烙印。这将使他们对概念更加抵触,因为他们已经有了可行的东西(他们认为)。
  3. 您是否已与其他团队的成员进行了任何外联活动以赢得对该概念的认可?其他开发人员是否有类似的意见或担忧?实现它的另一种途径是在执行工作的人员中建立批判性的关注对象。随着越来越多的人开始要求使用通用源存储库,管理层将不得不引起注意。
  4. 您是否足够熟悉其他团队的代码/流程/要求,以至于GitHub会(或不会)为他们工作?

至于您的最后一个(或实际的)问题,从业务经理的角度来看,从长远来看,唯一真正令人信服的原因是它可以省钱。这些节省的形式可以是减少停机时间,提高代码安全性,提高开发人员生产率,增加代码库冗余(用于备份)等。您最终需要做的就是说服为所有这些编写支票的个人,他们认为,过渡到这种模型所花费的时间,精力和金钱最终将很值得,作为他们的投资回报。您还需要证明,当“缓慢而有意地”最终发生时,将对该模型提供将来的支持。

这种对企业的更改涉及很多方面,因此需要大量基层风格的热情,并且您肯定需要VP级别的人来支持该概念。经理可能会工作,但高管将拥有更多权力将概念压印在其他群体上。


4

这样的公司将希望将其存储库集中化。SVN,VSS和PVC广告有一个共同点-它们都是客户端-服务器体系结构。Git被设计为分布式VCS,并且本质上是分散的。

GitHub-更麻烦 这是一项外部服务。外部服务中的源代码是管理层很可能永远不会接受的东西。

但是,存在可以使双方满意的解决方案。Git有git-svn命令。基本上,您将拥有SVN存储库,但是一些开发人员可能选择拥有自己的本地GIT存储库,并将其与集中式SVN存储库同步。替代私人分支机构或发送未提交的补丁程序的好选择。好如何做的混帐SVN集成


同意集中式存储库首选项。关于Git-SVN互操作:GitHub现在提供对Git存储库的SVN访问;公司托管的存储库可能会受益于SubGit之类的工具。
vadishev

github不必是外部的
UpAndAdam

1

由于有关GitHub和安全性的评论自发布以来,其中的一些答案已大大过时。

  • GitHub 不会强迫您被外部托管
  • GitHub 的免费版本是实施此限制的原因。
  • 有一个GitHub企业版可用于内部托管https://enterprise.github.com/home。它不是免费的,当然要花费$

我工作的公司刚开始使用它,由于我们的代码是商业秘密,我们在金融部门,因此我们也有同样的担忧。除此之外,还有其他不涉及GitHub,redmine,gitosis等的使用GIT的方式...

关于“谁在使用它”的问题:PayPal,Etsy,rackspace,vimeo,SAP,NASA的JPL,Linux内核

令人信服的技术原因不胜枚举。唯一值得关注的是其他答案指出的高层较大的企业问题。我能想到的最大的一件事就是一致性,统一性,清晰的审核,审核的简便性。尽管使用其他许多VCS系统解决问题的宝库是很大的。

减少了所有必须编写不同古怪的脚本以在不同系统之间进行集成,对其进行审核,对其进行报告和控制的部门的重复工作。

  • 每当我不得不在像贸易公司这样的偏执环境中使用SVN时,荒谬的“合规性”和“安全性”钩子都会对性能造成极大的损害。

由于我从开发人员的角度掩盖了技术使用问题,因此我会这样说。在15年以上的总使用时间中,我在专业环境中与GIT一起使用了CVS,SVN,CMVC,clearcase,perforce和其他系统。如果有人要我使用除GIT之外的其他东西(可能除了bzr,mercurial,perforce和clearcase(取决于后两个的设置)),我会立即知道我的时间最好花在其他地方。 早在2009年,我就快要得出这个结论了(尽管对CVS和SVN给予了些许津贴)。我对在工作场所使用SVN的短暂经历感到非常厌倦,于是在2010年初开始使用GIT作为SVN客户帮助说服我们改用GIT。

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.