Update on Tarragonhttps://tarrragon.github.io/blog/tags/update/Recent content in Update on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 21 May 2026 00:00:00 +0000Desktop client 簽章、公證與自動更新流程https://tarrragon.github.io/blog/ci/desktop-client-deploy/signing-notarization-update-flow/Thu, 21 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/ci/desktop-client-deploy/signing-notarization-update-flow/<p>Desktop client 發布流程的核心責任是讓多平台安裝包可信、可更新、可回復。桌面應用和 web 不同，使用者會下載 installer 或 package 到本機；CI/CD 需要處理平台差異、code signing、notarization、auto-update feed、delta package 與多版本共存。</p> <h2 id="流程定位">流程定位</h2> <p>Desktop client 的風險集中在作業系統信任鏈與更新通道。macOS、Windows、Linux 對簽章、安裝包格式與安全提示的要求不同；同一份 source 通常會產生多個平台 artifact，因此 workflow 要把平台 matrix、簽章 secret 與 <a href="https://tarrragon.github.io/blog/ci/knowledge-cards/release-channel/" data-link-title="Release Channel" data-link-desc="說明 stable、beta、internal 等發行通道如何控制 artifact 接觸到的使用者範圍">Release Channel</a> 拆清楚。</p> <table> <thead> <tr> <th>階段</th> <th>責任</th> <th>判讀訊號</th> </tr> </thead> <tbody> <tr> <td>Build</td> <td>產生 <code>.dmg</code>、<code>.pkg</code>、<code>.msi</code>、AppImage 等</td> <td>平台 matrix 是否完整</td> </tr> <tr> <td>Signing</td> <td>建立 OS 信任</td> <td>certificate、timestamp、keychain</td> </tr> <tr> <td>Notarize</td> <td>通過 macOS 公證或平台審查</td> <td>staple、gatekeeper 是否通過</td> </tr> <tr> <td>Release</td> <td>發布到 channel 或 download page</td> <td>stable / beta / internal 分流</td> </tr> <tr> <td>Update</td> <td>推送 <a href="https://tarrragon.github.io/blog/ci/knowledge-cards/update-feed/" data-link-title="Update Feed" data-link-desc="說明桌面與客戶端應用如何透過更新來源取得已簽章版本與回復路徑">Update Feed</a> 或 delta package</td> <td>feed 簽章、版本相容、回退策略</td> </tr> <tr> <td>Recovery</td> <td>hotfix、rollback channel、停用更新</td> <td>是否能阻止錯誤版本擴散</td> </tr> </tbody> </table> <p>Build 階段負責產生平台專屬 artifact。Flutter Desktop、Electron 與 Tauri 的輸出格式不同，但共同要求是每個 artifact 都能追到 commit、workflow run 與 dependency lock。</p> <p>Signing 階段負責讓 OS 信任安裝包。Windows code signing certificate、macOS Developer ID、timestamp server 與 Linux package signing key 都是發布能力；secret 應放在受控環境，並限制能觸發 signing job 的分支與 reviewer。</p> <p>Notarize 階段負責處理 macOS 信任 gate。macOS app 即使完成簽章，也常需要 notarization 與 stapling；CI 要把 notarization log 保存下來，否則使用者看到 Gatekeeper 警告時很難回溯。</p> <p>Release 階段負責把 artifact 放到正確 <a href="https://tarrragon.github.io/blog/ci/knowledge-cards/release-channel/" data-link-title="Release Channel" data-link-desc="說明 stable、beta、internal 等發行通道如何控制 artifact 接觸到的使用者範圍">Release Channel</a>。Internal、beta、stable 與 enterprise channel 的 gate 不同；CI/CD 要避免未審核的 beta artifact 被 stable feed 取用。</p> <p>Update 階段負責維持升級路徑。<a href="https://tarrragon.github.io/blog/ci/knowledge-cards/update-feed/" data-link-title="Update Feed" data-link-desc="說明桌面與客戶端應用如何透過更新來源取得已簽章版本與回復路徑">Update Feed</a>、delta package、signature、minimum supported version 與 rollback channel 要一起設計；更新壞掉時，使用者可能卡在需要人工修復的版本。</p> <p>Recovery 階段負責止血。桌面客戶端常用方式是撤下 update feed、發布 hotfix、切換 rollback channel、停用 remote feature 或要求最低版本；每種方式都依賴 app 內建相容支援。</p> <h2 id="平台差異判讀">平台差異判讀</h2> <p>平台差異判讀的責任是讓 CI matrix 對應真實發布風險。桌面發布除了確認「三平台都 build 成功」，還要確認每個平台的安裝、啟動、更新與卸載行為。</p> <table> <thead> <tr> <th>平台</th> <th>高風險點</th> <th>驗證方向</th> </tr> </thead> <tbody> <tr> <td>macOS</td> <td>Developer ID、notarization、universal binary</td> <td>Gatekeeper、arm64 / x64 啟動</td> </tr> <tr> <td>Windows</td> <td>Authenticode、SmartScreen、installer 權限</td> <td>安裝、更新、卸載、權限提示</td> </tr> <tr> <td>Linux</td> <td>AppImage、deb、rpm、repository key</td> <td>dependency、desktop entry、sandbox</td> </tr> </tbody> </table> <p>這張表的用途是避免平台細節被單一「desktop build」欄位抹平。每個 OS 的失敗代價不同，CI 應保留平台專屬 gate。</p>Desktop client 發布流程的核心責任是讓多平台安裝包可信、可更新、可回復。桌面應用和 web 不同，使用者會下載 installer 或 package 到本機；CI/CD 需要處理平台差異、code signing、notarization、auto-update feed、delta package 與多版本共存。

