DevOps——拯救你的代码免于崩溃

软件开发生命周期的定义、情感与理论

DevOps 的魔力和优势

沟通

计划

Scrum

看板

建造

使用 Git 进行源代码控制

容器

持续集成

部署

操作

反馈

概括

一位我以前的计算机科学系同学，现在是一位教授，邀请我去做关于DevOps的演讲。对现在的学生来说，听听业内人士的见解似乎总是很有帮助的。于是，我准备了演讲稿，然后心想，何不把它写成一篇博客文章呢？这就是成果。

我还制作了一个与演讲配套的在线课程。如果您不想阅读文字，只想观看视频，可以点击这里免费 获取课程。

如果你想观看我那次启发我写这篇文章的演讲，可以在YouTube上找到它。

软件开发生命周期的定义、情感与理论

首先，我们来定义一下DevOps。DevOps并没有一个完美的定义，但以下这段话比较贴切。DevOps是

一套结合了软件开发（Dev）和信息技术运维（Ops）的实践方法，旨在缩短从系统变更提交到变更投入正常生产的时间，同时确保高质量。

一方面是软件开发，另一方面是软件的运行或运营。关键在于，很多这类环节都可以自动化，从而缩短软件开发生命周期。

是情绪还是动机？

但在深入细节之前，让我们先来谈谈 DevOps 可能会给你带来怎样的感受——以及它可能会如何激励你。

如果你完全不实践这些方法，可能会遇到麻烦。DevOps 提供了许多工具，可以极大地帮助你构建应用程序。但如果你不使用任何这些工具和实践，那么——相信我，我曾经经历过——你最终可能会变成这样。

完全没有DevOps。一点乐趣都没有。

但是，当你开始掌握这些工具和概念后，开发人员的生活就会变得轻松许多！

你看，这样你可能会更放松。做项目很有趣。或许你还可以喝杯咖啡，好好放松一下。

这是最现实的方案——或者至少是最现实的目标。

当然，还有一种梦想，那就是DevOps为我们包办一切。所有事情都实现了自动化，你无需再做太多事情，然后就可以在海滩上放松身心了。

但这只是乌托邦。我们还没达到那个境界。我们的目标——也是你们的目标——应该是第二幅图那样的景象。

DevOps理论

所有软件开发生命周期的理论都是这样的：你想把咖啡——或者任何其他种类的热饮——变成利润。

有趣的是中间的那段路程。如何从咖啡生意走向盈利？

目前来看，这简直太神奇了。

读完这篇文章，你就会明白这种魔法是如何运作的。

DevOps 的魔力和优势

好了，那么DevOps的魔力究竟是什么呢？

正如你在这里看到的，软件开发过程并不是一条从A点到Z点的清晰直线。它是一个由六个阶段组成的循环过程。

我们从左上角的“规划”开始。你会收到任务、功能需求，可能对项目的整体方向有所了解，然后就应该开始规划这个项目了。再次强调，规划并非从头到尾一气呵成，而是在开发过程中逐步迭代。有很多优秀的工具和方法可以帮你做到这一点。

接下来是构建阶段。现在我们要开始编写代码了。启动集成开发环境（IDE），实现你在上一阶段规划的功能。在这个阶段，有一些工具可以确保你的代码安全，如果出现任何严重错误，你可以回溯修改。

持续集成是自动部署代码的绝佳方式。因此，持续集成和部署密不可分。我们稍后会详细介绍。请记住，它是部署整个团队代码的绝佳方法。

除此之外，还有一些很棒的平台可以用来部署你的代码。如果你想开发一个 Web 应用程序，并使用运行该应用程序的服务，那么在部署过程中一定要格外注意。

应用程序运行时，您可能需要对其进行监控。服务器是否始终运行？是否出现任何错误？这属于运行阶段。您可以使用一些工具来完成这项工作，或者也可以自行实现一个简单的解决方案。

最后，你需要反馈。你的应用是否实现了预期功能？使用起来是否有趣？当然，所有这些都可以通过缺陷跟踪工具等工具来实现，然后你可以利用这些反馈回到规划阶段。

所有这些步骤都离不开沟通，沟通是其中最重要的部分。你必须与你的团队沟通。最棒的是，你无需离开家就能做到这一点。

上图所示是您可以在软件开发生命周期的各个步骤中使用的一些工具。

