重要公告：我們的阿里 BP 專案部署流程已全面升級！即日起採用全新的自動化 CI/CD 流程，告別手動部署時代。

懶人包

新流程超級簡單：

# 開發測試
git push origin main  # 自動部署到開發環境

# 功能測試  
git tag v1.2.0-rc.1 && git push origin v1.2.0-rc.1  # 自動部署到測試環境

# 正式發佈
git tag v1.2.0 && git push origin v1.2.0  # 自動部署到生產環境

解決了什麼問題？

舊流程的痛點

# 為了測試功能往往需要重複執行這些指令...
ssh ali-server "cd /app && git pull"
ssh ali-server "docker-compose build"  
ssh ali-server "docker-compose down && docker-compose up -d"

主要問題：

• 每次部署需要記住一長串指令
• 頻繁切換部署環境時容易下錯指令
• 重複性工作太多，整合後可節省大量時間

新流程的優勢

• 推送即部署：無需再手動登入各個部署環境
• 測試環境驗證：生產環境發佈前先在 staging 環境驗證

下階段發展目標

• 自動化測試：程式碼推送前自動執行品質檢查
• 智慧回滾：發現問題時 30 秒內自動恢復
• 即時通知：透過 Telegram 即時通知部署狀態

版本號規則（重要！）

基本格式說明

v1.2.3-rc.1
│││ │   └── RC 版本序號
│││ └────── 預發布標識符
││└──────── PATCH 版本（錯誤修復）
│└───────── MINOR 版本（新增功能）
└────────── MAJOR 版本（重大更新）

實際使用範例

# 開發階段：直接推送，無需打 tag
git push origin main

# 測試階段：使用 RC 版本號
git tag v1.3.0-rc.1    # 第一版測試版本
git tag v1.3.0-rc.2    # 修復問題後的版本
git tag v1.3.0-rc.3    # 最終測試版本

# 發佈階段：移除 RC 後綴
git tag v1.3.0         # 正式發佈版本

版本號遞增邏輯

專案實際案例：

• 修復爬蟲程式錯誤 → v1.2.3 → v1.2.4
• 新增資料匯出功能 → v1.2.4 → v1.3.0
• 重構整體 API 架構 → v1.3.0 → v2.0.0

實際操作指南

1. 日常開發部署

使用時機：完成小功能開發或錯誤修復，需要在開發環境進行測試

# 如同平常一樣推送到 main 分支
git add .
git commit -m "feat: 新增使用者頭像上傳功能"
git push origin main

# 系統將自動執行：
# 1. 建構 Docker 映像檔
# 2. 部署至開發環境

預期結果：1-2 分鐘後，您的程式碼變更將在開發環境生效！

2. 功能測試部署

使用時機：功能開發完成，需要在模擬生產環境進行完整驗證

# 建立 RC (Release Candidate) 測試版本
git tag v1.2.0-rc.1
git push origin v1.2.0-rc.1

# 系統將自動執行：
# 1. 建構測試環境專用映像檔
# 2. 部署至測試環境

如果測試中發現問題：

# 修復問題後建立新的 RC 版本
git commit -m "fix: 修復測試環境爬蟲檔案下載失敗問題"
git tag v1.2.0-rc.2
git push origin v1.2.0-rc.2

3. 正式環境發佈

使用時機：測試環境驗證完成，準備發佈至生產環境

# 建立正式版本（重要：必須在已測試的 commit 上執行）
git tag v1.2.0
git push origin v1.2.0

# 系統將自動執行：
# 1. 建構生產環境專用映像檔
# 2. 部署至生產環境

Q&A

Q1: 推送 tag 後多久會完成部署？

A: GitHub Actions 建構映像檔約需 1-2 分鐘，各環境的部署時間會依據 Watchtower 的檢查頻率而定。

Q2: 如果版本號標記錯誤該如何處理？

A:

# 刪除錯誤的標籤
git tag -d v1.2.0
git push origin --delete v1.2.0

# 重新建立正確的標籤
git tag v1.2.1
git push origin v1.2.1

Q3: 遇到緊急問題需要快速修復時怎麼辦？

A:
直接在 main 分支進行修復並標記正式版本：

git commit -m "hotfix: 修復爬蟲檔案下載失敗問題"
git tag v1.2.1
git push origin v1.2.1

你可能不會想知道的技術細節

本節內容提供給對技術架構有興趣的同事參考

系統架構流程圖

GitHub Repository
    ↓ (程式碼推送/標籤)
GitHub Actions (CI 持續整合)
    ↓ (建構與推送)
GitHub Container Registry
    ↓ (映像檔拉取)
Watchtower (CD 持續部署) → Docker Containers

映像檔標籤對應策略

三環境配置差異

開發環境

• 更新檢查頻率：每 1 分鐘
• 部署策略：立即更新
• 資料來源：開發專用測試資料

測試環境

• 更新檢查頻率：每 5 分鐘
• 部署策略：快速更新
• 資料來源：模擬生產環境資料

生產環境

• 更新檢查頻率：每 30 分鐘
• 部署策略：滾動式平滑更新
• 資料來源：實際生產環境資料

核心自動化組件

GitHub Actions

• 多架構映像檔建構：同時支援 AMD64 和 ARM64 架構
• 自動環境偵測：自動識別部署目標環境並建構對應映像檔

Watchtower

• 持續容器監控：定期檢查映像檔更新狀態
• 服務健康檢查：確保服務正常運作

Docker Compose

• 多服務協調編排：阿里 BP 主應用程式 + PostgreSQL 資料庫 + Selenium 服務
• 環境完全隔離：透過 profiles 機制區分不同環境
• 資料永久保存：確保重要資料不因部署而遺失

總結

新的自動化部署流程讓我們能夠：

• 提升效率：告別繁瑣的手動操作
• 降低風險：減少人為操作錯誤
• 加速交付：快速將功能推送到各個環境

讓我們一起擁抱自動化，專注於創造價值！