量化现代版本控制系统的优势[关闭]

在过去的三年中，我一直在大型金融企业环境中担任团队负责人/开发人员。我们的产品发布过程是一场噩梦，因为它围绕Clearcase展开。我们有一个变更管理小组，负责执行所有版本，并且只允许将代码从生产中带入生产。

加入时，我要做的第一件事就是与Git建立团队。每个人都同意，Clearcase太糟糕了，对于处理日常源代码控制事务不切实际。因此，我们在本地计算机上建立了一种“非官方”存储库，并编写了一个脚本以在发布时同步git和Clearcase存储库。

这句话传给其他团队，有几个团队采用了相同的过程。以“非官方”方式使用git进行日常活动，以“官方”方式使用Clearcase进行发布。对于Git的任何问题，我都非常喜欢。

因此，本周我将与基础架构变更高级副总裁开会，他特别希望我向她解释Git的优点。显然，我在Clearcase上听到了我的常识。如果她接受我的论点，我将真正帮助我的雇主摆脱这种可憎的事情。

我与高管的经验告诉我，他们a）想要对所有事物进行极为简洁的解释b）只对涉及美元数据的事实感兴趣

我可以向开发人员解释Git优于Clearcase的优点（或针对此问题的Clearcase的任何其他版本控制系统），但是我正在向没有技术背景的技术主管说明如何做到这一点（她有一个工商管理硕士（MBA），并取得地理学本科学位。

我觉得我对她的任何争论要么听起来像是胡言乱语，要么是我在宣扬自己的个人喜好。

我要查找的是具体事实，这些事实表明开发人员可以更有效地使用Git或任何现代源代码控制系统。

我认为其他团队已经开始在内部使用Git是一个有意义的信号，但是它仍然不够强大，因为它仍然可以作为个人喜好而忽略。

我真正需要的是一个足以突破“这个过程已经工作了20年，为什么我们要改变它呢？”的功能。论点。

我曾经遇到过非常相似的情况（在航空航天和汽车行业）。不要期望在本次会议或以后的会议中取得很大进展。这两种情况都超出了我继续争取进步的愿望，但这是我迄今为止看到的最好的策略。

您说“这个过程已经工作了20年”，但是真的吗？首先概述您的意思是“我们的产品发布过程是一场噩梦”。使用当前进程/工具创建一个问题列表，该列表尽可能与ClearCase无关。

然后，创建尽可能不了解Git的流程/工具“解决方案”列表（尽管Git或任何现代DVCS都希望完全符合要求）。向非用户解释为什么Git比ClearCase更好。

允许基础架构团队确认当前方法是否存在您确定的问题。这可能会导致他们寻求IBM的支持以“解决”这些问题。保持连接状态，以确保IBM不会回避问题。由于ClearCase缺乏我们对版本控制的现代理解的基本属性，因此大多数这些问题无法解决，或者将需要对基础架构进行重大更改。

希望到此为止，基础架构团队将这视为一个业务问题，但没有一个简单的解决方案。此时，您可以用估计的成本来对其他解决方案进行基准测试。由于您的许多团队已经在使用Git，因此您应该可以取消培训，而这是一笔费用。

祝好运！

我们的产品发布过程是一场噩梦，因为它围绕Clearcase展开。我们有一个变更管理小组，负责执行所有版本，并且只允许将代码从生产中带入生产。

不，由于您的变更管理小组和发布过程，您的过程是一场“噩梦”。继续，将Clearcase替换为SVN或git或Fossil。您将遇到完全相同的问题。（我认为他们在TBH上做的不错，强大的发布控制至关重要）。

这是您需要重点关注的内容，而不是git的怪异凭据（除开发人员外，其他都不相关），您需要关注业务案例以更改流程以减少繁琐的工作。您可以使用Clearcase做到这一点，但是它给了您一个偷偷摸摸地使用git的想法的机会。

如果您不看这里的“大图”，最好的情况是使用git并具有与发行组相同的限制。如果您确实考虑了变更控制的广泛用途，那么您将意识到为使git在组织所需的高度受控的发布过程中有用而必须实现的限制。

为您提供一些建议：让他们从开发人员的角度看当前系统的生产力问题。在2的第1部分中执行此操作。在第2部分中，继续使用它们，以便您可以查看开发人员需要了解的控制问题。将其作为双方都可以查看对方观点的学习练习，然后您应该能够更好地提出一种解决方案，该解决方案仍然可以解决双方的主要要求。请注意，发布比开发更重要，因此，您应该准备比您期望的更多。

一旦了解了发行所需要的内容，就应该同意编写一份详细的过程文档（包括遵循步骤的详细信息），以便向他们展示所需的信息。如何进行按摩，使开发方对您更好，取决于您自己。我想他们只要在适当地管理源代码并正确组织发布的情况下，都不在乎开发人员如何进行开发-这意味着您必须展示如何将代码更改与更改票证联系在一起，如何获取生成的代码发布补丁，构建并重新发布。

具体的例子比抽象的优点更令人印象深刻。我认为，如果您可以记录以下特定示例，则将获得最大的成功：（a）Clearcase引起的问题需要花费时间来解决，并且（b）Git解决了这些问题。请记住，您无需深入了解为何如此（除非询问）的技术细节，只需说明事实即可。管理层不需要了解技术细节，这就是您的报酬。

如果您可以在这些示例中附加特定的时标和日期，那就更好了。您可能还可以通过显示您完成的任务X在Clearcase中花费Y分钟，在Git中花费Z分钟来结束这项工作。