别担心，我们不会逐一讨论，但我会给出一些提示，告诉你哪些工具可能是不错的选择。

你可能听说过git、GitHub、Google Drive、Slack等等。有很多选择。

在深入细节之前，还有一件事要问。为什么要费这个劲？为什么要使用更多工具？这样做有什么好处？

好处

一切都从你的代码开始。借助一些工具，团队协作会更加轻松。你们团队的代码质量也会得到提升。

开发所需时间会减少。尤其是在部署方面，这会非常麻烦。你的工作更有条理，知道下一步该做什么，然后直接去做，而不用再苦苦思索如何才能达到某个特定目标。

使用某些方法和工具后，你会发现一些原本根本不可能发现的漏洞。最终，这可能会损害你的利润。

最后但同样重要的是，这样工作更有趣，而且晚上肯定睡得更好。

好了，现在我们来详细讨论一下每个阶段的情况。

沟通

在项目进行过程中，你必须始终保持沟通。

无论是规划、修复漏洞还是监控应用程序，你都应该和你的团队讨论所有这些方面——有时也应该和你的客户讨论。有时甚至应该和你自己讨论……

由于不可能一直待在同一个办公室，所以最好还是有一个工具，让你至少大部分时间都能在线，或者可以查看是否有任何有趣的事情发生。

当然，电子邮件也是一种选择，但肯定还有更好的解决方案。

这就是Slack 的用武之地。本质上，Slack 是一款聊天客户端。您可以下载并安装 Slack，也可以使用网页版客户端。

然后您就可以免费创建自己的工作区，并邀请所有团队成员。

之后，你就拥有了自己的项目小工作区，可以在其中创建不同的频道，用于规划、讨论 bug、随意聊天等等。

此外，Slack 还支持集成多种服务。例如，如果您正在部署应用程序，您可以自动向 Slack 工作区发送消息，让所有人都能看到部署是否成功。这样，您就无需亲自监控部署过程了。

Slack 还提供文件传输和视频通话等更多功能。

我不是收了钱才这么说的（就像我在这里推荐的所有工具一样），但 Slack 确实是一个很棒的工具，可以帮助你进行开发。

您可以完全免费开始使用 Slack。所以我建议您立即访问slack.com并注册您的工作区。

计划

计划的重要性不容低估。它能决定项目的成败，尤其是在你打算在项目管理方法之外额外实现一些功能的情况下。

你听说过瀑布模型或螺旋模型吗？这些模型或多或少已经过时了，但了解软件过去的开发方式仍然很有趣……嗯，有些时候现在仍然适用，但如今肯定有更好的解决方案。

总之，正如您在下方看到的，瀑布模型包含多个步骤。在进行下一步之前，每个步骤都必须完成。

你能想象所有需求都准备就绪，然后就再也不提它们了吗？因为这些需求对每个人来说都应该很清楚。当然，这几乎不可能实现。设计甚至实现也是如此。瀑布模型在现实世界中非常不切实际。

当然，必须要有概念设计稿，最好是包含应用程序所有功能的文档。但指望一切照旧，只会惹来麻烦。如果客户想修改某些内容，或者根本不清楚软件的某个部分应该是什么样子，你该怎么说？“时间到了，我们得从头再来，这又要花一大笔钱？”我敢打赌，你以后再也见不到这位客户了。

螺旋模型无疑更好，而且与目前广泛使用的敏捷流程非常相似。

关键在于迭代。你的项目管理方式就是反复执行每个步骤。当然，先有一个软件的大致概念固然好，但细节会在相应的迭代中讨论和实现。这也是处理变更请求的好方法，无需一切从头再来。

所以如今人们采用类似的方法，即所谓的敏捷开发流程。

以下这段引自维基百科的文字很好地描述了敏捷软件开发。

它提倡适应性规划、渐进式发展、早期交付和持续改进，并鼓励对变化做出快速灵活的反应。

因此，敏捷意味着你能够对某些事件（例如变更请求或错误）做出快速反应。

与瀑布模型中从 A 到 Z 规划整个开发过程不同，你每周或每两周查看一次你的项目。

当然，你心中要有大局，但重要的是要始终关注下一个周期、下一个迭代，或者像Scrum（这里提到的软件开发框架之一）中所说的那样，下一个Sprint。

