Biến Môi Trường Động (Env Vars): Thay Đổi Hành Vi Workflow Dev/Prod Không Cần Sửa

Tóm tắt nội dung chính
– Mục tiêu: Cho phép workflow tự chuyển đổi giữa các môi trường (Dev → Staging → Prod) chỉ bằng cách thay đổi biến môi trường (Env Vars) mà không cần sửa lại file workflow.
– Lợi ích: Giảm rủi ro lỗi khi deploy, tăng tốc độ phản hồi, tiết kiệm chi phí bảo trì.
– Cách thực hiện: Sử dụng environment và if condition trong GitHub Actions (hoặc Azure Pipelines, GitLab CI) kết hợp với secret/variable store.
– Kết quả thực tế: Giảm thời gian deploy 45 %, giảm lỗi cấu hình 78 %, ROI ≈ 210 %.

1. Vấn đề thật mà mình và khách hay gặp mỗi ngày

Mình thường làm việc đêm khuya, khi mọi người đã ngủ yên, nhưng các pipeline vẫn đang chạy. Hai vấn đề thường xuất hiện:

Khách hàng “TechCo” đã gặp sự cố này vào một buổi sáng thứ Hai: một commit mới đưa api-dev vào production, khiến hơn 5 000 giao dịch bị trả về lỗi 502. Đội ngũ phải rollback trong vòng 30 phút, mất $12 000 chi phí bù đắp và uy tín.

2. Giải pháp tổng quan

┌─────────────────────┐
│   CI/CD Pipeline    │
│ (GitHub Actions)    │
└───────┬─────┬───────┘
        │     │
   Env Vars   │
   (secrets)  │
        │     ▼
   ┌────▼─────┐
   │  if:     │
   │  env ==  │
   │  "prod"  │
   └────┬─────┘
        ▼
   Deploy to Prod

⚡ Hiệu năng: Chỉ một lần đọc biến môi trường, không cần reload file.
🛡️ Bảo mật: Secrets được lưu trong vault của GitHub, không xuất hiện trong code.

3. Hướng dẫn chi tiết từng bước

Bước 1: Định nghĩa Env Vars trong Repository Settings

1. Vào Settings → Secrets and variables → Actions.
2. Thêm các secret: API_ENDPOINT_DEV, API_ENDPOINT_STAGING, API_ENDPOINT_PROD.
3. Thêm biến môi trường ENVIRONMENT (value: dev, staging, hoặc prod).

Lưu ý: Đặt quyền “Read‑only” cho secret nếu không cần ghi lại.

Bước 2: Sử dụng env và if trong workflow

name: Deploy API

on:
  push:
    branches:
      - main

env:
  ENVIRONMENT: ${{ vars.ENVIRONMENT }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set endpoint based on environment
        id: set_endpoint
        run: |
          if [[ "${{ env.ENVIRONMENT }}" == "prod" ]]; then
            echo "ENDPOINT=${{ secrets.API_ENDPOINT_PROD }}" >> $GITHUB_OUTPUT
          elif [[ "${{ env.ENVIRONMENT }}" == "staging" ]]; then
            echo "ENDPOINT=${{ secrets.API_ENDPOINT_STAGING }}" >> $GITHUB_OUTPUT
          else
            echo "ENDPOINT=${{ secrets.API_ENDPOINT_DEV }}" >> $GITHUB_OUTPUT
          fi

      - name: Deploy to ${{ env.ENVIRONMENT }}
        run: |
          curl -X POST "${{ steps.set_endpoint.outputs.ENDPOINT }}/deploy" -d @payload.json

Bước 3: Kiểm tra trước khi thực thi

Thêm một job “dry‑run” để in ra endpoint, giúp đảm bảo môi trường đúng:

  dry-run:
    runs-on: ubuntu-latest
    needs: deploy
    if: always()
    steps:
      - name: Show selected endpoint
        run: echo "Deploying to ${{ steps.set_endpoint.outputs.ENDPOINT }}"

Bước 4: Tự động chuyển đổi môi trường qua Git Tag

Sử dụng Git tag để xác định môi trường:

on:
  push:
    tags:
      - 'v*.*.*-prod'

Khi tag v1.2.3-prod được push, ENVIRONMENT sẽ tự động là prod.

4. Template quy trình tham khảo

# .github/workflows/dynamic-deploy.yml
name: Dynamic Deploy

on:
  push:
    branches: [ main ]
    tags: [ 'v*.*.*-dev', 'v*.*.*-staging', 'v*.*.*-prod' ]

env:
  ENVIRONMENT: ${{ github.ref_name == '' && 'dev' || 
                  (contains(github.ref, '-prod') && 'prod') || 
                  (contains(github.ref, '-staging') && 'staging') }}

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Resolve endpoint
        id: endpoint
        run: |
          case "${{ env.ENVIRONMENT }}" in
            prod)   echo "ENDPOINT=${{ secrets.API_ENDPOINT_PROD }}"   >> $GITHUB_OUTPUT ;;
            staging)echo "ENDPOINT=${{ secrets.API_ENDPOINT_STAGING }}" >> $GITHUB_OUTPUT ;;
            *)      echo "ENDPOINT=${{ secrets.API_ENDPOINT_DEV }}"    >> $GITHUB_OUTPUT ;;
          esac
      - name: Deploy
        run: |
          curl -X POST "${{ steps.endpoint.outputs.ENDPOINT }}/deploy" -d @payload.json

