单页应用程序中智能DevOps的5种策略

最新推荐文章于 2021-01-03 16:10:21 发布

「已注销」

最新推荐文章于 2021-01-03 16:10:21 发布

阅读量198

点赞数

文章标签： js 编程语言 docker java javascript

本文链接：https://blog.csdn.net/duxinshuxiaobian/article/details/109324127

版权

全文共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插件）很重要，这能避免花时间在反馈周期上。但是，保证质量以进行整体代码质量管理同样重要。