这些软件开发框架——Scrum 或 Kanban——可以帮助你继续使用敏捷开发流程。那么，让我们来谈谈它们。我们先从 Scrum 开始。

Scrum

这就是 Scrum 框架。别担心，我不会花一个小时讲解每一个细节。这一段旨在概述 Scrum 的运作方式以及它如何改进你的开发周期。

如您所见，最左侧是您的产品待办事项列表。本质上，这里包含了所有任务、所有功能，简而言之，就是您的最终产品应该具备的所有内容。这些任务或功能由所谓的“产品负责人”提出。她会与客户或利益相关者沟通，或者仅仅是出于她对项目的想法。

但你并不想一次性完成所有事情，而是希望循序渐进。这就是冲刺计划的作用。再次强调，一个冲刺就是一次迭代，通常持续一到两周。

在冲刺计划会议（或者更准确地说是冲刺计划日）上，你们会计划下一个冲刺的所有任务。这次会议的成果就是冲刺待办事项列表：你和你的团队承诺在这个迭代周期内完成的所有任务。

理想情况下，你必须确认所有进入待办事项列表的任务，因为你必须完成它们，而且只有你才能估算完成它们所需的时间。至少理论上是这样。但如果你无法按时完成，也不会有什么后果。事情总会发生，问题也会出现，或者估算有误。通常这没什么大不了的。这就是评审、回顾会议和新一轮迭代计划会议存在的意义。

在迭代开发期间，会有每日站会。每日站会应该非常简短。每个团队成员只需简要汇报自己之前的工作内容、目前正在进行的工作以及是否存在任何问题，无需赘述细节。如果存在问题，则在每日站会结束后进行讨论。每日站会的目的仅仅是为了了解当前的开发状态。

每日站会由所谓的Scrum Master主持。Scrum Master 会询问每个人的当前情况，并在必要时分配新任务。如果出现任何问题或团队成员需要支持，Scrum Master 是应该联系的人。

迭代周期结束时会进行评审，这本质上就是用户验收测试。这意味着，你需要向客户、利益相关者或任何有权查看结果的人展示你的成果。希望这些人能够接受你的实现方案。

冲刺结束后，在冲刺回顾会议上，你需要反思哪些方面做得好，哪些方面做得不好。这是提供反馈和提出改进建议的绝佳机会。

就这样！下一轮迭代开始了。

再次强调，这只是一个简短的概述，但应该能让你对这个软件开发框架的工作原理有一个大致的了解。

看板

什么是看板？实际上，看板是一种用于精益生产和准时制生产的调度系统。它由丰田的一位工业工程师开发，旨在提高生产效率。顺便一提，日语单词“看板”的意思是“视觉信号”。通常情况下，开发人员的实际工作是不可见的。使用看板可以将工作可视化，并展示给其他人，确保每个人都了解进度。

看板是由 David Anderson 用看板引入软件开发领域的。

上面展示的就是看板。它是Trello工具的一个例子。看板由列和卡片组成，旨在帮助你的开发团队高效完成任务！卡片代表一项任务，列代表一个类别或该任务的当前状态。

你完全可以将看板与 Scrum 结合使用。正如你所看到的，看板上有三列：待办事项卡片、正在进行的卡片或任务，以及已完成的任务。你还可以添加一个产品待办事项列表列。这样，你就可以把所有产品待办事项都添加到这一列中。然后，在即将到来的迭代周期中，你可以把团队想要完成的任务移到待办事项列。一旦有人从那里领取了任务，它就会被移到正在进行的列，以此类推。你应该明白我的意思了。

Trello 或任何数字看板工具的另一个优点是，您可以为卡片添加更多信息。您可以为卡片添加描述、分配团队成员、添加清单，还可以添加图片或撰写评论。顺便一提，如果您想跟踪应用程序中的任何错误，这非常有用——添加带有描述的屏幕截图，即可开始调试……

这是一个简单但非常高效的项目管理解决方案。当然，还有像Asana、Monday.com、Basecamp等更强大的工具。但像 Trello 这样的看板工具完全可以满足需求。这只是我个人的经验之谈。

建造

现在，真正的工作才刚刚开始。

我不太清楚你用来编写代码的集成开发环境（IDE），选择太多了，我帮不上什么忙。

