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

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

为什么需要这种方案:

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

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

具体方案

前端打同一个包可以从测试晋升到生产的配置方案_第1张图片

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-filtertitle>
        <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-filtertitle>
        <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很类似。

你可能感兴趣的:(前端)