当年轻人遇到传统商业时会发生什么

        1 Dec 2015 at 15:31, Adrian Bridgwater

         谁会在意？DevOps可以修复它,不是么？

         你可能想知道，为什么这是重要的呢？

        我们生活在一个存在DevOps的世界，即使我们结束了大型二进制资产存储库或分给多个外部存储库，我们也可以在构建,测试及以后版本时，通过DevOps合并和统一这些元素。分布式版本控制系统的对手们会质疑这对一些大问题而言只是一个创口贴并且，把所有资产存储在一个数据库会是个更明智的做法。

         的确，这所谓的单一资料来源在CAPS A敏捷开发中受到欢迎及拥护。但一个很简单的问题是在一个单一的位置，在这个世界上，多地点，多手段，多学科的团队合作，与软件资产的多种软件应用需求的多样性。

        事实是(不要太大声喊出来), 为了测试和部署，源代码通常是比文件,图片、模型、音频、视频、甚至整个虚拟机(VM)环境都小的二进制点。

        这种资产的扩张给企业采用Git带来了很大的挑战，因为它内部档案系统的设计授权了一个最大1或2GB的实际数据库大小。甚至远低于实际限制的数据库可以表现出相对差的性能,这都依靠于资产和操作的类型和大小。

        现实世界解决方案的选择

        根据Mark Warren，Perforce的产品市场总监所言，这里的选项包括例如‘narrow cloning’这样的路径——它是一种尽管高度可取但是现在无法实现的方法。开发人员只想采用他们需要的bits，而不是被所有时间的所有代码困扰（例如一个iOS客户端开发人员可能并不在乎Windows Phone客户端做什么）；所以narrow cloning可以使编码员在需要的时候从一个克隆选项中选择，混合和匹配。

        “这样做的目的是为了把app的所有组成部分集中到一个地方。” Warren说。“编码员可能会写出很好的Java脚本，但除非构建系统可以找到合适的第三方支付处理系统或者包括设计师最新的图形，构建很有可能失败。这就意味着浪费时间，除非经理和DevOps工程师能解决这个混乱的状况。因此，需要分享数据库中的所有文章，而不只是源代码。”

        Warren逻辑性地指出在一个数据库中mono-repo在崛起。他说很多团队都发现使用mono-repo的乐趣，例如，所有应用程序的源文件都存在于一个地方，这样所有的“利益相关者”都能看到一切，并充分理解改变的影响（或者，同时传播所有项目之间的改变）。

              Warren说：“这是一个非常强有力的命题。但是，使用像Git这样的工具（从来不想持有这些gb或tb的代码和资产）真的是一个不利因素。需要区分反常的行为并且使它正常行动。工作流必须适应这些人工限制而不是编码员所需要的工具。因此，在Helix中需要有一个有效的可无限扩展的主数据库，当结合narrow cloning时它是非常有效的。

         下一步我们要做什么？

        不幸的是我们还要面对许多挑战。如果我们现在已经有一些基础克隆和分支管理的改革方法，那么我们是否有一个长期的数据恢复和高可用性？如果我们回到个人开发等级（记得这个问题是从哪里开始的么？）那么这个答案肯定是不行，不是么？但是我们现在讨论开发者自由和企业需求之间的技术嫁接型挑战，所以数据恢复和可用性必须被提及。

       开发商店是否应该采用备用的虚拟机器作为文件系统中映射变化的一种方式？这样的话存储可以改变，因为需要提供数据恢复的支柱。个人开发者并不会很介意，所以公司最好确认这一点。更高级项目管理的仪表盘控制问题呢？身份验证和安全问题呢? 我们还没有研究这么多。

        从这些讨论中我们可以推测的事实是野外的开发者自然会有截然不同的工作方式，他们将更严格的在企业发展商店的系统内工作。

        我们也可以认为新一代架构级软件开发工具和交付方法正在针对跨功能和控制的需要开发。

         我们也同意光速汽车的灯光是否会打开这个问题contradicts Einstein’s special theory of relativity. 这意味着没有物体的质量能够达到或超过光速，因为物体的阻力加速度和有限的力量将会被施加到物体上。你看，开发者几乎一直是正确的，所以公司最好习惯这种心态。