如果您需要，我推荐使用Visual Studio Code以及一些扩展程序。它绝对是我最喜欢的 .NET、JavaScript 和 TypeScript 项目 IDE。当然，您也可以通过一些扩展程序将其用于 Java 或 Python 项目。

但“构建”部分并非仅仅指代码管理。它更侧重于代码管理。而要做到这一点，你绝对需要源代码控制。那么，源代码控制究竟是什么呢？源代码控制意味着跟踪和管理代码的变更。但它不仅包括你编写的代码，还包括你整个团队的代码。

当你独自开发项目时，你可能会觉得不需要版本控制。你可能会认为备份一些文件就能管理变更，仅此而已。但我强烈建议你使用版本控制，即使你是单枪匹马。当然，如果你是团队合作，那就更应该如此了。

使用源代码控制有很多好处，例如可以查看更改历史记录、合并团队成员的代码更改以及创建功能分支。

让我们以源代码控制系统Git为例来详细说明这一切。

使用 Git 进行源代码控制

对于大多数项目而言，最合适的源代码控制或版本控制系统是 Git。

Git 最初由Linus Torwalds开发，他也是 Linux 内核的创建者。它绝对能帮助你跟踪和管理代码变更，尤其是在团队协作时。

那么，跟踪和管理代码变更究竟意味着什么？

首先，如果你或你的团队成员搞砸了，你可以直接回滚到之前运行正常的版本。以前人们习惯于把文件从一台电脑复制粘贴到另一台电脑，然后祈祷一切顺利。相信我，我经历过。那可不是什么好体验。还记得之前那只受惊的猫吗？

但今天不一样了。今天你们有了一个所谓的代码仓库。团队中的每个人都会将他们的代码更改提交并推送到这个代码仓库。

上面这张截图显示的是一个 Git 客户端，这里叫做Fork。本质上，这里展示的是 Git 仓库。你可以看到完整的提交历史记录。在左侧，你还可以看到我们正在查看的是master 分支——假设它是你代码的主要版本。我们稍后会讨论分支。

当你提交更改，并且你修改的代码与其他人修改的代码没有重复时，Git 会自动将你的代码更改与同事的更改合并。是不是很棒？甚至不需要修改不同的文件。假设你和同事在同一个文件上编辑不同的函数，Git 也能自动合并你们的更改。再也不用复制粘贴了。（如果你是新手，这可能会彻底改变你的工作方式！）

但是，如果您和一个或多个队友对同一段代码进行了修改，那么可能会出现合并冲突。

这意味着你想要修改的代码行已经存在已提交的更改。从截图中可以看到，Git 不知道应该选择哪个版本的代码。是他们的版本还是我们的版本？

在这种情况下，您需要自行解决冲突。您可以选择支持一方，也可以选择支持双方，或者在编辑器中手动快速修复冲突。此外，还有一些工具可以帮助您解决冲突。

例如，大多数集成开发环境（IDE）已经能够做到这一点。所以，Visual Studio Code 本身可能就是一个工具。其他专门为 Git 设计的工具包括TortoiseGit和GitKraken。您可能也已经见过Fork和SourceTree。大多数 Git 客户端都是免费的，或者至少提供免费试用版。

如果你不太喜欢带有图形用户界面的客户端，你也可以选择使用 Git bash、终端或命令提示符——具体取决于你的操作系统。

但要实现这一点，首先您需要为您的操作系统下载 Git 。

下载 Git 后，您可以在自己的计算机或服务器上创建存储库，或者使用在线免费服务之一，然后将在线创建的存储库克隆到本地计算机。

克隆是指下载代码仓库，这样你的更改就会被跟踪，以便你可以再次提交并推送（即上传）这些更改。我们将在持续集成部分讨论这些在线服务。

无论你选择哪种方案，每个团队成员都可以使用这个代码仓库并向其中推送更改。这是一个非常棒的集中式解决方案。

但这还不是全部。Git 的另一个优点是能够创建分支。

那么，什么是分支（​​有时也称为特性分支）呢？

您可以获取当前代码库并创建当前状态的副本。然后对代码进行更改，并将更改推送到副本，而无需触及副本代码库（通常称为主分支）。

同样，您可以复制主分支，然后在不触及主分支的情况下修改代码。如果您想创建一个新功能并推送该功能的更改，而又不想破坏现有的代码库，这种方法非常有用。这样，您的代码就安全地保存在代码仓库中，而不是随意地躺在您的硬盘上。