请记住，时间就是金钱，因此，如果您可以证明与Git的合作更快，那么您可以证明这也具有财务意义。

这是我如何尝试的尝试。

对于开发人员来说，这听起来很愚蠢，但是对于管理人员来说，技术变革被视为冒险。

“如果魔术东西已经起作用了，为什么要冒险打破它呢？”

因此，您必须翻转桌子。加大风险，不要切换到git。不惜一切代价，不要让它听起来像是一个新玩具。

我首先要说git现在已被广泛使用。使用数字，例如：http : //ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

对于经理来说，这意味着他们应该能够使用git找到很多开发人员。还有一个完整的第三方工具生态系统（我听说微软现在也将git与Visual Studio集成在一起）。

另外，不能因为跟随主流事情而责怪经理，不是吗？相反，谁在这里使用$ other_cvs？

强调使用它的大型项目，因为它简单，快速，灵活，强大...查找使用git附加名称的大型项目（GNU / Linux，Google，Microsoft ...）。

在证明这不是一个不好的举动之后，您可以继续研究如何改善您的情况。

您希望公司保持竞争力，而不是被更快，更敏捷的团队所超越，对吗？我将尝试找到一些内部（书面）评估，以通过使用Clearcase vs Git来改变生产力。您可以从那里的其他开发人员那里获得一些帮助。然后为整个公司（即所有软件开发人员）推断出使用Clearcase的人数和估计费用。

会议结束后，即使有适当的话，我也会用书面电子邮件回顾整个过程（包括合适的人员）。

我真正需要的是一个足以突破“这个过程已经工作了20年，为什么我们要改变它呢？”的功能。论点。

这是一个无效的论点（马车已经“工作了几个世纪”，但您可能想购买一辆汽车）。

我曾听到过关于svn vs.Mercurial的相同论点（我是在开发系统上使用Mercural的人）。

这个问题不是要替代有效的方法。不要试图这样说，如果这是您需要“击败”的问题，则应首先指出，这与有效与否无关，而与git的优势有关，什么时候都能工作（以及git为什么更好地工作）。

使用git的好参数：

• git是以变更集为中心，而不是以文件为中心。这意味着更改更容易跟踪跨文件（跨项目的可跟踪性）。

• git是分布式的，而不是集中式的；这意味着签入内容不受网络速度的限制-再次节省了很多时间。这也意味着万一您的ClearCase服务器出现故障，您就不会出现单点故障。

• 由于它是分支系统，因此git最大限度地减少了合并的需要（即，您不会在每次签入时都合并文件，而是在每个已完成的功能上都合并文件）。您从每天几次（每次提交）解决合并冲突（如果有）到每周一次（两次完成的功能）一次或两次。这意味着您的开发人员将有更多的开发时间（某些管理人员希望最大化）。

我认为其他团队已经开始在内部使用Git是一个有意义的信号，但是它仍然不够强大，因为它仍然可以作为个人喜好而忽略。

您可以指出，质量上的差异是如此之大，以至于整个公司的开发人员都喜欢在Clearcase之上安装，配置和使用git的复杂性，因为它具有额外的功能。实际上，这是一个有力的论据（如果它不能提供更好的用户体验和功能集，那么人们就不会花更多的力气去使用它-尤其是因为这不是公司所必需的）。

因此，本周我将与基础架构变更高级副总裁开会，他特别希望我向她解释Git的优点。

绘制一个图表，表示使用这两个系统的提交，并显示开发人员未公开进行提交所获得的精简效果（即，如果您伪造文件，则团队的其余成员将不会受到阻塞并且无法解决，直到您对其进行修复为止）。还要说明在进行中间提交而不影响其他任何人时可以进行的额外质量控制，事实是每个功能都可以获得干净的差异（对于代码审阅是必不可少的）。

我真正需要的是一个足以突破“这个过程已经工作了20年，为什么我们要改变它呢？”的功能。论点。

如果没有现场见证，很难真正判断出什么是好的论点。但我会尽力帮助您提出自己的观点，以便可以听到。

我假设您的听众对这个主题没有专业知识，并且对保持当前的课程感兴趣。他们有不同的关注点和责任，如果出现问题，他们可能会遭受严重的后果，因此您必须以这种思维方式工作。预计他们可能会遇到的一些问题或担忧：

• 这将带来什么新功能？ 是否有我们目前无法做的事情，我们想做的事情以及新事物可以允许我们做的事情？从正面开始。

• 对发布时间表有什么影响？ 对即将发布的下一个版本实施此更改的成本是多少？后续版本的成本和收益是什么？

• 这会改变流程吗？ 与发布时间表不同，此更改是否需要发布过程中的人员改变其方式？这对他们是透明的，还是他们需要适应？您需要与其他部门合作吗？人们抵制变化。

• 坚持使用当前系统是否存在迫在眉睫的危险？ 当前的流程中是否已经存在软件或硬件依赖性，或者寿命即将终止？它是否依赖于个人的专业知识，从而增加了招聘成本？新系统是否存在潜在的安全漏洞（如果此漏洞可能导致法律诉讼，请加分）？不要动摇，“也许”或“可能”这样：感觉它在20年中运作良好，因此举证责任在于变革的倡导者。

另外，请具体说明问题和解决方案。如果找不到具体示例，请使用您作为专家的诚实估计。采取这种更改的其他公司/部门/实体的示例（最好是来自您所在行业的示例）及其对这种更改的评估将为您提供帮助。（不要选择近年来发生过一些公开的IT问题的示例，否则您将有责任证明这种变化不是原因。）

您可能会找到此答案，以说服我为实施版本控制而工作的公司？有帮助的。