构建软件部署管道

建筑（30）， 软件工程（15）， 部署（2）

当Digg的工程团队被收购到社交码时，我们有一个慷慨的技术和文化难题来思考，但最直接的挑战是一个工程团队的缩放过程，其成员们翻了一夜之间。

虽然我认为面向服务的体系结构用于扩展人员，它们可能不是扩展团队和流程的首选机制。可复制的部署管道是扩展工程团队的第一个也是最好的工具。

出色的部署管道：

  1. 让新的租用在第一天部署到生产，
  2. 在达到客户之前停止一个糟糕的变化，
  3. 用一个平凡的、可预测的系统取代部署神秘主义，
  4. 加快发展。

嗯，那是什么样子的？

[TOC]

工具链

我们的方法将需要少数工具：

  1. 代码的存储库（吉特那汞，......），
  2. 一种代码检查机制，带有钩子(杰里特那Bitbucket.那GitHub.，......），
  3. 构建服务器或服务（詹金斯那特拉维斯CI，......），
  4. 将代码移动到服务器的机制（厨师那俱乐部，......）。

部署的各个阶段。

您选择的工具的组合将产生重大影响，但任何选择都将能够支持合理的部署管道。我与Git，GitHub，Jenkins和Chef有很好的体验，并建议将其视为一个良好的起点。

（Gerrit很可能不一个很好的起点，除非你有牦牛剪。）

提交者的工作流程

有了这些工具，让我们把自己放在工程师的位置上，希望将他们的代码部署到生产环境中。他们的工作流程是这样的（目前假设这个特定的更改没有争议，并且不会破坏任何测试）：

  1. 它们在个人代码存储库中开发更改。
  2. 准备好进行审核时，他们将变化转换为代码审查系统，这会自动通知他们的同事们有一个新的变更器准备好进行审查。
  3. 一旦代码被审查，提交者就会将他们的变更集合并到权威代码库中。
  4. 一旦更改部署到alpha环境的服务器上，构建服务器就会发送电子邮件。
  5. QA团队或工程师检查alpha环境，然后单击构建服务器上的按钮部署到staging。
  6. 在暂存中部署更改后，构建服务器电子邮件。
  7. 他们单击另一个按钮并将代码推广到生产中。
  8. 当构建服务器通知它们时，他们的代码在生产中，它们验证了所有在生产环境中都很好。
  9. 成功。

提交者的时间和关注此部署的礼物是相当简单的，同样重要的是，他们是简单的行动，要求既不是判断判决的陈述也不是记忆的壮举。

工具链的工作流

部署的细分阶段。

现在，让我们从工具的角度来看相同的流程：

  1. 代码评审工具接收更改并通知团队。
  2. 代码审查完成后，代码审查工具将更改合并到阿尔法分支机构。
  3. 生成服务器检测上的新更改阿尔法和：
    1. 运行语法和样式检查器，
    2. 运行单元测试，
    3. 通知服务器配置工具部署阿尔法到alpha服务器，
    4. 部署后，对Alpha运行集成测试。
  4. 当有人手动触发暂存生成时：
    1. 合并阿尔法进入登台那
    2. 通知服务器配置工具部署登台到暂存服务器，
    3. 部署后，运行集成测试对暂停。
  5. 当有人手动触发生产构建时：
    1. 合并登台进入生产那
    2. 通知服务器配置工具部署生产要生产服务器，
    3. 部署后，对产品运行集成测试。
  6. 成功。

工具链所采取的每一步都是工程师不再需要执行的步骤，也是他们既不能搞砸，也不能忽略或忘记的步骤。这就是部署管道如何在提高开发人员吞吐量的同时提高可预测性。

管理速度与安全权衡

随着您的团队和组织的发展，事情会以您无法有效预期的方式发生变化：您可能决定需要一个手动QA团队，您可能会采用不同的编程语言，您可能会转向使用静态JavaScript前端来分离代码基，或者其他一些事情。

您的部署管道需要能够适应不可知的未来。

您可以分层使用其他工具，并通过以下机制管理速度与安全之间的权衡：

  1. 一个经验丰富的小型团队可以跳过代码评审，直接合并到权威代码库中。
  2. 每个构建都可以选择它的工具：
    1. 语法和样式过梁（如皮塔尼特那Pep8或JShint.）很棒的新项目，但对于遗留项目来说可能太严格，
    2. 如果使用预提交挂钩运行测试，则可以跳过运行测试，
    3. 您可以添加其他验证工具和检查。
  3. 每个项目对每个环境都有不同的构建，允许您根据以下条件运行不同的验证：
    1. 您要部署到的环境（可能只对alpha的更改文件运行测试，但在合并到暂存环境之前运行完整的测试套件），
    2. 项目：仅内部工具可能不需要多大验证。
  4. 拥有三种环境（alpha，暂存，生产）是相当普遍的，但也相当繁多。一项经验法则：如果您有三个以上的工程师，您可能需要两个环境，如果您有手动QA或想要交错生产发布超过几天，那么您可能需要三个环境。
  5. 从Alpha到分期和暂存到生产的过渡可以是自动的。制作过渡手册提供了更多对发射时机的控制，并有助于手动测试，但选择是您的选择！

使用像Jenkins这样的构建服务器，您的构建只是一个脚本，在满足某些条件时执行，为您提供了对您的情况进行优化的大量灵活性。因此，限制主要是想象力......或者因为您的构建服务器仍在运行Ubuntu 12.04。

额外提示和评论

以下是一些额外的想法，不值得完整部分：

  1. 何时应该添加部署管道？如果您是两个或三个工程师的小型创始团队，特别是如果您没有任何组织对系统管理特别舒适，那么维护管道的开销可能会足够高，以掩盖益处。一旦你开始雇用非创始工程师，可能是时候潜水了。
  2. 绕过迫切和紧急推动的保障措施怎么样？正常的部署路径应该是最佳路径，尤其是在紧急时刻。如果不是这样，请思考您需要如何调整您的部署以使其正确。（您可能已经习惯了当前构建管道中的一个重大性能问题，或者单元测试的编写方式依赖于外部资源。这两个都不好，值得修复。）
  3. 为什么不连续部署？此方法使用持续部署到alpha环境，但在进一步进一步之前需要手动批准。经验表明，耦合合并的代码和部署到生产验证了最令人不愉快的方法的测试质量。（如果有罪党在临时回家，这也是在同事额头中识别静脉的一项很好的工作。）
  4. 自动构建的意外好处正在减少您提供语法和风格反馈的义务，这可以使您和您提供反馈的人质疑其所选职业的人。相反，您依靠构建服务器进行迂腐，这 - 作为一个灵魂的自动机 - 它非常好。

我在这里描述的部署管道是基本的，并且已经成熟，可以进行改进，但是在目睹了推出一个令人愉快的部署管道的影响之后，这绝对是我清单上的第一件事，用于扩展团队和提高工程师的生活质量。

好吧，希望这里有一些有用的小道消息，像往常一样，我很有兴趣听到一些建议和替代方法！