你看到截图中那些彩色线条了吗？这些是不同的分支。Hero_images这些google_verification功能是在各自的分支上开发的，经过测试成功后，它们被合并回主分支，你的修改也成为了主代码库的一部分。

如果你不那样做，可能会发生以下情况。

这些图片取自《刺猬索尼克》电影的预告片。派拉蒙发布了这部电影的预告片，但社区对此并不满意。可以说，第一个版本直接在主分支上修改了代码，而没有经过审查或测试。

第二个版本使用的是经过测试并合并到主分支的特性分支。这样好多了，你不觉得吗？

容器

我还要提一下Docker或容器技术。

让我们来看一下维基百科上的这段引文：

Docker 可以将应用程序及其依赖项打包到一个虚拟容器中，该容器可以运行在任何 Linux 服务器上。这有助于提高灵活性和可移植性，使应用程序能够在各种位置运行，无论是在本地、公有云还是私有云。Docker 允许容器在单个 Linux 实例中运行，从而避免启动和维护虚拟机的开销。

简单来说，使用 Docker，你可以启动一个虚拟机，它会获取运行应用程序所需的一切（库等等），然后直接运行它。这样，每次修改后你都可以快速测试应用程序，确保它不仅能在你的机器上运行，也能在全新的系统上运行。或许你最终会想了解一下 Docker。它可能会进一步提高你的工作效率。

好了，构建部分就到这里。接下来我们进入持续集成部分。

持续集成

持续集成非常重要，而且确实很有用。但它究竟是什么呢？

我认为GitLab上的这句话描述得非常贴切。

持续集成是指将代码集成到共享存储库中，并尽可能早地自动构建/测试每个更改（通常每天多次）。

我们在源代码控制部分已经稍微提到过这一点。你和你的团队成员每天在项目上工作时，可能需要多次提交并推送对代码库的更改。

如果没有代码仓库和持续集成，你就必须手动合并整个代码——而且一天要合并好几次。这会非常耗时。所以你宁愿每天、每周甚至每月只合并一次代码。但这会导致很多问题，或者至少会带来一些烦人的任务。

有了持续集成和源代码控制，这些都已成为历史。

你有了自己的代码仓库，提交了代码，就不用再操心这些管理工作了。

这张图展示了软件开发的常规流程。GitLab 的引述中提到了测试——更准确地说，是自动化测试。

你构建好应用程序后，推送更改，系统将运行自动化测试，如果测试成功，你的应用程序将被部署到你的服务器、云端等等。

自动化测试

这些自动化测试是什么？简单介绍一下。

最广为人知的是单元测试和集成测试——以及测试驱动开发，但这又是另一种开发实践了。

以单元测试为例。顾名思义，单元测试用于测试单个单元的功能。想象一下，你有一个计算器，只想测试加法或减法功能是否正常。那么，你就只需要为这部分功能编写测试。

完成这些测试后，您可能需要测试所有这些单元是否也能协同工作。是否可以在一次计算中同时进行加减运算？这属于集成测试。

另一个例子是为后端代码编写单元测试，但也要编写集成测试，以检查前端是否能与后端正确协同工作。

如果你只使用单元测试而忽略集成测试，就会出现这样的情况：

你看，滑动门和旋转式购物门本身都运行良好，但结合起来就不行。显然有人忘了做集成测试……

和往常一样，有很多测试框架可供使用。上面展示的是微软测试框架的示例。在 Visual Studio 中，你可以看到哪些测试失败了，哪些测试成功了。如果某个测试失败，你还可以深入分析，找出问题所在。是单元测试的实现有问题，还是你编写的测试本身有问题？

如果你熟悉 Java，你会发现 JUnit 和 Eclipse 的界面非常相似。左侧显示测试结果，右侧显示详细信息或实现细节。你还可以看到，测试实现都有各自的注解。因此，编写测试以及如何使用特定的测试框架都有其特定的规则。

无论你用什么语言编写软件，都会有相应的测试框架。随便找找就知道了。例如，前端的 Angular 就已经有自己的测试文件了。

好了，我们的小测试就到此为止。它们非常适合持续集成流程，但你并非必须使用它们。记住，持续集成的核心理念是：你编写代码，将其推送到源代码控制仓库，然后你的应用程序会在服务器上构建或编译，接着运行测试，所有测试通过后，你的应用程序就会被部署。