流程定位

Desktop client 的風險集中在作業系統信任鏈與更新通道。macOS、Windows、Linux 對簽章、安裝包格式與安全提示的要求不同；同一份 source 通常會產生多個平台 artifact，因此 workflow 要把平台 matrix、簽章 secret 與 Release Channel 拆清楚。

階段 責任 判讀訊號
Build 產生 .dmg、.pkg、.msi、AppImage 等 平台 matrix 是否完整
Signing 建立 OS 信任 certificate、timestamp、keychain
Notarize 通過 macOS 公證或平台審查 staple、gatekeeper 是否通過
Release 發布到 channel 或 download page stable / beta / internal 分流
Update 推送 Update Feed 或 delta package feed 簽章、版本相容、回退策略
Recovery hotfix、rollback channel、停用更新 是否能阻止錯誤版本擴散

Build 階段負責產生平台專屬 artifact。Flutter Desktop、Electron 與 Tauri 的輸出格式不同，但共同要求是每個 artifact 都能追到 commit、workflow run 與 dependency lock。

Signing 階段負責讓 OS 信任安裝包。Windows code signing certificate、macOS Developer ID、timestamp server 與 Linux package signing key 都是發布能力；secret 應放在受控環境，並限制能觸發 signing job 的分支與 reviewer。

Notarize 階段負責處理 macOS 信任 gate。macOS app 即使完成簽章，也常需要 notarization 與 stapling；CI 要把 notarization log 保存下來，否則使用者看到 Gatekeeper 警告時很難回溯。

Release 階段負責把 artifact 放到正確 Release Channel。Internal、beta、stable 與 enterprise channel 的 gate 不同；CI/CD 要避免未審核的 beta artifact 被 stable feed 取用。

Update 階段負責維持升級路徑。Update Feed、delta package、signature、minimum supported version 與 rollback channel 要一起設計；更新壞掉時，使用者可能卡在需要人工修復的版本。

Recovery 階段負責止血。桌面客戶端常用方式是撤下 update feed、發布 hotfix、切換 rollback channel、停用 remote feature 或要求最低版本；每種方式都依賴 app 內建相容支援。

平台差異判讀

平台差異判讀的責任是讓 CI matrix 對應真實發布風險。桌面發布除了確認「三平台都 build 成功」，還要確認每個平台的安裝、啟動、更新與卸載行為。

