软件公司总是面临这样一个问题：如何在速度和安全之间达成一个令人满意的媒介，那么内部通信系统是如何管理的呢？为了构建世界级的软件，技术公司需要发布大量代码。在对讲机公司，在过去的六个月里，我们每天发送代码多达81次，快速迭代并向客户提供新功能。在确保必要的安全措施到位的同时，我们如何快速发布代码？它与其他公司处理运输代码的方式有什么不同？在我作为软件工程师的职业生涯中，大数据数据采集，我曾在一些公司工作过，这些公司以非常不同的方式来处理这一问题。这些流程是根据公司的业务需求而制定的。他们有什么样的产品？什么样的顾客？他们如何在市场中定位？这篇文章是基于我在最近的建筑内部通讯活动上的一次演讲。你可以看下面的谈话全文。专注于速度当我刚开始我的职业生涯时，我在一家公司工作，我们称之为"a公司"。A公司没有自己的产品，阿里大数据分析，而是在为客户开发软件。从某种意义上说，软件是它的主要产品。因为我们是为客户交付软件，所以最后期限是事先约定好的，而且很难改变。这意味着在开发阶段，我们专注于编写代码。我们想把产品拿出来，而不是专注于编写自动化测试。维护通常是在产品的第一个版本交付之后进行的，客户通常会额外收费。编写代码大约占项目分配时间的80%，数据技术与大数据技术，而这些项目通常持续两到三个月。在编码阶段的最后，我们将进行手动测试。这通常是由一个单独的QA团队来完成的，该团队将检查产品以确保其符合规范。一旦他们对最终产品感到满意，他们就把它交给我们进行快速的技术评估——通常由团队中的某个人进行，云服务器一年多少钱，但此人并不直接参与项目。如果他们没有发现任何明显的技术问题，它就可以出货了。通常，我们的项目经理都很高兴。有一次，我在公司花了整整一个圣诞节的时间试图修复一个bug这个开发过程非常快——我有一段时间来编写代码，其间几乎没有中断。然而，这个过程并没有强调安全性，有时会出问题。在这些事件中，开发过程看起来并没有太大的不同。我们会尝试找出问题的根本原因，应用修复程序，重复测试过程，进行技术审查，然后祈祷它能正常工作。有一次，我在公司花了整整一个圣诞节的时间，试图修复我两天前发布的一个bug。当我的家人在家里享用晚餐和喝酒时，我独自一人坐在冰冷的办公室里，试图让这件事再次运转起来。我不推荐。注重可靠性在A公司之后，我转到B公司工作，这家公司的工作方式截然不同。与A公司不同，B公司有自己的产品。它正在开发服务，作为其他公司的基础设施。在开发用作基础设施的服务时，正常运行时间至关重要。重要的是，这些服务始终有效，而且停机时间很少，因为每次停机都会侵蚀客户的信任。B公司有一个非常漫长的过程，以尽量减少发生这种情况的风险。这个过程首先编写一些代码并提交给评审，然后通过一些测试运行它。然而，在那之后，代码将在那里停留大约两个星期。为什么？由于业务的性质，我们必须提供详细的文档–您将要部署的更改对业务和操作的影响是什么。重点是尽量减少出错的风险，以及如果出了问题该怎么办。然后，该文件必须由团队中的一名或两名工程师和我们的经理审查。在装运之前，我们必须执行另一组手动测试，以确保没有明显损坏，最后我们准备好装运。出了问题我们怎么办？好吧，首先，我们会设法立即收回零钱。但有时这并不容易，例如，如果您只是部署了一个客户已经看到的UI更改。如果你回退，那将导致一个非常糟糕的客户体验。所以我们决定向前推进，这意味着你要尽快修复错误。有时不太明显是什么破坏了构建，因为您刚刚部署了大量提交。首先，你需要确定问题的根本原因是什么。然后开始修复bug，然后基本上重复我刚才描述的过程。编写代码，进行评审测试，然后部署。B公司的这一过程被设计成非常安全的，但尽管有时不可避免地会出问题，但我认为在我在那里工作的三年里，我从未发布过一个导致重大停机的bug。然而，我也没有提供我想要的那么多功能——过程很慢。对讲机进近然后我加入了对讲机。如果你愿意的话，C公司。为了展示对讲机对快速工作的重视程度，在我的第一周，我被要求发布一个功能。老实说，当他们告诉我，"哦，你需要在第一周内装运一些东西"时，我吓呆了。我刚从B公司来，说："我不可能做到的，对吧？我和自己进行了长时间的讨论，"嗯，也许这个对讲机不是个好主意。"但我做到了。我们有什么流程可以让我在第一周发布一个功能，同时保持高安全标准？我们接受大项目，然后把它们分成小部分。我们总是尽量把最小的有意义的零件运出去。我们能为客户提供的最微小的东西是什么？我们的过程首先设置一个feature标志，这个简单的机制使我们能够控制谁有权访问这个特性。通过设置特性标志，我们只向特定的一组用户公开功能。我们可以控制谁看到这个功能。我们尽量避免过早地将特性暴露给太多的人。然后我们收集反馈并迭代。我们能为客户提供的最微小的东西是什么？在我们设置了特性标志之后，我们编写了一些代码并提交代码以供审阅。在等待评审时，自动测试开始了。一旦代码被批准并且测试成功通过，我们就可以合并到主分支中。一旦代码被合并，测试将再次开始。当测试运行时，我们的内部部署工具会收到一个通知，说明它已经准备好部署了。一旦部署完成，代码就已经发布了。整个过程可能需要一天到一周的时间，具体取决于功能。当然，这种方法确实面临一些挑战。我们的部署在测试允许的范围内尽可能快，并且随着代码库的不断增长，测试也会继续增长。我们试图通过将测试并行化并将它们分割成更小的块来实现这一点，以便它们能够更快地运行。作为一个主要从事用户界面工作的人，我看到了一些CSS的变化，这些变化将会中断，大数据开发平台，即使是最复杂的UI测试也无法捕捉到。因此，有时手动测试仍然是必要的，以便捕捉这些变化。优先事项问题我从这些经历中得到了一些启示。首先，工程师们喜欢有生产力，这意味着要发布代码。他们喜欢感受过程的一部分，而不是害怕。第二个好处是，有了良好的测试，我们就可以放心地发布代码了。虽然编写测试有时会很枯燥，但是花两个小时编写测试要比花圣诞节去修复本该被发现的东西要容易得多。但最主要的收获是，企业不应该牺牲安全换取速度，或者确实是为了安全而牺牲速度。不同的软件公司有不同的客户，有不同的需求，导致不同的激励，结果，不同的过程。这些不同的方法有各自的优点，可能最适合这些情况，而最佳平衡将因公司而异。然而，在对讲机公司，我们实现了一种平衡，不仅通过提供具有常规新功能的安全产品来为客户服务，而且还让我们的工程师感到高效。和任何平衡行为一样，它需要持续的努力和专注来维持平衡。