部署Vue.js SPA：多环境配置文件与Git部署流程技术咨询

Great question! Handling multiple environments in a Vue CLI webpack project doesn't have to be messy—let's break this down into two parts: setting up environment-specific configs, and optimizing your Git workflow to match your four stages.

Step 1: Create Environment Config Files #

In your project's config/ directory, you'll already have dev.env.js and prod.env.js. Add two more files for your staging/QA and UAT environments:

• config/staging.env.js
• config/uat.env.js

Each file should export your environment-specific variables (like API URLs). For example, staging.env.js might look like:

module.exports = {
  NODE_ENV: '"staging"',
  API_URL: '"https://staging-api.yourdomain.com"'
}

Repeat this pattern for uat.env.js, and update dev.env.js/prod.env.js to match their respective API endpoints.

Step 2: Install cross-env for Cross-Platform Compatibility #

To set environment variables consistently across Windows, macOS, and Linux, install cross-env as a dev dependency:

yarn add cross-env --dev

Step 3: Update Build Scripts in package.json #

Modify your scripts section to add build commands for each environment. This lets you trigger environment-specific builds with a single command:

"scripts": {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  "build:dev": "cross-env BUILD_ENV=dev node build/build.js",
  "build:staging": "cross-env BUILD_ENV=staging node build/build.js",
  "build:uat": "cross-env BUILD_ENV=uat node build/build.js",
  "build:prod": "cross-env BUILD_ENV=prod node build/build.js"
}

Step 4: Modify the Build Script to Load the Correct Env #

Open build/build.js and replace the hardcoded prod.env import with a dynamic one based on the BUILD_ENV variable:

// Replace this line:
// const env = require('../config/prod.env')

// With this dynamic import:
const env = require(`../config/${process.env.BUILD_ENV || 'prod'}.env`)

Step 5: Use Environment Variables in Your App #

You can now access these variables anywhere in your Vue components or JS files using process.env.API_URL. For example, setting a base URL for Axios:

import axios from 'axios'
axios.defaults.baseURL = process.env.API_URL

For a clean, scalable workflow across four environments, I recommend adopting a Git Flow-inspired branching strategy (tweaked to fit your specific stages). Here's how to structure it:

Branch Structure #

• main: Production-ready code (only merged when UAT is fully approved).
• develop: Integration branch for all completed features (used for dev environment testing).
• feature/*: Short-lived branches for individual features/bug fixes (merged into develop once tested locally).
• release/<environment>: Branches for preparing releases to specific environments (e.g., release/staging, release/uat). These let you make environment-specific tweaks without affecting develop.
• hotfix/*: Emergency fix branches for production issues (merged directly into main and develop).

Deployment Workflow #

1. Development (Dev):

   • Developers work on feature/* branches, testing locally with yarn dev.
   • Once a feature is done, merge it into develop.
   • If you have a dedicated Dev server, set up CI/CD to automatically run yarn build:dev and deploy the dist/ folder whenever develop is updated.

2. Staging/QA:

   • Create a release/staging branch from develop.
   • Run yarn build:staging to generate the staging build, then deploy to your QA server.
   • After QA passes, merge release/staging back into develop (to keep it in sync) and delete the release branch.

3. UAT:

   • Create a release/uat branch from the updated develop.
   • Build with yarn build:uat and deploy to the UAT server.
   • Once UAT approves, merge release/uat into both develop and main.

4. Production:

   • From the main branch, run yarn build:prod to generate the production build.
   • Deploy the dist/ folder to your production server.

Automate with CI/CD (Optional but Highly Recommended) #

To eliminate manual steps, set up a CI/CD tool (like Jenkins, GitLab CI, or GitHub Actions) to:

• Trigger builds automatically when specific branches are pushed.
• Deploy the built dist/ folder to the corresponding server.
• Run automated tests before deployment to catch issues early.

Key Notes #

• Never commit the dist/ folder to Git—let CI/CD or your server build it on demand.
• For sensitive data (like API keys), avoid hardcoding them in env files. Instead, use server-side environment variables or a .env.local file (add to .gitignore) that overrides default configs locally.

内容的提问来源于stack exchange，提问作者abstrakt