平台 高風險點 驗證方向
macOS Developer ID、notarization、universal binary Gatekeeper、arm64 / x64 啟動
Windows Authenticode、SmartScreen、installer 權限 安裝、更新、卸載、權限提示
Linux AppImage、deb、rpm、repository key dependency、desktop entry、sandbox

這張表的用途是避免平台細節被單一「desktop build」欄位抹平。每個 OS 的失敗代價不同，CI 應保留平台專屬 gate。

Update feed 契約

Update Feed 契約的責任是讓已安裝使用者安全升級。Auto-update 需要簽章、版本比較、channel、最低版本與回退策略共同成立，才能讓新版本 URL 進入 feed。

  1. Feed 只指向已簽章且已驗證的 artifact。
  2. Stable feed 只接收 stable release，beta feed 只接收 beta release。
  3. App 啟動時能處理 feed 暫時不可用。
  4. Delta update 失敗時能 fallback 到 full installer。
  5. 錯誤版本要能從 feed 撤下，並讓未更新使用者停止取得。
  6. 已更新使用者要有 hotfix 或 rollback channel。

這些條件讓更新通道具備操作性。若 app 只知道「看到新版就下載」，錯誤 feed 會把事故放大到所有啟動中的使用者。

下一步路由

]]>Update Feedhttps://tarrragon.github.io/blog/ci/knowledge-cards/update-feed/Thu, 21 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/ci/knowledge-cards/update-feed/<p>Update Feed 的核心概念是「告訴已安裝客戶端該取得哪個版本」。它連接 <a href="https://tarrragon.github.io/blog/ci/knowledge-cards/release-channel/" data-link-title="Release Channel" data-link-desc="說明 stable、beta、internal 等發行通道如何控制 artifact 接觸到的使用者範圍">Release Channel</a> 與 <a href="https://tarrragon.github.io/blog/ci/knowledge-cards/app-signing/" data-link-title="App Signing" data-link-desc="說明行動與桌面應用的簽章憑證如何影響發布能力">App Signing</a>，讓自動更新具備信任與回復能力。</p> <h2 id="概念位置">概念位置</h2> <p>Update Feed 位在 signed artifact、release channel 與已安裝 app 之間，常包含版本號、下載 URL、signature、checksum、release notes 與最低支援版本。</p> <h2 id="可觀察訊號">可觀察訊號</h2> <ul> <li>客戶端需要自動偵測新版本。</li> <li>beta 與 stable 使用者需要看到不同版本。</li> <li>錯誤版本需要從更新來源撤下。</li> </ul> <h2 id="接近真實服務的例子">接近真實服務的例子</h2> <p>Electron app 啟動時讀取 stable feed，取得最新 signed installer 與 signature。若新版本 crash rate 升高，團隊先撤下 feed 指向，讓未更新使用者停止取得錯誤版本。</p> <h2 id="設計責任">設計責任</h2> <p>Update Feed 要定義簽章驗證、channel 分流、版本比較、fallback installer、撤版策略與 telemetry，讓已安裝客戶端安全升級。</p>Update Feed 的核心概念是「告訴已安裝客戶端該取得哪個版本」。它連接 Release Channel 與 App Signing，讓自動更新具備信任與回復能力。

概念位置

Update Feed 位在 signed artifact、release channel 與已安裝 app 之間，常包含版本號、下載 URL、signature、checksum、release notes 與最低支援版本。

可觀察訊號

  • 客戶端需要自動偵測新版本。
  • beta 與 stable 使用者需要看到不同版本。
  • 錯誤版本需要從更新來源撤下。

接近真實服務的例子

Electron app 啟動時讀取 stable feed，取得最新 signed installer 與 signature。若新版本 crash rate 升高，團隊先撤下 feed 指向，讓未更新使用者停止取得錯誤版本。

設計責任

Update Feed 要定義簽章驗證、channel 分流、版本比較、fallback installer、撤版策略與 telemetry，讓已安裝客戶端安全升級。

]]>