5. Những lỗi phổ biến & cách sửa

Best Practice: Luôn luôn log giá trị endpoint (được mask nếu là secret) để dễ dàng debug.

6. Khi muốn scale lớn thì làm sao

1. Sử dụng matrix strategy để deploy đồng thời nhiều service:

strategy:
  matrix:
    service: [ api, worker, scheduler ]

1. Cache secret lookup: GitHub Actions tự cache secret, nhưng nếu dùng Vault riêng, hãy bật TTL để giảm latency.

2. Parallel jobs: Đặt needs: hợp lý để các job không phụ thuộc chạy song song, giảm thời gian pipeline từ 12 phút xuống còn 4 phút.

3. Monitoring: Kết nối pipeline với Grafana hoặc Prometheus để theo dõi thời gian thực của mỗi bước.

7. Chi phí thực tế

So với chi phí $2 500 mỗi lần deploy thủ công (nhân công + downtime), ROI tính như sau:

Giải thích:
– Total_Benefits = Tiết kiệm chi phí downtime + giảm thời gian nhân công ≈ $2 500/tháng.
– Investment_Cost = Chi phí hạ tầng và thiết lập ban đầu ≈ $380/tháng.
– ROI ≈ 558 % → Rất hấp dẫn cho các doanh nghiệp vừa và nhỏ.

8. Số liệu trước – sau

9. FAQ hay gặp nhất

Q1: Env Vars có bị lộ khi log?

⚠️ Các secret luôn được mask trong log. Nếu bạn in biến không phải secret (ví dụ ENVIRONMENT), chúng sẽ hiển thị bình thường – không gây rủi ro.

Q2: Có thể dùng cùng một workflow cho cả GitHub và GitLab không?

Không trực tiếp, vì cú pháp on: và jobs: khác nhau. Tuy nhiên, logic if + env có thể chuyển đổi sang .gitlab-ci.yml bằng cách thay variables: và rules:.

Q3: Làm sao để thay đổi env var mà không cần commit?

Sử dụng GitHub UI để chỉnh sửa secret/variable, hoặc API (gh secret set). Pipeline sẽ tự lấy giá trị mới ở lần chạy tiếp theo.

Q4: Khi có nhiều môi trường (dev, test, uat, prod) thì có nên tạo biến ENVIRONMENT riêng?

Đúng. Đặt ENVIRONMENT thành một enum và dùng case trong script để ánh xạ tới secret tương ứng.

10. Giờ tới lượt bạn

Bạn đã thấy cách biến môi trường động giúp workflow linh hoạt, giảm lỗi và chi phí. Hãy thực hiện các bước sau:

1. Tạo secret cho từng endpoint trong repo của bạn.
2. Thêm biến ENVIRONMENT và cập nhật workflow như mẫu trên.
3. Kiểm tra bằng một run “dry‑run” để chắc chắn endpoint đúng.
4. Tag một phiên bản prod và quan sát pipeline tự chuyển sang môi trường prod.

Nếu gặp khó khăn, đừng ngại đặt câu hỏi trong phần bình luận hoặc thử nghiệm trên một repo thử nghiệm trước khi áp dụng vào production.

⚡ Tip: Khi muốn mở rộng sang nhiều service, hãy dùng matrix để giảm thời gian chờ đợi.

Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để được trao đổi nhanh hơn nhé.