前端打同一个包可以从测试晋升到生产的配置方案

发布时间：2024年01月19日

前端打同一个包从测试晋升到生产环境的方案，是一种高效、可靠且易于维护的部署方式。在这种方案中，前端代码在开发完成后，经过测试验证无误后，可以直接打包部署到生产环境，无需进行额外的配置或修改。这样可以减少部署过程中可能出现的错误和延迟，提高应用的可用性和性能。

为什么需要这种方案：

简化部署流程：通过使用同一个包从测试到生产，可以大大简化部署流程。开发人员只需要打包一次，就可以在不同的环境中使用。这避免了在不同环境之间迁移代码时可能出现的错误和混淆。
提高应用性能：由于测试环境和生产环境中的代码是相同的，因此应用的性能在两个环境中也会保持一致。这有助于确保用户在生产环境中获得最佳的性能体验。
减少维护成本：使用同一个包从测试到生产可以减少维护成本。一旦代码在测试环境中通过验证，就可以放心地部署到生产环境，而无需担心环境差异带来的问题。这有助于降低技术支持和故障排除的成本。
提高开发效率：通过消除在不同环境之间迁移代码的需要，这种方案可以显著提高开发效率。开发人员可以专注于开发任务，而不是部署和环境配置等非核心工作。这有助于加快开发周期和迭代速度。
提高应用可用性：由于测试环境和生产环境中的代码是相同的，因此应用在生产环境中出现问题的可能性大大降低。这有助于提高应用的可用性和稳定性，从而提升用户体验和忠诚度。
总之，前端打同一个包从测试晋升到生产环境的方案是一种高效、可靠且易于维护的部署方式。它可以简化部署流程、提高应用性能、降低维护成本、提高开发效率和应用的可用性。因此，对于需要频繁部署和快速迭代的前端项目来说，这种方案是一种非常有价值的工具。

直接上代码:
代码下载地址

具体方案

在这里插入图片描述

Nginx subfilter

在 Nginx 中，你可以使用 sub_filter 指令来替换 HTML 中的占位符。sub_filter 允许你在 Nginx 处理响应内容时进行文本替换，这通常用于修改 HTML 页面中的特定内容。

以下是一个简单的示例，演示如何在 Nginx 配置中使用 sub_filter：

server {
    listen 8090;
    server_name localhost;

    location / {
        index index.html;
        root /Users/yueyu/Project/allens-learn/webapp/subfilter;
        # 启用 sub_filter
        sub_filter '_SERVER_ADDR' 'http://123.com';
        sub_filter_once off; # 可选，用于启用全局替换而不仅仅是第一次出现的地方
    }
}

在上述配置中：

sub_filter 指令用于替换响应中的 （占位符）为指定的 replacement_value。
sub_filter_once off; 是可选的，如果设置为 off，则会对所有匹配的地方进行替换。如果设置为 on，则只替换第一次匹配的地方。
请根据你的实际需求修改 和 replacement_value，以及其他配置参数。确保配置文件语法正确，并且重新加载 Nginx 以应用更改。

<html>
    <head>
        <title>nginx sub-filter</title>
        <script src="index.js"></script>
        <script>
            var addr = "_SERVER_ADDR";
            console.log("xxxxx", addr)
        </script>
    </head>
</html>

console.log()会输出123.com。

这种方案可以完美解决同一个包晋升的问题，优点有改造成本比较低，对代码入侵性很低，不同环境配置不同的nginx config即可。性能也比较好，单页应用只会在第一次加载的时候替换。

但也有很多缺点，比如:
① 必须使用nginx
② 配置都要配置到nginx中
③ 本地环境使用webpack-dev-server启动的话可能需要单独适配
④ 配置在nginx中，可发需要熟悉成本，假设不知道有这个东西可能会有配置遗漏等等

根据域名匹配

原理就是通过window.location.host 作为key拿到在js代码中的配置。直接上代码：

const domainMap = {

    "localhost:8090": {
        config1: "test"
    }

}

const getDomainConfig = (configName) => {
    const domain = window.location.host
    const config = domainMap[domain] || {}
    return config[configName]
}

html通过getDomainConfig传配置名称即可。

<html>
    <head>
        <title>nginx sub-filter</title>
        <script src="index.js"></script>
        <script>
            var addr = "_SERVER_ADDR";
            console.log("xxxxx", addr)
            console.log(getDomainConfig("config1"))
        </script>
    </head>
</html>

这种优点就是很方便简单，缺点也很明显假如域名不匹配可能就获取不到配置了。

前后端不分离

现在主流情况就是前后端分离，所以不做过多讨论，只提供思路。

可以通过后端把公共配置传参到前端，比如java的thymleaf ，velocity等等。php的话就是smarty、laravel的blame、thinkphp的模板填充等。

原理很简单，前端代码都是通过后端渲染的，后端理论上可以对前端的代码为所欲为。前端只需要写好后端约定的占位符，后端替换即可，这种方式和nginx subfilter很类似。

文章来源:https://blog.csdn.net/yh4494/article/details/135691169
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
最新文章