该报告将从开发人员的角度讨论一些 DevOps 实践。 通常，所有加入 DevOps 的工程师都已经拥有多年的管理经验。 但这并不意味着这里没有开发商的立足之地。 通常，开发人员正忙于修复“当天的下一个紧急关键错误”，他们甚至没有时间快速浏览 DevOps 领域。 在笔者的理解中，DevOps首先是常识。 其次，这是一个提高效率的机会。 如果您是一名开发人员，具有常识并希望提高团队合作效率，那么这份报告适合您。
让我自我介绍一下，我完全承认房间里有人不认识我。 我叫 Anton Boyko，是 Microsoft Azure MVP。 什么是MVP？ 这是模型-视图-呈现器。 模型-视图-演示者正是我。
此外，我目前在 Ciklum 担任解决方案架构师。 就在最近，我给自己买了一个如此漂亮的域名，并更新了我的电子邮件，我通常在演示中展示它。 您可以写信给我：me [dog] byokoant.pro。 您可以给我发电子邮件询问问题。 我通常会回答他们。 唯一的问题是，我不想通过电子邮件收到涉及两个主题的问题：政治和宗教。 您可以通过电子邮件给我写信了解其他事宜。 过一段时间，我会回答。
关于我自己的几句话：
- 我在这个领域已经工作了 10 年了。
- 我在微软工作过。
- 我是乌克兰 Azure 社区的创始人，我们于 2014 年在某个地方创立了该社区。 我们仍然拥有它并且正在开发它。
- 我也是我们在乌克兰主办的 Azure 会议创始人的父亲。
- 我还帮助组织基辅的全球 Azure 训练营。
- 正如我所说，我是 Microsoft Azure MVP。
- 我经常在会议上发言。 我真的很喜欢在会议上发言。 在过去的一年里，我表演了大约40次。 如果您经过乌克兰、白俄罗斯、波兰、保加利亚、瑞典、丹麦、荷兰、西班牙或欧洲其他国家，那么当您参加一个以云为主题的会议时，很可能你可能会在发言者名单上看到我。
- 我也是星际迷航迷。
我们来谈谈议程。 我们的议程非常简单：
- 我们将讨论什么是 DevOps。 让我们谈谈为什么这很重要。 以前，DevOps 是你写在简历上的一个关键词，立刻就收到了 +500 美元的薪水。 例如，现在你需要在简历中写下区块链，才能获得+500美元的薪水。
- 然后，当我们稍微了解这是什么时，我们将讨论 DevOps 实践是什么。 但并不是一般的 DevOps 背景，而是开发人员可能感兴趣的那些 DevOps 实践。 我会告诉你为什么你可能会对它们感兴趣。 我将告诉您为什么应该这样做以及它如何帮助您减轻疼痛。
许多人展示的传统图片。 这就是许多项目中发生的情况。 这时我们就有开发和运营部门来支持我们的软件。 而且这些部门之间互不沟通。
也许，如果你在DevOps和运营部门感受不那么清楚，你可以与Dev和QA部门进行类比。 从开发人员的角度来看，有些人开发软件，有些人则很糟糕。 例如，我将我精彩的代码提交到存储库，然后有一些无赖坐在那里，将这段代码返回给我并说你的代码很糟糕。
这一切的发生都是因为人们彼此之间不沟通。 他们通过一些误解向对方扔出一些包裹、一些应用程序，并尝试用它们做点什么。
DevOps 文化正是旨在摧毁这堵墙，即迫使人们相互沟通，至少了解项目中不同人员的工作以及他们的工作为何重要。
当我们谈论DevOps时，有人会告诉你DevOps是当项目有持续集成时； 有人会说DevOps就是项目实现了“基础设施即代码”的实践； 有人会说 DevOps 的第一步是功能分支、功能标志。
本质上，这一切都以它自己的方式是正确的。 但这些只是我们的最终实践。 在继续这些实践之前，我建议先看一下这张幻灯片，它显示了在您的公司项目中实施 Dev-Ops 方法的 3 个阶段。
这张幻灯片还有第二个非官方名称。 你可以上网搜索一下DevOps的三剑客是什么。 您可能会找到这篇文章。 为什么是3火枪手？ 下面写着：人员、流程和产品，即PPP – 波托斯、波托斯和波托斯。 这是 DevOps 的 3 个火枪手。 本文更详细地描述了为什么这一点很重要以及它的含义。
当您开始实施 DevOps 文化时，按以下顺序实施非常重要。
最初你需要与人交谈。 你需要向人们解释它是什么以及他们如何从中获得一些好处。
我们的会议称为 DotNet Fest。 而且正如主办方告诉我的，我们这里主要邀请的是开发者观众，所以我希望在场的大部分人都参与开发。
我们会谈论人，我们会谈论开发人员每天想要做什么。 他们最想要什么？ 他们想要编写一些新代码，使用新奇的框架，创建新功能。 开发者最不想要什么？ 修复旧错误。 我希望你同意我的观点。 这正是开发商想要的。 他们想要编写新功能，而不是修复错误。
特定开发人员产生的错误数量取决于他的手臂有多直以及它们从他的肩膀而不是从他的屁股口袋长出的程度。 但是，尽管如此，当我们有一个大型项目时，有时不可能跟踪所有内容，因此我们最好使用一些方法来帮助我们编写更稳定和更高质量的代码。
QA 最想要什么？ 不知道他们是否在大厅里。 我很难说我想要 QA，因为我从来没有做过。 无意冒犯这些家伙，有人会说我希望我永远不会。 但并不是因为我认为他们的工作毫无意义、无用，而是因为我不认为自己是一个能够高效地完成这项工作的人，所以我什至不会尝试去做。 但据我了解，QA 最不喜欢的是早上工作，不断运行某种回归测试，踩在 3 个冲刺前向开发人员报告的相同错误上，并说：“你什么时候才能，达达尼昂先生，修复这个错误。 达达尼昂先生回答他：“是的，是的，是的，我已经修好了。” 以及我是如何修复了 5 个错误并一路完成 XNUMX 个错误的。
在生产中支持该解决方案的人们希望该解决方案能够无错误地运行，这样他们就不必在每个星期五所有普通人都去酒吧时重新启动服务器。 开发人员在周五进行了部署，管理员则一直等到周六，试图启动并修复此部署。
当您向人们解释他们的目标是解决相同的问题时，您可以继续将流程正式化。 这是非常重要的。 为什么？ 因为当我们说“形式化”时，至少在餐巾纸上的某个地方描述您的流程是如何发生的对您来说很重要。 您需要了解，例如，如果您部署到 QA 环境或生产环境，那么它总是按此顺序发生；在这些阶段，我们运行自动单元测试和 UI 测试等。 部署完成后，我们检查部署是否顺利。 但您已经有了一份清晰的操作列表，在部署到生产环境时必须一遍又一遍地重复这些操作。
只有当您的流程正式化后，您才开始选择能够帮助您自动化这些流程的产品。
不幸的是，我经常看到这种情况相反发生。 有人一听到“DevOps”这个词，立马建议安装Jenkins，因为他们相信，只要安装了Jenkins，就拥有了DevOps。 他们安装了 Jenkins，阅读了 Jenkins 网站上的“How to”文章，试图将流程塞进这些 How to 文章中，然后来到人们面前，让人们弯腰，说书上说你需要这样做，所以我们就这样做。
这并不是说 Jenkins 是一个糟糕的工具。 我无意以任何方式这么说。 但这只是其中一种产品。 您使用哪种产品应该是您的最后决定，而不是您的第一个决定。 你的产品不应该由文化和方法的实施来驱动。 理解这一点非常重要，这就是为什么我在这张幻灯片上花了这么多时间并解释了这么长时间的所有内容。
我们来谈谈一般的 DevOps 实践。 这些是什么？ 有什么不同？ 如何试穿它们？ 为什么它们很重要？
您可能听说过的第一个实践称为持续集成。 也许该项目中的某个人具有持续集成（CI）。
最大的问题是，最常当我问一个人：“你的项目有 CI 吗？” 他说：“是的”，然后当我问他做什么时，他向我描述了整个自动化过程。 这并不完全正确。
事实上，CI的实践只是为了将不同人编写的代码集成到某种单一的代码库中。 就这样。
除了 CI 之外，通常还有其他实践 - 例如持续部署、发布管理，但我们稍后会讨论。
CI本身告诉我们，不同的人编写代码，并且这些代码必须不断集成到单个代码库中。
这给我们带来了什么以及为什么它很重要？ 如果我们有DotNet，那就很好，它是一种编译语言，我们可以编译我们的应用程序。 如果它能够编译，那么这已经是一个好兆头了。 这还没有任何意义，但这是我们至少可以编译的第一个好兆头。
然后我们可以运行一些测试，这也是一个单独的实践。 测试全部都是绿色的——这是第二个好兆头。 但话又说回来，这并不意味着什么。
但你为什么要这样做呢？ 我今天要讨论的所有实践都具有大致相同的价值，即大致相同的收益，并且也以大致相同的方式进行衡量。
首先，它可以让您加快交货速度。 这如何帮助您加快交货速度？ 当我们对代码库进行一些新的更改时，我们可以立即尝试使用此代码执行某些操作。 我们不会等到星期四到来，因为星期四我们将其发布到 QA 环境，我们就在这里就在这里进行。
我会告诉你我一生中的一个悲伤的故事。 那是很久以前的事了，那时我还年轻、英俊。 现在的我已经年轻、美丽、聪明、谦虚。 前段时间我在做一个项目。 我们有一个由大约 30 名开发人员组成的庞大团队。 我们有一个非常非常大的企业项目，开发了大约 10 年。 我们有不同的分支机构。 在存储库中，我们有一个供开发人员行走的分支。 还有一个分支显示了生产中的代码版本。
生产分支比可供开发人员使用的分支晚了 3 个月。 这是什么意思？ 这意味着，一旦我在某个地方出现了由于开发人员的错误（因为他们允许）而进入生产的错误，并且由于 QA 的错误（因为他们查看了它），那么这意味着如果我收到生产修补程序的任务，那么我必须回滚 3 个月前的代码更改。 我必须记住三个月前发生的事情并尝试解决它。
如果您还没有这种经验，您可以在您的家庭项目中尝试一下。 最重要的是，不要在商业上尝试。 编写几行代码，六个月内忘记它们，然后回来尝试快速解释这些代码行的含义以及如何修复或优化它们。 这是一次非常非常令人兴奋的经历。
如果我们有持续集成实践，那么一旦我编写了代码，我们就可以立即使用许多自动化工具进行检查。 这可能无法让我了解全部情况，但无论如何，它将至少消除一些风险。 如果有任何潜在的错误，我会立即知道，也就是说，实际上在几分钟内。 我不需要回滚3个月。 我只需要回滚 2 分钟。 一台好的咖啡机甚至没有时间在 2 分钟内冲泡咖啡，所以这很酷。
这具有可以在每个项目上一次又一次重复的价值，即不仅仅是您设置的那个。 您可以重复实践本身，并且对于您对项目所做的每个新更改，CI 本身都会重复。 这使您可以优化资源，因为您的团队工作效率更高。 您将不再遇到 3 个月前使用的代码出现错误的情况。 当你坐下来花前两个小时试图理解当时发生的事情并在开始纠正某些内容之前了解上下文的本质时，你将不再需要上下文切换。
我们如何衡量这种做法的成功或失败？ 如果你向大老板报告我们在 CI 项目上实施的情况，他会听到等等等等。 我们实施了它，好吧，但是为什么，它给我们带来了什么，我们如何衡量它，我们实施它的正确或错误程度如何？
首先，得益于 CI，我们可以越来越频繁地进行部署，而且更频繁地部署正是因为我们的代码可能更加稳定。 同样，我们发现错误的时间减少了，纠正错误的时间也减少了，正是因为我们此时此刻从系统收到了答案，我们的代码出了什么问题。
我们的另一个实践是自动化测试实践，它通常与 CI 实践一起出现。 他们齐头并进。
这里需要理解什么是重要的？ 重要的是要了解我们的测试是不同的。 每个自动化测试都是为了解决自己的问题。 例如，我们有单元测试，允许我们单独测试模块，即它如何在真空中工作？ 这很好。
我们还有集成测试，使我们能够了解不同模块如何相互集成。 这也不错。
我们可能有 UI 自动化测试，使我们能够检查 UI 的工作满足客户设定的某些要求的程度等。
您运行的特定测试可能会影响您运行它们的频率。 单元测试通常写得又短又小。 并且它们可以定期启动。
如果我们谈论的是 UI 自动化测试，那么如果您的项目很小，那就很好。 您的 UI 自动化测试可能需要一些足够的时间。 但在大型项目中，UI 自动化测试通常需要花费几个小时。 如果是几个小时就好了。 唯一的问题是，为每个构建运行它们是没有意义的。 在晚上运行它们是有意义的。 当每个人早上上班时：无论是测试人员还是开发人员，他们都会收到某种报告，表明我们在晚上运行了 UI 自动测试并得到了这些结果。 在这里，检查您的产品是否满足某些要求的服务器的一个小时的工作将比同一个 QA 工程师的一个小时的工作便宜得多，即使他是一个为食物和感谢而工作的初级 QA 工程师。 尽管如此，机器运行一小时会更便宜。 这就是为什么投资它是有意义的。
我还有另一个项目正在做。 我们对该项目进行了为期两周的冲刺。 这个项目很大，对金融部门很重要，不能出错。 经过两周的冲刺后，开发周期之后是测试过程，又花了 4 周时间。 试着想象一下这场悲剧的规模。 我们编写代码两周，然后像 CodeFreeze 一样进行，将其打包到应用程序的新版本中，并将其推出给测试人员。 测试人员又测试了 4 周，即在他们测试的同时，我们还有时间为他们准备两个版本。 这是一个非常悲伤的案例。
我们告诉他们，如果您想提高工作效率，那么实施自动化测试实践是有意义的，因为这正是此时此地对您造成伤害的原因。
实践持续部署。 太棒了，你已经完成构建了。 这已经很好了。 您的代码已编译。 现在，在某些环境中部署此版本会很好。 假设在开发人员的环境中。
它为什么如此重要？ 首先，您可以查看部署过程本身的成功程度。 我遇到过这样的项目，当我问：“如何部署应用程序的新版本？”时，他们告诉我：“我们将其组装并打包到 zip 存档中。 我们通过邮件将其发送给管理员。 管理员下载并扩展此存档。 整个办公室都开始祈祷服务器能够接受新版本。”
让我们从简单的事情开始。 例如，他们忘记将 CSS 放入存档中或忘记更改 java 脚本文件名中的主题标签。 当我们向服务器发出请求时，浏览器认为它已经有了这个java脚本文件并决定不下载它。 而且有一个旧版本，缺少一些东西。 一般来说，可能会出现很多问题。 因此，持续部署的实践至少可以让您测试一下如果您获取干净的参考映像并将其上传到完全干净的新环境中会发生什么。 你可以看到这会导致什么结果。
此外，当您在彼此之间集成代码时，即在命令之间，这还允许您查看它在 UI 上的外观。
使用大量普通 java 脚本时出现的问题之一是两个开发人员鲁莽地在 window 对象中声明了一个同名的变量。 然后就看你的运气了。 谁的java脚本文件被第二个拉出，就会覆盖另一个的更改。 这也非常令人兴奋。 你进来：一件事对一个人有用，另一件事对另一个人不起作用。 当这一切投入生产时，那真是“太棒了”。
我们的下一个实践是自动恢复的实践，即回滚到应用程序的先前版本。
为什么这对开发人员很重要？ 仍然有人记得遥远的 90 年代，当时计算机很大，程序很小。 Web 开发的唯一方法是通过 PHP。 这并不是说 PHP 是一种糟糕的语言，尽管它确实如此。
但问题是不同的。 当我们部署新版本的 php 站点时，我们是如何部署的？ 大多数情况下，我们会打开 Far Manager 或其他东西。 并将这些文件上传到FTP。 然后我们突然意识到我们有一些很小很小的bug，例如我们忘记加分号或者忘记更改数据库的密码，而数据库有一个密码，它在本地主机上。 我们决定快速连接到 FTP 并在那里编辑文件。 这简直就是火啊！ 这是90年代流行的。
但是，如果你没有看日历，90 年代已经快 30 年前了。 现在一切都发生了一点不同。 当他们告诉您：“我们部署到生产环境，但那里出了问题。”时，请尝试想象一下悲剧的规模。 这是您的 FTP 登录名和密码，连接到生产环境并快速修复它。” 如果你是查克·诺里斯，这会起作用。 如果没有，那么你就有可能修复一个错误，你就会再犯 10 个错误。这正是为什么回滚到以前版本的做法可以让你取得很多成就的原因。
即使某些不好的东西以某种方式进入了某个地方，那么它是坏的，但不是致命的。 您可以回滚到之前的版本。 如果用这个术语更容易理解的话，可以将其称为备份。 您可以回滚到之前的版本，用户仍然可以使用您的产品，并且您将有足够的缓冲时间。 您可以冷静地、不慌不忙地把所有这些都放在本地进行测试、修复，然后上传新版本。 这样做确实很有意义。
现在让我们尝试以某种方式将前面的两种实践结合在一起。 我们将获得第三个称为发布管理的工具。
当我们谈论经典形式的持续部署时，我们说我们必须从存储库的某个分支中提取代码，编译并部署它。 如果我们有同样的环境就好了。 如果我们有多个环境，这意味着我们每次都必须提取代码，即使是从同一个提交中提取代码。 我们每次都会将其拉出，每次都会构建它，并将其部署到新环境。 首先，这是时间，因为要构建一个项目，如果你有一个很大的项目并且来自90后，那么可能需要几个小时。
除此之外，还有另一种悲伤。 当您构建时，即使在同一台机器上，您也将构建相同的源，但您仍然无法保证该机器处于与上次构建期间相同的状态。
假设有人进来并为您更新了 DotNet，或者相反，有人决定删除某些内容。 然后你就会产生认知失调，从两周前的这次提交开始，我们正在构建一个版本，一切都很好，但现在看起来就像我们试图构建的同一台机器，相同的提交，相同的代码，但它不起作用。 你会在很长一段时间内处理这个问题，但事实上你并不会弄清楚。 至少，你的神经会非常紧张。
因此，发布管理实践建议引入一个额外的抽象，称为工件存储库或库或库。 你可以随意称呼它。
主要思想是，一旦我们在那里进行了某种提交，比如说，在我们准备部署到不同环境的分支中，我们就会从此提交中收集应用程序以及该应用程序所需的所有内容，然后将其打包到 zip 存档并将其保存在一些可靠的存储中。 我们可以随时从该存储中获取该 zip 存档。
然后我们将其自动部署到开发环境中。 我们在那里比赛，如果一切顺利，我们就会部署到舞台上。 如果一切顺利，那么我们将相同的存档部署到生产环境，相同的二进制文件，只编译一次。
此外，当我们拥有这样的图库时，它还可以帮助我们解决上一张幻灯片中我们讨论回滚到以前版本时所解决的风险。 如果您不小心部署了错误的内容，您始终可以从此库中获取任何其他以前的版本，并以相同的方式将其取消部署到这些环境。 如果出现问题，您可以轻松回滚到以前的版本。
还有另一个很棒的做法。 你我都明白，当我们将应用程序回滚到以前的版本时，这可能意味着我们还需要以前版本的基础设施。
当我们谈论虚拟基础设施时，许多人认为这是管理员设置的东西。 比如说，如果您需要一台新服务器来测试应用程序的新版本，那么您必须向管理员或开发人员写一张票。 DevOps 为此需要 3 周时间。 3 周后，他们会告诉您，我们已经为您安装了一台虚拟机，具有一个核心、3GB RAM 和一台不带 DotNet 的 Windows 服务器。 你说：“但我想要 DotNet。” 他们：“好吧，三周后回来。”
这个想法是，通过使用基础设施即代码实践，您可以将虚拟基础设施视为另一种资源。
也许，如果你们中有人在 DotNet 上开发应用程序，您可能听说过一个名为 Entity Framework 的库。 您甚至可能听说过实体框架是微软积极推动的方法之一。 对于使用数据库，这是一种称为“代码优先”的方法。 这是当您在代码中描述您希望数据库的外观时。 然后部署应用程序。 它连接到数据库，它本身确定哪些表存在，哪些表不存在，并创建您需要的一切。
您可以对您的基础设施执行同样的操作。 项目是否需要数据库或项目是否需要 Windows 服务器之间没有区别。 这只是一个资源。 并且你可以自动化这个资源的创建，你可以自动化这个资源的配置。 因此，每次你想要测试一些新概念、新方法时，你不需要给 devops 写票，你可以简单地从现成的模板、现成的脚本为自己部署一个隔离的基础设施并实现它那里有你所有的实验。 您可以删除它，获取一些结果并进一步报告。
下一个实践也存在并且也很重要，但很少有人使用，那就是应用程序性能监控。
关于应用程序性能监控，我只想说一件事。 这种做法最重要的是什么？ 这就是应用程序性能监控与修理公寓大致相同的地方。 这不是最终状态，而是一个过程。 你需要定期这样做。
从一种好的方式来说，在几乎每个构建上执行应用程序性能监控是件好事，尽管正如您所知，这并不总是可能的。 但是，至少需要为每个版本执行此操作。
它为什么如此重要？ 因为如果你突然遇到性能下降，那么你需要清楚地了解原因。 如果您的团队有两周的冲刺，那么您应该至少每两周将应用程序部署到某个单独的服务器，在该服务器上您有明确固定的处理器、RAM、磁盘等。并运行相同的性能测试。 你得到结果了。 查看它与之前的 sprint 相比有何变化。
如果你发现某个地方的回撤急剧下降，那就意味着这只是因为过去两周发生的变化。 这将使您能够更快地识别并解决问题。 再说一遍，这些指标大致相同，您可以通过它们来衡量您的成功程度。
我们的下一个实践是配置管理实践。 很少有人认真对待这一点。 但请相信我，这实际上是一件非常严重的事情。
最近有一个有趣的故事。 这些人来找我说：“帮助我们对我们的应用程序进行安全审核。” 我们一起看了很长时间的代码，他们告诉我有关应用程序的信息，画了图表。 无论正负，一切都是合乎逻辑的、可以理解的、安全的，但有一个但是！ 他们的源代码管理中有配置文件，包括使用 IP 数据库生产的配置文件，以及用于连接到这些数据库的登录名和密码等。
我说：“伙计们，好吧，你们已经用防火墙关闭了生产环境，但事实上，你们在源代码管理中拥有生产数据库的登录名和密码，并且任何开发人员都可以读取它，这已经是一个巨大的安全风险。 无论您的应用程序从代码的角度来看多么安全，如果您将其保留在源代码控制中，那么您将永远无法通过任何审计。” 我就是这个意思。
配置管理。 我们在不同的环境下可能会有不同的配置。 例如，我们对于 QA、演示、生产环境等的数据库可能有不同的登录名和密码。
该配置也可以自动化。 它应该始终与应用程序本身分开。 为什么？ 因为你构建了应用程序一次，然后应用程序并不关心你是否通过某某IP或某某IP连接到SQL服务器，它应该工作相同。 因此，如果突然有人仍在代码中对连接字符串进行硬编码，请记住，如果您发现自己与我在同一个项目中，我会找到您并惩罚您。 它始终放置在单独的配置中，例如，在 web.config 中。
而且这个配置已经是单独管理的，也就是说，这正是开发人员和管理员可以坐在同一个房间的时刻。 开发人员可以说：“看，这是我的应用程序的二进制文件。 他们工作。 该应用程序需要数据库才能工作。 二进制文件旁边有一个文件。 在这个文件中，这个字段负责登录，这个是密码，这个是IP。 将其部署到任何地方。” 对管理员来说简单明了。 他可以通过管理此配置将其部署到任何地方。
我想谈的最后一个实践是与云非常非常相关的实践。 如果您在云端工作，它会带来最大的效果。 这是自动删除您的环境。
我知道参加这次会议的有几个人来自与我一起工作的团队。 在与我合作的所有团队中，我们都采用这种做法。
为什么？ 当然，如果每个开发人员都有一个可以 24/7 工作的虚拟机，那就太好了。 但也许这对你来说是新闻，也许你没有注意到，但开发人员本身并不是 24/7 工作的。 开发人员通常每天工作 8 小时。 即使他上班很早，他也会吃一顿丰盛的午餐，期间他会去健身房。 就让开发者实际使用这些资源的时候一天12个小时吧。 根据我们的立法，每周 5 天中有 7 天被视为工作日。
因此，在工作日，该机器不应工作 24 小时，而只能工作 12 小时，而在周末，该机器不应根本不工作。 看起来一切都很简单，但是这里要说的是什么？ 通过按照这个基本计划实施这个简单的实践，您可以将维护这些环境的成本降低 70%，即您将开发、QA、演示、环境的价格除以 3。
问题是，剩下的钱怎么办？ 例如，如果开发人员还没有购买 ReSharper，他们应该购买。 或者举办鸡尾酒会。 如果您以前有一个开发和 QA 都可以使用的环境，就是这样，现在您可以创建 3 个不同的环境，这些环境将被隔离，人们不会互相干扰。
对于持续性能测量的幻灯片，如果项目中数据库中有1条记录，两个月后就有000万条记录，我们如何比较性能？ 如何理解衡量绩效的原因和意义？
这是一个很好的问题，因为您应该始终衡量相同资源上的性能。 也就是说，您推出新代码，衡量新代码的性能。 例如，您需要测试不同的性能场景，假设您要测试应用程序在轻负载下的性能，其中有 1 个用户，数据库大小为 000 GB。 你测量了它并得到了数字。 接下来我们来看另一个场景。 例如，5 个用户，数据库大小 5 TB。 我们收到了结果并记住了它们。
这里重要的是什么？ 这里重要的是，根据场景、数据量、并发用户数等，您可能会遇到某些限制。 例如，网卡的限制，或者硬盘驱动器的限制，或者处理器能力的限制。 这对您来说理解很重要。 在不同的场景中，您会遇到某些限制。 当你达到这些数字时，你需要理解这些数字。
我们是在谈论在特殊测试环境中测量性能吗？ 也就是说，这不是生产？
是的，这不是生产环境，这是测试环境，它始终相同，以便您可以将其与以前的测量结果进行比较。
明白了，谢谢！
如果没有问题，我想我们就可以结束了。 谢谢你！
来源： habr.com