Guidant AI · FR-127 需求索引
⌂ 需求中心

FR-127 · 需求索引 · 本頁由 build 掃資料夾生成

FR-127 GitLab CI 一鍵發版

網頁按一顆鈕 → 掃描 → 平行 build → 封包 → 升級 e2e

狀態：完成（2026-10-03） 文件 2 份

FR-127 GitLab CI 一鍵發版

§1

🔴 先看哪一份

文件 性質 什麼時候看
本頁 首頁 想知道這個需求做完是什麼樣子、決定了哪些事
design.md 設計 想知道流程怎麼走、為什麼這樣選、哪些坑換機器還會再撞
operations.md 操作手冊 要發一版、看結果、處理憑證過期、換 build 機
.gitlab-ci.yml、scripts/build/*.sh 檔頭 程式碼 要改流程時；真相以程式碼為準
Notion 母卡 CM-2412、commit message 歷史 想知道當初怎麼一步步修到全綠
§2

結論

  1. 發版從「登進 188 手打一串指令」變成「在 GitLab 網頁按 Run pipeline、選 e2e」，約 30 分鐘後 e2e 專機（190）就升到新版。
  2. 一次跑完四段：先掃相依套件漏洞並產出 SBOM（軟體成分表）→ 四顆 image 平行打 → 封安裝包並推 Harbor → 用客戶升級的同一條路把安裝包升到 190；任何一段紅了就停，不會帶著問題部署。
  3. 定版 tag 仍由決策者本人手打，CI 只負責「把這個 commit 做成一包、升到 e2e」；安裝包留在 188，要給客戶從那裡拿。

像但不做的：push／MR／打 tag 不自動觸發（發版是人的決定）；部署不從 Harbor pull（所有環境統一走安裝包）；安裝包不放 GitLab artifacts（超過 1GB 上限）。

§3

📊 總進度

棒次 Notion 卡 做什麼 狀態 commits
單棒 CM-2412（母卡） 決策者本人 session 做：.gitlab-ci.yml、sbom.sh、push_harbor.sh、deploy_e2e.sh、188 runner 安裝 ✅ 326f4e7d9（初版）→ ed4a64cfb（deploy 改走安裝包）→ 4125f5e60（workflow 放行 api 來源）→ 1120bacf1（收 artifacts 前先清 out/）

第一次全綠：pipeline #2908476198（2026-10-03）。各段實測時間：verify 約 1 分、build 約 17 分（由 BE 決定）、package 約 9 分、deploy 約 3.5 分。

§4

需求討論紀錄

決策者拍板的七條（2026-10-02～03）：

  • D1 只有人主動發才跑：網頁 Run pipeline 或 glab ci run；push、MR、打 tag 都不觸發——發版是人的決定，不該因為推了一個 commit 就動到環境。
  • D2 按下去就是部署：選了環境就會部署，中間沒有第二道確認；保護靠「任一段失敗就停」，不靠多按一次。
  • D3 定版 tag 決策者手打，CI 不碰：image tag 改用「版號-commit 短 hash」，定版前同一版號可以出很多次測試包，彼此不覆蓋。
  • D4 邏輯全在 scripts/build/*.sh：CI 設定檔只寫「什麼時候、在哪台、叫哪支腳本」，188 手跑和 CI 跑走同一條路，不會出現兩套做法。
  • D5 直接在 188 的 /opt/guidant-ai-be 跑，不另外 clone：建置需要的 .venv、模型、.env、FE clone 都在那裡；代價是和手跑共用工作樹，所以有人在手跑或工作樹不乾淨就拒跑。
  • D6 SBOM 分兩份：應用層從 lock 檔產、會擋；OS 層從 image 產、只出報告不擋——BE 編譯後的 image 裡看不到 Python 套件，而基底 image 的漏洞天天有，拿來擋就永遠出不了貨。
  • D7 所有環境都走安裝包升級：e2e 用 install.sh --upgrade --force 升級，順便驗證安裝包本身升得上去；Harbor 照推，但只是出版的一環，不是部署來源。
§5

文件

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

設計

文件 類型 標題 最後更新
design ／ md 設計 設計 2026-10-03

其他文件

文件 類型 標題 最後更新
operations ／ md 文件 操作手冊 2026-10-03