将新项目版本投入生产需要在部署速度和解决方案可靠性之间进行仔细平衡。 Slack看重快速迭代、短反馈周期、及时响应用户请求。 此外，该公司还有数百名程序员，他们努力提高工作效率。
我们今天发布的该材料的译文的作者表示，一家努力坚持这种价值观并同时发展的公司必须不断改进其项目部署系统。 公司需要投资于工作流程的透明度和可靠性，这样做是为了确保这些流程与项目的规模相对应。 在这里，我们将讨论在 Slack 中开发的工作流程，以及导致公司使用当今存在的项目部署系统的一些决策。
如今项目部署流程如何运作
Slack 中的每个 PR（拉取请求）都必须接受代码审查，并且必须成功通过所有测试。 只有满足这些条件后，程序员才能将自己的代码合并到项目的master分支中。 但是，此代码仅在北美时间的工作时间部署。 因此，由于我们的员工都在工作场所，我们已做好充分准备来解决任何意外问题。
我们每天都会进行大约 12 次计划部署。 在每次部署期间，指定为部署负责人的程序员负责将新版本投入生产。 这是一个多步骤的过程，可确保组装顺利投入生产。 借助这种方法，我们可以在错误影响所有用户之前检测到错误。 如果错误太多，可以回滚程序集的部署。 如果发布后发现特定问题，可以轻松发布修复程序。
Checkpoint系统的接口，用于Slack中部署项目
将新版本部署到生产环境的过程可以被认为由四个步骤组成。
▍1. 创建发布分支
每个版本都以一个新的版本分支开始，这是我们 Git 历史中的一个点。 这允许您为版本分配标签，并提供一个位置，您可以在其中实时修复在准备版本以发布到生产的过程中发现的错误。
▍2. 在暂存环境中部署
下一步是将程序集部署在临时服务器上，并对项目的整体性能运行自动测试（冒烟测试）。 登台环境是不接收外部流量的生产环境。 在此环境中，我们执行额外的手动测试。 这让我们更有信心修改后的项目可以正常工作。 仅自动化测试不足以提供这种程度的置信度。
▍3. 在 Dogfood 和 Canary 环境中部署
部署到生产环境从测试环境开始，由一组为我们内部 Slack 工作区提供服务的主机表示。 由于我们是非常活跃的 Slack 用户，因此采用这种方法帮助我们在部署初期发现了很多错误。 在我们确保系统的基本功能没有被破坏之后，程序集被部署在金丝雀环境中。 它代表约占生产流量 2% 的系统。
▍4. 逐步发布到生产环境
如果新版本的监控指标稳定，并且在金丝雀环境中部署项目后没有收到任何投诉，我们将继续将生产服务器逐步转移到新版本。 部署过程分为以下阶段：10%、25%、50%、75%和100%。 这样，我们就可以慢慢地将生产流量转移到新版本的系统上。 同时，如果发现任何异常情况，我们也有时间去调查情况。
▍部署过程中出现问题怎么办？
修改代码始终存在风险。 但我们能够应对这一问题，这要归功于训练有素的“部署领导者”的存在，他们管理将新版本投入生产的过程，监控监控指标并协调程序员发布代码的工作。
如果确实出现问题，我们会尽力尽早发现问题。 我们调查问题，找到导致错误的 PR，将其回滚，彻底分析，然后创建新的构建。 确实，有时这个问题在项目投入生产之前才被注意到。 在这种情况下，最重要的是恢复服务。 因此，在开始调查问题之前，我们立即回滚到之前的工作版本。
部署系统的构建块
让我们看一下项目部署系统背后的技术。
▍快速部署
回想起来，上述工作流程似乎有些显而易见。 但我们的部署系统并没有立刻变成这样。
当公司规模小得多时，我们的整个应用程序可以在 10 个 Amazon EC2 实例上运行。 在这种情况下部署项目意味着使用 rsync 来快速同步所有服务器。 以前，新代码距离生产仅一步之遥，由暂存环境代表。 组件是在这样的环境中创建和测试的，然后直接投入生产。 这样的系统很容易理解；它允许任何程序员随时部署他编写的代码。
但随着我们客户数量的增长，支持该项目所需的基础设施规模也在不断扩大。 很快，鉴于系统的不断增长，我们基于将新代码推送到服务器的部署模型不再发挥作用。 也就是说，添加每台新服务器意味着增加完成部署所需的时间。 即使基于并行使用 rsync 的策略也有一定的局限性。
我们最终通过转向完全并行的部署系统来解决这个问题，该系统的设计与旧系统不同。 也就是说，现在我们没有使用同步脚本将代码发送到服务器。 现在，每个服务器都独立下载新程序集，因为它们知道需要通过监视 Consul 密钥更改来完成此操作。 服务器并行加载代码。 这使我们即使在系统不断增长的环境中也能保持高速部署。
1.生产服务器监控Consul密钥。 2. 密钥发生变化，这告诉服务器它们需要开始下载新代码。 3. 服务器下载带有应用程序代码的 tarball 文件
▍原子部署
帮助我们实现多层部署系统的另一个解决方案是原子部署。
在使用原子部署之前，每次部署都可能会导致大量错误消息。 事实上，将新文件复制到生产服务器的过程不是原子的。 这导致调用新函数的代码在函数本身可用之前就可用的时间很短。 当调用此类代码时，会导致返回内部错误。 这表现为 API 请求失败和网页损坏。
研究这个问题的团队通过引入“热”和“冷”目录的概念解决了这个问题。 hot目录中的代码负责处理生产流量。 在“冷”目录中，代码在系统运行时只是准备使用。 在部署期间，新代码被复制到未使用的冷目录中。 然后，当服务器上没有活动进程时，将执行即时目录切换。
1. 将应用程序代码解压到“冷”目录中。 2. 将系统切换到“冷”目录，使其变为“热”（原子操作）
结果：重点转向可靠性
2018 年，该项目发展到如此规模，以至于非常快速的部署开始损害产品的稳定性。 我们拥有一个非常先进的部署系统，我们投入了大量的时间和精力。 我们需要做的就是重建和改进我们的部署流程。 我们已经发展成为一家相当大的公司，其开发成果已在世界各地用于组织不间断的通信并解决重要问题。 因此，可靠性成为我们关注的焦点。
我们需要使部署新 Slack 版本的过程更加安全。 这种需求促使我们改进我们的部署系统。 事实上，我们在上面讨论了这个改进的系统。 在系统深处，我们继续使用快速、原子的部署技术。 部署的方式已经改变。 我们的新系统旨在在不同级别、不同环境中逐步部署新代码。 我们现在使用比以前更先进的支持工具和系统监控工具。 这使我们能够在错误到达最终用户之前捕获并修复错误。
但我们不会就此止步。 我们正在不断改进这个系统，使用更先进的辅助工具和工作自动化工具。
亲爱的读者！ 在您工作的地方，部署新项目版本的流程是如何进行的？
来源： habr.com