我爱分享网这篇博文包含我在母校弗吉尼亚大学给 M.S. 2017 年 11 月 2 日至 4 日的信息技术管理专业。
可以在侧边栏和本页底部找到有关本次演讲中提出的概念的详细信息的链接。
大家好，我叫 Matt Makai。我是 Twilio 的一名软件开发人员，也是 Full Stack Python 的创建者，每月有超过 125,000 名开发人员阅读该书以学习如何构建、部署和操作基于 Python 的应用程序。
你已经谈到在你的团队中使用敏捷软件开发方法，但目的是什么？为什么敏捷开发对您和您的组织很重要？
敏捷很重要，因为它允许您交付更多代码，比传统的“瀑布”方法方法更快.
交付是当今软件开发中的一个常见寓言，因为未在生产中、在用户手中的代码不会为任何人创造价值。
如果代码没有在生产中运行，它就不会创造价值。敏捷开发团队每隔几周创建的新代码在生产中执行之前不会创造更多价值。
航运代码对于高功能公司非常重要，以至于海事主题被用于各种项目，包括在 Dockerlogo 中。
以及船舵轮形式的Kubernetes标志。
这是我们需要的敏捷开发团队理想场景的超高层图表。创建工作代码并尽快将其投入生产。
Facebook 的内部格言曾经是“快速行动，打破陈规”。他们认为，如果你不破坏东西，那么你就不够快。
最终如果你不断地运送到生产并且你没有适当的流程和工具到位，您的应用程序将崩溃。破损与敏捷方法本身无关。
当您最终遇到一个糟糕的环境时，您的团队和组织将走到岔路口。
传统上，组织试图通过放置更多手动工具和流程来防止损坏。体力劳动会减慢…您的…能力…执行。
这是岔路口提供的一条路径。将您的“EnterpriseChange Review Boards”放置到位。要求某位从未写过一行代码的执行副总裁签署生产协议。将几十名“技术架构师”放在一个房间里，讨论谁可以在当月将他们的变更部署到生产中。
手动路径是疯狂的。最终，你组织中最好的开发人员会感到沮丧并离开。高管们会问为什么什么都做不成。为什么我们的组织需要三年时间才能对关键应用程序进行微小更改？
一些开发团队试图通过将所有内容发送到开发环境来解决手动生产挑战。开发环境在他们的控制之下。
但在这种情况下，最明显的问题是什么？
如果您不交付生产，那么您就不会为您的用户创造任何价值。团队做出了交付开发的理性决定，但由于手动控制，组织仍然受到影响。
我们所说的问题是由敏捷方法创造的，因为当你开发时它们变得尖锐团队正在高速生产代码。更快地创建代码后，您需要一种方法来可靠、一致地将代码投入生产，以便它可以为用户创造价值。
DevOps 和持续交付是广义术语，涵盖了如何可靠地将代码发送到生产环境并在代码在生产环境中运行时对其进行操作。
我们今天将大量使用术语“DevOps”和“持续交付” ，所以让我们从定义它们的含义开始。事实上，术语“DevOps”已经积累了很多流行语包袱，所以我们将从定义 DevOps 不是开始。
首先，DevOps 并不是一个新角色。如果你雇了一群人，称他们为“DevOps 工程师”，然后让他们坐在你的开发人员和系统管理员/运维人员中间，你将会有一段糟糕的时光。您刚刚在需要拉近距离的两个组之间添加了一个新层。
其次，DevOps 不是特定的工具或应用程序。您不需要使用 Docker 或 Puppet 在您的组织中执行 DevOps。使 DevOps 工作的过程通过一些工具变得容易得多，例如基础设施是瞬态的云平台，但即使是这些平台也不需要正确地执行 DevOps。
第三，DevOps 不依赖于特定的编程语言生态系统。您不需要使用 Node.js 或 Ruby on Rails。您仍然可以在仅使用 COBOL 或 J2EE 的组织中使用 DevOps。
抛开这些误解，让我们来谈谈 DevOps 是什么。首先，在DevOps 是 Development 和 Operations 这两个词的组合，风险太明显了。这种组合不是随机配对，而是有意为之。
其次，DevOps 意味着您的应用程序开发人员处理操作。不一定所有操作都有效，但操作处理他们编写和部署的代码作为冲刺的一部分。开发人员还可能非常熟悉底层基础设施，例如 Web 应用程序服务器、Web 服务器和配置管理工具的部署代码。
第三，DevOps 通过确保由正确的人员处理错误和应用程序故障，使您的组织能够更有效地处理问题。
我们不会通过定义它不是什么来经历持续交付 (CD)，但有几点要说。首先，CD 是一系列工程实践，旨在自动交付代码，从版本控制签入到在生产环境中运行。
自动化 CD 方法的好处是您的组织将对在生产中运行的代码更有信心，即使代码本身在每次部署中更改得更频繁。
Facebook 最初的座右铭在几年前改为“Move Fast and BuildThings”，因为他们意识到中断生产并不是快速行动的副产品，而是组织流程和工具不成熟的结果。 DevOps 和持续交付是为什么组织现在可以每天将数百或数千次部署到生产环境中，并且随着他们继续更快地移动，他们对系统的信心增加而不是减少。
让我们看几个示例场景，了解 DevOps 和 CD 的全部内容，并了解属于该领域的一些流程、概念和工具。
这是我刚刚离开的城市旧金山的美丽夜景照片。
我工作的公司Twilio位于旧金山。如果您飞到 SFO 机场并乘车前往市中心，您会在路的右侧看到我们的广告牌。
Twilio 使软件开发人员可以轻松地将电话、消息和视频等通信功能添加到他们的应用程序中。我们是一家以软件的强大功能为基础的电信公司，客户无需购买他们过去必须购买的所有昂贵的旧硬件。作为一家电信公司，我们永远不能倒闭，否则我们的客户会被洗劫一空，然后我们的业务也会被洗劫一空。
但是，我们在历史上遇到过挑战，这些挑战迫使我们面对手动流程和通过信任我们的自动化更快地前进之间的岔路口。
2013 年 8 月，Twilio 面临基础设施故障。
首先，一些上下文。当开发人员注册 Twilio 时，她会在他们的帐户上存入一些信用额度，然后通过打电话、发送消息等方式使用信用额度。当信用额度不足时，我们可以为您的卡充值，以便您获得更多信用额度。
2013 年 8 月经常性收费出现重大生产问题。我们的工程师收到警报错误和问题在 Hacker News 的顶部爆炸，引起了广泛关注。
那么现在出现了一个重大的生产错误……我们该怎么办？
（读者注意：本节主要是听众根据自己处理这些困难技术情况的经验进行讨论。）
第一步是弄清楚问题何时开始以及是否已经结束。如果还没有结束，请对具体问题进行分类并开始与客户沟通。尽可能准确和透明。
这个案例中的具体技术问题是由于我们对Redis实例的错误配置。
我们知道特定的技术故障是由于我们的 Redis 处理不当造成的，但是我们如何超越特定的部分并更广泛地了解导致问题的过程？
我们先看看情况的解决，再了解下解决的概念和工具可以防止将来出现问题。
在这种情况下，我们尽可能多地与客户沟通问题。作为一家以开发人员为中心的公司，我们很幸运，通过对具体技术问题保持透明，我们的许多客户赢得了对我们的尊重，因为他们在自己的环境中也遇到过类似的错误配置。
Twilio 的服务状态变得更加透明，尤其是显示部分故障和中断。
Twilio 还故意避免积累其他组织经常投入的手动流程和控制失败后的位置。我们通过自动化加倍提高弹性，以提高部署到生产环境的能力。
我们在 Twilio 使用哪些工具和概念来防止未来的故障情况？
如果你没有合适的工具和流程，最终你会得到一个运输代码后破坏生产环境。我们可以使用什么工具来确保投入生产的代码没有损坏？
自动化测试，有多种形式，如单元测试、集成测试、安全测试和性能测试，有助于确保代码的完整性。您需要自动化，因为手动测试太慢了。
属于自动化测试范畴但传统上不被视为“测试用例”的其他重要工具包括代码覆盖率和代码指标（例如圈复杂度）。
太棒了，现在你只有在大量自动化测试用例保证完整性的情况下才能部署到生产环境你的代码。一切都好，对吧？
呃，没有。东西仍然可能在生产中中断，特别是在由于各种原因您在测试中没有与生产中完全相同的数据的环境中。您的自动化测试和代码指标不会捕捉到每一个可能在生产中出错的场景。
当你的应用出现问题时，你需要监控才能知道问题出在哪里，并且提醒告诉正确的人。传统上，“正确”的人在操作。但随着时间的推移，许多组织意识到运维人员最终不得不联系编写有问题代码的原始应用程序开发人员。
DevOps 的一个关键部分是确保适当的开发人员携带寻呼机。携带寻呼机并在半夜醒来很糟糕，但调试你的团队编写的代码比你是一个从未见过代码的随机操作人员要容易得多。
让应用程序开发人员携带生产问题警报的“寻呼机”的另一个副产品是，随着时间的推移，他们编写的代码更具防御性。错误得到更适当的处理，因为否则你会知道稍后会在不太方便的时候发生一些事情。
通常你会发现仍然有很多生产错误即使你有防御代码放置大量不断测试的代码库最重要的部分。
这就是一个被称为“混沌工程”的概念可以发挥作用的地方。混沌工程打破了部分您的生产环境按计划甚至不按计划进行。这是一项非常先进的技术 – 您不会在没有现有自动化测试覆盖率或适当控制措施的环境中销售它。
通过故意引入失败，特别是在白天，当你的团队可以解决问题时并采取进一步的保护措施，使您的生产环境更具弹性。
几年前我们谈到了 Twilio 支付基础设施的失败，导致我们最终变得更加通过适当的自动化来抵御故障。
糟蹋别人的钱真不好，糟蹋人的命也不好。
让我们讨论一个人命关天的场景。
为了明确说明下一个场景，我只打算谈论公共信息，以便我的听众中的人可以放松。
在 2007 年美军在伊拉克激增的高峰期，更多的简易爆炸装置正在杀戮和伤残士兵和平民比以往任何时候都多。这是一个令人难以置信的悲剧，导致该国当时的不确定性。
然而，生物识别方面的努力是帮助防止更多攻击的难题之一，因为这张图片来自彼得雷乌斯将军向国会提交的报告。
该项目的一个主要挑战是糟糕的手动构建过程用于创建应用程序工件的集成开发环境。该过程过于手动，最终结果是最新版本的软件投入生产的时间太长。
我们没有自动部署到开发环境、暂存或生产。
我们的团队不得不从某个地方开始，但由于缺乏批准的工具，我们所有可用的工具对我们来说是 shell 脚本。但是 shell 脚本是一个开始。我们能够为开发环境创建一个非常脆弱但可重复的自动化部署过程吗？
但仍然存在一个巨大的明显问题：在代码实际部署到生产环境之前，它不会为用户提供任何价值。
在这种情况下，我们永远无法完全自动化部署，因为我们必须刻录到 CD在移动到物理上不同的计算机网络之前。不过，该团队可以将几乎所有其他事情自动化，这对迭代和部署速度非常重要。
您可以使用可用的工具尽力而为。
自动化部署背后的工具和概念是什么？
源代码存储在源代码控制（或版本控制）存储库中。源代码控制是自动化过程的开始，但是我们需要什么才能使用可重复的自动化过程将代码放入各种环境？
这就是持续集成的用武之地。持续集成从版本控制系统获取您的代码、构建它、测试它并在将代码部署到环境之前计算适当的代码指标。
现在我们有一个连接到源代码管理的持续集成服务器，但是这张图片看起来还是很奇怪.
技术上，持续集成不处理构建的细节以及如何配置单独的执行环境.
配置管理工具处理应用程序代码和环境的设置。
这两个场景为 DevOps 和 ContinuousDelivery 为什么对不同行业的组织很重要提供了一些背景。当您拥有通过敏捷开发方法论工作的高绩效团队时，您将遇到一系列无法通过“更好”地实施敏捷来解决的问题。您需要我们今天讨论的工具和概念以及大量其他工程实践才能将新代码投入生产。
我们今天介绍的工具和概念是自动化测试、监控、混沌工程、持续集成和配置管理.
在继续您的旅程时，您还需要许多其他实践。您可以了解所有他们在 Full Stack Python 上。
今天就到这里。我叫 Matt Makai，是 Twilio 的一名软件开发人员，也是 Full Stack Python 的作者。非常感谢。
可以在各自的页面上找到有关以下主题的更多信息的其他资源：
- 部署
- 持续集成
- 无服务器计算
- AWS Lambda
- 静态站点生成器
- 监控
- DevOps
- 配置管理
- 平台即服务 (PaaS)
- Docker
- Web 应用程序安全
- 测试
- 源代码控制
- Git
- 代码指标
- NoSQL