持续集成服务

您可以使用多种持续集成服务。有些服务功能更强大，有些则功能较弱。例如，Jenkins是领先的自动化服务器之一。但就您的情况而言，其他解决方案可能更合适。

以我的经验来看，Jenkins和Hudson在持续集成方面表现出色，而且可以通过扩展程序添加更多功能。但也有其他平台提供完整的 DevOps 解决方案。

GitLab、Bitbucket或Azure DevOps（甚至直接使用了 DevOps 这个术语）都力求成为一体化解决方案——以我的经验来看，它们确实做到了。你不仅能获得持续集成，还能获得代码仓库、问题看板、工单系统、部署方案、通知功能、与其他工具的大量集成选项等等。

别误会我的意思。其他服务也能做到这一点，但你可能需要花更多时间进行设置。

最终，选择哪种服务、工具或平台取决于您自己。最好的办法当然是亲自试用，找到您最喜欢且最符合您需求的那一款。

持续集成配置

但让我们以 GitLab 为例，看看如何实现持续集成。

首先你需要一个配置文件。对于 GitLab 来说，它是一个名为.gitlab-ci.yml的 yml 文件。

您可以看到它被放在了项目的根目录中。

这个 yml 文件包含一个脚本。您可以定义阶段，然后为每个阶段添加命令，或者添加在特定阶段之前或之后执行的命令。

在这些示例中，您可以看到 .NET Core 后端和 Angular 前端的部署脚本。

本质上，你只需输入在本地开发机器上构建应用程序时运行的命令。然后添加发布已编译应用程序的命令即可。

例如，在 .NET Core 项目中，我们运行dotnet build命令dotnet publish来发布调试版本和发布版本。对于 Angular，我们调用命令npm install来安装所有依赖项，然后ng build使用特定配置运行。后端服务和 Angular 前端这两个应用程序都部署在 Windows 服务器上的 Internet 信息服务 (IIS) 中。

这样做的一个绝妙优势在于，每次编写代码都如同第一次编写一样。理想情况下，即使出现错误，你也不会再听到“但它在我的机器上运行正常”这种说法了。

如前所述，可以将 GitLab 等 DevOps 平台与其他工具（例如 Slack）集成。代码推送或构建部署过程完成后，系统会向 Slack 频道发送消息，其中包含提交消息和部署结果。

从那里我可以点击“比较更改”或部署流程的管道编号。

“比较更改”会将我带到实际的提交页面，在那里我可以比较代码更改。在这个例子中，您可以看到已更改的文件，以及与先前版本的所有差异，例如第 290 行添加的条件。

点击管道会跳转到 yml 脚本的运行结果页面。您可以看到类似dotnet publish这样的命令及其执行结果。如果出现任何错误，您会在这里看到具体的错误信息，并可能获得一些修复提示。如果一切顺利，您会看到相应的Job succeeded语句。

这就是持续集成的工作原理。代码会被集成到一个共享代码库中，每天自动构建和测试数次。

我们甚至可以更进一步，实现持续部署或交付。

持续交付还补充说，软件可以随时发布到生产环境，通常是通过自动将更改推送到暂存系统来实现的。

持续部署更进一步，可自动将更改推送到生产环境。

本质上，这意味着您不仅需要构建和测试代码，还需要将其部署到正在运行的生产服务器上。无需手动将测试或预发布版本迁移到生产服务器。DevOps可以自动完成所有这些操作。

还记得沙滩上的那只猫吗？我们就是按那种方式到达目的地的。

部署

我们在讲解持续集成时已经讨论过部署问题了。

部署是将你的代码移动到服务器或平台上，供人们实际使用的过程。

有几种方法可以实现这一点。您可以租用自己的专用服务器、虚拟机，或者使用众多可用的平台之一，例如Microsoft Azure、Amazon Web Services或Google Cloud。

这三者的最大优势在于，您无需自行托管和配置服务器。您只需为实际需要的功能付费。您的 Web 应用程序需要数据库和少量网页空间？没问题，只需添加这些功能，确定所需的内存和处理器，一切就搞定了。

这些平台的另一个优点是可扩展性。如果您只需要在短时间内提升性能，可以只添加内存或其他资源。如果您的应用程序或用户数量增长，您也可以进行长期扩展。

