♥️ 🎛️ ✍🏽 Slack使用的项目部署方法 🙅🏾 ⌨️ 🔧

要完成新项目的发布，需要在部署速度和解决方案的可靠性之间进行仔细的权衡。 Slack喜欢快速迭代，较短的反馈循环以及对用户请求的响应能力。此外，该公司拥有数百名致力于尽可能提高生产率的程序员。

该材料的作者（我们今天出版的译文）说，一家寻求坚持这种价值观并同时成长的公司应不断改善其项目部署系统。公司需要投资于工作流程的透明性和可靠性，以确保这些流程与项目范围相符。在这里，我们将讨论在Slack中开发的工作流程，以及导致该公司使用当今存在的项目部署系统的一些解决方案。

今天的项目部署流程如何运作

Slack中的每个PR（拉动请求）都必须经过代码审查，并且必须成功通过所有测试。仅在满足这些条件后，程序员才能将其代码与项目的master分支合并。但是，仅根据北美时间在工作时间内执行此类代码的部署。因此，由于我们的员工在工作，我们已做好充分准备，可以解决任何意外的问题。

每天我们完成大约12个计划的部署。在每次部署期间，被指定为主部署的程序员负责将新程序集投入生产。这是一个多步骤过程，可在工作模式下顺利完成组装。通过这种方法，我们可以在错误影响到我们所有用户之前检测出错误。如果有太多错误，则可以回滚程序集的部署。如果在发行后检测到特定问题，则可以轻松地发布修复程序。

Slack用于部署项目的Checkpoint系统的界面，

可以在四个步骤中表示在生产环境中部署新版本的过程。

▍1。创建一个发布分支

从我们Git历史的那一刻起，每个版本都以一个新的版本分支开始。这使您可以为发行版分配标签，并提供一个地方，可以对在准备将发行版投入生产时发现的错误进行操作更正。

▍2。中间部署

下一步是将程序集部署到登台服务器，并对项目的整体性能运行自动测试（烟雾测试）。中间环境是生产环境，其中外部流量不会下降。在这种环境下，我们将进行其他手动测试。这使我们更加确信修改后的项目可以正常工作。单凭自动化测试不足以赢得这种信心。

▍3。在狗粮和金丝雀环境中部署

生产中的部署始于以一组供我们内部Slack工作区使用的主机代表的狗粮环境。由于我们是Slack的非常活跃的用户，因此使用这种方法有助于在部署的早期阶段检测到许多错误。在确保系统的基本功能没有中断之后，将程序集部署在Canary环境中。它是一个接收约2％生产流量的系统。

▍4。生产中的逐步结论

如果新版本的监视指标显示稳定，并且在Canary环境中部署项目之后我们没有收到投诉，我们将继续将生产服务器逐步转移到新版本。部署过程分为以下几个阶段：10％，25％，50％，75％和100％。因此，我们可以将生产流量缓慢转移到新的系统版本中。同时，我们有时间调查情况以防发现某些异常情况。

if如果在部署过程中出现问题怎么办？

修改代码总是有风险的。但是，由于我们训练有素的“部署经理”能够管理此问题，因此他们可以管理将新发行版引入生产过程，监控监视性能并协调发布代码的程序员的工作。

如果确实出了什么问题，我们将尽早发现问题。我们调查问题，找到导致错误的PR，将其回滚，仔细分析并创建一个新的程序集。没错，有时候在项目投入生产之前，问题就不会被注意到。在这种情况下，最重要的是恢复服务。因此，在开始研究问题之前，我们立即回滚到以前的工作程序集。

部署构件

考虑我们的项目部署系统的基础技术。

▍快速部署

回想起来，上述工作流程似乎是完全显而易见的。但是我们的部署系统并没有马上发展。

当公司规模明显缩小时，我们的整个应用程序可以在10个Amazon EC2实例上运行。在这种情况下部署项目意味着使用rsync快速同步所有服务器。以前，新代码仅通过一个步骤（由中间环境表示）与生产分开。在这样的环境中创建并测试装配，然后直接投入生产。了解这样的系统非常简单；它允许任何程序员随时部署他编写的代码。

但是随着客户数量的增加，确保项目运营所需的基础架构规模也随之增加。很快，由于系统的不断增长，基于向服务器发送新代码的我们的部署模型不再满足其任务。即，每台新服务器的增加意味着完成部署所需的时间增加。即使基于并行使用rsync的策略也有一定的局限性。

结果，我们通过切换到完全并行的部署系统解决了这个问题，该系统的排列方式不像旧系统那样。即，现在我们没有使用同步脚本将代码发送到服务器。现在，由于观察Consul密钥的更改，每个服务器都独立下载了一个新程序集，得知需要完成该程序集。服务器并行下载代码。这使我们即使在系统不断增长的环境下也能保持较高的部署速度。

1.生产服务器监视Consul密钥。2.密钥正在更改，这告诉服务器它们需要开始下载新代码。3.服务器上传带有应用程序代码的tarball文件

▍原子部署

帮助我们使用多层部署系统的另一个解决方案是原子部署。

在使用原子部署之前，每个部署都可能导致大量错误消息。事实是，将新文件复制到生产服务器的过程不是原子的。这导致存在较短的时间跨度，即在调用功能本身可用之前，调用新功能的代码可用。调用此类代码时，它返回内部错误。这在不成功的API请求和破碎的网页中得到了体现。

解决此问题的团队通过引入“热”（热）目录和“冷”（冷）目录的概念解决了该问题。“ hot”目录中的代码负责处理生产流量。在系统运行时，仅在“冷”目录中的代码可供使用。在部署过程中，新代码将复制到未使用的“冷”目录中。然后，当服务器上没有活动的进程时，目录将立即切换。

1.将应用程序代码解压缩到“冷”目录中。2.将系统切换到“冷”目录，该目录变为“热”（原子操作）

底线：对可靠性的关注转移

在2018年，该项目发展到了如此之大的规模，以至于快速部署开始损害产品的稳定性。我们有一个非常先进的部署系统，我们在其中花费了大量的时间和精力。我们只需要重组和改进部署组织流程。我们已经成为一家相当大的公司，其发展在全世界范围内被用于组织不间断的通信并解决重要问题。因此，我们关注的重点是可靠性。

我们需要使部署新的Slack版本的过程更加安全。这种需求促使我们改进了部署系统。实际上，上面我们讨论了这个改进的系统。在系统的核心，我们继续使用快速和原子部署的技术。更改了执行部署的精确度。我们的新系统旨在逐步在不同环境中的不同级别上部署新代码。现在我们使用比以前更高级的辅助工具和工具来监视系统。这使我们有机会在错误有机会到达最终用户之前就捕获并消除错误。

但是我们不会到此为止。我们正在使用更高级的辅助工具和自动化工具来不断改进该系统。

亲爱的读者们！在您工作的地方部署新项目版本的过程如何？

Slack使用的项目部署方法