单页应用程序中智能DevOps的5种策略全文共2014字

全文共2014字，预计学习时长6分钟
文章插图
图源：unsplash
DevOps在开发生命周期中起着不可或缺。大多数前端框架都配有如Webpack一般的模块捆绑器，以负责繁重的工作。但是，我们仍然需要规划如何连接捆绑持续集成（CI）和持续交付（CD）环境的前端工具。
本文关注5种能在单页应用程序中使用DevOps的策略。
1.减少环境配置
当使用React、Angular和Vue创建单个页面应用的结构时，常规操作是每个环境使用单独的配置文件。通常，开发、生产等使用一个环境配置。若每个环境彼此不同，便有多个配置文件。
但是，在本应使用不同捆绑配置情况下，若开发和生产只使用两个配置，而其他应用程序特定的变量，如API路径和主机名等在生成后修改，又会怎么样呢？通过保留这两个配置，你可以分开本地开发配置与其余配置（生产、暂存和质量保证）。
如果将Build和Release划分为两个管道，可以先放完整的占位符，然后反复使用Build管道来创建构件。之后，根据部署环境，可以在Release管道中动态替换这些变量。这种方法主要有两个优点：
· 可将相同捆绑器推入多个环境（使用基础的字符串替换），节省宝贵构建时间。
· 掌握对捆绑器所做的确切更改，特别是在特定环境中。
2.设置质量门
在Pull Request合并到开发分支之前，先构建前端的做法很常见。
质量门的概念连接着Pull Request构建，你可以在其中设置其他步骤（或门）以确保质量。例如，可以用一个构建步骤来用linter执行操作，以确保修改或添加的任何代码与已经遵循的代码样式没有任何偏差。做完这步后，可以用SonarCloud等高级代码质量工具来进行质量检查，通过详细的见解向Pull Request本身提供反馈。
你或许会问，为什么在签入代码之前就不进行IDE级别的这些代码质量评估？是的，在IDE级别进行这些评估（如果有可用的IDE插件）很重要，这能避免花时间在反馈周期上。但是，保证质量以进行整体代码质量管理同样重要。
文章插图
图源：unsplash
3.缓存程序包安装
NPM软件包安装占很大一部分端构建的执行时间。重复构建时，由于很少更改外部依赖项，很难改善这个情况。
改进后，你可以设置一个缓存步骤来缓存这些依赖项。在特定的DevOps平台（例如AzureDevOps）中，预定义的步骤可以执行此操作。但是，如果无法在DevOps平台中找到它，可以基于package.json内容创建一个哈希函数，并将其用作缓存键来执行相同的操作。
4.寻找并行性
在某些情况下，当在DevOps管道上构建Web应用程序时，需要同时构建前端和后端。由于大多数DevOps平台都使用代理支持并行性，因此，可以将前端构建和后端划分为不同的代理。借此，完成构建所需的时间便减少了。
如果将DevOps步骤划为Build和Release管道，甚至可以在Release管道上组合前端和后端构建构件（前提是两者都部署到同一服务器上）。
此外，即使在构建管道中，还可以用其他步骤来执行并行操作。重要的是，尝试使用并行性进行各种优化，并评估其对整体DevOps的影响，以根据经验教训进行改进。
5.自动化测试的有效执行
最后，我想采取一个关键步骤，需要在DevOps管道中进行设置。尽管最好是在Pull Request级别执行这些步骤（在开发人员的设备上更佳），但需要根据测试执行时间来确定正确的执行位置。
例如，作为质量门的一部分，在Pull Request构建时执行单元测试是一种常见的做法。但是，如果执行要花几分钟时间（常事），则在此级别上运行E2E测试可能会成为一笔开销。因此，评估情况并决定在不同级别运行E2E测试用例至关重要。
文章插图
图源：unsplash
如你所见，我们可以对DevOps进行不同的改进，以提高效率并提升应用程序的整体质量。此外，其中的一些技术同样适用于后端。
【单页应用程序中智能DevOps的5种策略】虽然本文只讨论了五种策略，但是这些策略的方向可能会有助于进一步改进管道，以提高其性能（如根据构建步骤在各个级别进行缓存的技术）。
但还需要注意的是，每项改进都需要付出一定的代价。如果使用相同的缓存示例则应该知道，即使你指定NPM依赖项的自动更新小补丁，也有可能不使用库的最新更新。最后，希望这些步骤将有助于你更好地使用DevOps并改善现有管道。