当您不得不依赖自己管理的服务器时，您可能需要额外购买另一台服务器，甚至需要完全迁移您的应用程序。

GitLab和Bitbucket提供了出色的 DevOps 解决方案，但您可能需要自己购置服务器，并将应用程序部署到该服务器上。

当然，像Microsoft Azure这样的服务是需要付费的。不过，也有免费的选项。在这种情况下，您可以免费试用该服务 12 个月。您可以测试应用程序并将其部署到虚拟机，例如使用 SQL 数据库。移动应用程序也完全不成问题。此外，借助 Azure 等服务，您还可以从用户数据中获取洞察，并根据这些数据改进应用程序和用户体验，这是其另一大优势。

亚马逊云服务 (AWS)与此非常相似。它也提供免费选项，但这些选项分为不同的层级。有些服务永久免费，有些可以免费试用 12 个月，还有一些的试用期较短，例如 30 天。不过，您可以根据自己的需要选择合适的服务。

谷歌云平台采用了不同的方法。它提供 300 美元的预算，你可以用它来构建和访问任何你想要的东西。更棒的是，你还可以使用谷歌的专属服务和 API，例如 Firebase 或谷歌地图 API。

我觉得这一点真的很好，也很人性化，免费试用期结束后不会自动收取任何费用。你需要先自行升级到付费套餐。

BitBucket 和 GitLab 的界面略有不同。它们也提供免费套餐，我认为对于新手来说，大多数情况下这些套餐完全够用。

Bitbucket采用典型的定价模式。小型团队可以免费使用某些功能。如果团队规模扩大或需要更多功能，则需要升级到付费套餐。

我认为免费套餐就能提供无限量的私有仓库、Trello 集成和持续集成功能，这非常棒。

GitLab也非常类似。免费版就提供无限数量的代码仓库和持续集成，而且我记得它还提供多种集成选项。看起来它不受团队规模的限制。

付费套餐可以提供越来越多的功能。

最终决定权在你。你需要什么？我建议你比较一下不同的服务，可以先从免费套餐开始，甚至可以先选择功能有限的服务熟悉一下，然后再根据自身需求升级到更高级的套餐，尤其是在你更熟悉这些平台和服务提供的各种功能之后。

操作

DevOps流程的下一阶段是运维。换句话说，就是监控服务器，记录信息和发生的错误，并在必要时发送通知。

同样，有很多服务可以帮助您完成所有这些工作。Nagios 、Loggly、Dynatrace和Splunk都是您可以了解一下的服务。

Nagios 的核心功能是监控。它可以监控您的 Windows 或 Linux 系统、任何类型的服务器、您的应用程序等等，并将所有这些监控结果记录下来。

当然，我们还提供免费试用。

以下是使用 Nagios 的一种可能工作方式。

左侧显示的是您的对象，通常是各种类型的服务器。Nagios 可以检查所有设备是否正常运行，并按预期工作。此外，它还可以跟踪性能数据。

然后是右侧的状态栏。这意味着 Nagios 可以随时随地向您发送通知。例如，如果发生错误，您可以指示 Nagios 发送电子邮件、短信，或者将其记录到数据库或 Web 应用程序中，以便您自行检查这些错误。

其实就是这样。再说一遍，一切都是自动完成的，您无需一直亲自监控服务器。

Dynatrace 采取了不同的策略。他们以人工智能驱动的一体化平台来推广其服务。他们不仅监控和提供数据，还希望提供数据解读和“答案”。您也可以点击此处免费试用。

但对我来说，最关键的问题是：你真的需要这样的服务吗？这类监控主要适用于中大型企业。大多数情况下，你可以尝试自己进行一些日志记录和发送通知，但同样可以实现自动化。

为什么不自己编写后端日志服务呢？您可以将任何想要的信息写入数据库甚至文本文件，如果发生任何错误或抛出异常，只需向自己或开发团队发送电子邮件，其中包含日期和时间、触发错误的用户以及请求数据等信息即可。

然后您可以深入查看日志，尝试重现错误，修复错误，就完成了。

不妨考虑一下？

反馈

随着反馈阶段的到来，DevOps 循环正逐渐接近尾声。

反馈方式多种多样。我们有自动化状态更新、IT服务管理（ITSM）、客户关系管理（CRM）和缺陷跟踪。

简而言之，ITSM更侧重于IT部门的反馈，而CRM则侧重于客户。问题跟踪可以作为IT服务管理的一部分。但我们先来看看其中的一些服务。

我们提供IT服务管理、客户关系管理和问题跟踪的服务和平台。

有些服务更侧重于客户关系管理。这意味着它们专注于存储客户信息、提供反馈，并最终有望提升利润。因为当您能够追踪客户信息并给予恰当的反馈时，您的客户可能会更满意，购买频率更高，并且更愿意推荐您的服务。

但我更想专注于IT服务管理，更准确地说，是问题或缺陷跟踪。Mantis 、Bugzilla、Jira和Trello都是提供创建工单和缺陷报告功能的Web应用程序。Mantis和Bugzilla更侧重于缺陷跟踪。

Mantis 这类问题跟踪器的目的是让用户可以向跟踪器添加问题描述。这样，一旦出现错误，您或您的应用程序测试人员就可以添加一个新问题，其中包含标题、问题描述以及可能造成的后果。例如，应用程序是否崩溃？这个错误是否导致了奇怪的 UI 行为？或者还有其他什么问题？

使用 Mantis 或 Bugzilla，您可以拥有一个跟踪器，使您的整个团队能够协作并查看应用程序中的所有错误。

和大多数服务一样，你可以开始免费试用，甚至可以先睹为快。因为 Mantis 的官方追踪器本身就是对所有人开放的。

如您所见，我们列出了多个问题。部分问题尚未分配，部分问题已解决。您可以查看问题的创建、编辑或评论时间线，也可以查看所有问题的详细信息。

然后您会看到每个问题的严重性、状态或类别等属性。当然，您还会看到上次更新日期以及该问题的概要描述。

这样一来，您就能更好地整理 bug，从而改进软件。此外，启用通知功能后，您的团队就能随时了解最新动态。

例如，如果团队成员修复了一个 bug，该 bug 的报告者会收到通知并立即测试修复。因为得益于持续集成和交付，修复后的代码已经发布并部署到测试系统中，对吧？太棒了！

Jira 只是这类软件的又一个例子。但 Mantis 只专注于 bug 报告，而 Jira 通常也用于功能请求或任何类型的工单。不过，它们的核心功能是相同的：创建工单、跟踪工单、更新工单、完成工单以及发送通知。

GitLab 也提供问题跟踪功能。您可以自行决定是以列表形式还是看板形式查看工单或问题。您还可以添加类别、严重程度、不同颜色等等。这看起来与 Trello 非常相似。

那么，Trello 在哪里出现呢？在规划阶段，也就是我们 DevOps 流程的最初阶段。像 Mantis 这样的问题跟踪工具看起来可能不一样，但实际上，你完全可以使用你用来规划开发生命周期的软件来跟踪问题。

如果你使用的是像 GitLab 这样的 DevOps 解决方案平台，你甚至不需要额外的工具。

你明白我的意思吗？我们又回到了原点。给予和提供反馈最终会帮助你规划下一次迭代。

是时候总结一下了。

概括

现在我们又回到了原点。我们从规划到构建，再到持续集成和部署，然后进入了DevOps的运维阶段，也就是运维和反馈阶段。基于这些反馈，我们能够规划下一步的开发。所有这一切都建立在实时沟通之上。

你已经见过很多可以帮助你完成 DevOps 各个阶段的工具。最终选择哪个完全取决于你。你可以为每个步骤选择一个工具，自己完成诸如记录异常和向团队发送电子邮件之类的工作，也可以选择一个大型 DevOps 平台，用一个服务完成所有操作。

记住，一定要在软件开发生命周期中贯彻DevOps理念。你肯定不想一开始就显得像只受惊的猫吧？

尝试不同的工具，然后找到最适合你的方法。市面上有很多解决方案，我认为每个团队、每家公司、每种你想开发的软件都能找到合适的方法。

希望你有所收获，并获得一些新的见解。如有任何疑问，欢迎随时提问！

下次见，保重。

题图：Romolo Tavani/Shutterstock.com

等等，还有更多！

• 免费获取完整版及最新版DevOps在线课程。
• 让我们在Twitter、YouTube、LinkedIn或dev.to上联系吧。
• 在patrickgod.com上阅读更多对您的开发者生活和职业生涯有价值的文章。