Power Platform Managed Solution：Update、Upgrade、Stage for Upgrade 完整區別

| PowerPlatform | 3 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1383

在 Power Platform 中，如果 Canvas App、Dataverse Table、Power Automate Flow 等元件都透過 Solution 管理，常見的 ALM 發布流程是：

Development
    ↓
Unmanaged Solution
    ↓
匯出 Managed Solution
    ↓
Sandbox
    ↓
Production

也就是說，開發環境通常使用 Unmanaged Solution，而 Sandbox、Production 等下游環境則匯入 Managed Solution。

當 Sandbox 或 Production 已經存在舊版本 Managed Solution，再匯入同一 Solution 的較新版本時，Power Platform 會判斷這是一個既有 Solution 的更新，並提供 Update、Upgrade、Stage for Upgrade 等處理方式。

一、Update、Upgrade、Stage for Upgrade 有什麼不同？

方式 主要行為 新版已刪除的舊 Component 是否產生 _Upgrade
Update 將新版內容更新到既有 Solution 保留 否
Upgrade 直接完成正式升級 刪除 目前一般不會
Stage for Upgrade 先建立 Pending Upgrade，再稍後完成正式升級 Apply 前暫時保留 是

二、Update：更新，但不清理舊 Component

例如舊版本包含：

Canvas App
Table A
Table B
Flow A

新版已經把 Flow A 刪除：

Canvas App
Table A
Table B

如果使用 Update，新版內容會更新進去，但是舊版中的 Flow A 不會因為新版已經沒有它而自動刪除。

因此最後可能仍然是：

Canvas App
Table A
Table B
Flow A  ← 仍然存在

Update 適合只想更新既有 Component，而暫時不希望 Power Platform 清理舊 Component 的情況。

另外，Update 不會產生：

MyBusinessSolution_Update

這種 Solution 並不存在。

三、Upgrade：更新並完成舊 Component 清理

如果對同樣的版本變更使用 Upgrade：

舊版：
Canvas App
Table A
Table B
Flow A

新版：
Canvas App
Table A
Table B

正式 Upgrade 完成後會變成：

Canvas App
Table A
Table B

Flow A 因為已經不包含在新版 Solution 中，因此會被移除。

目前 Power Platform 的單步 Upgrade 流程已經過最佳化，正常直接執行 Upgrade 時，一般不需要先建立一個暫時的 _Upgrade Solution。

因此一般發布通常可以理解為：

MyBusinessSolution 1.0.0.0
        ↓
Import 1.1.0.0
        ↓
Upgrade
        ↓
MyBusinessSolution 1.1.0.0

Solution 清單最終仍然只有一個正式 Solution。

四、Stage for Upgrade：把 Upgrade 拆成兩個階段

Stage for Upgrade 比較特殊。

假設目前環境中已經存在：

MyBusinessSolution

匯入新版時選擇 Stage for Upgrade，完成後 Solution 清單會暫時看到：

MyBusinessSolution
MyBusinessSolution_Upgrade

這裡的 _Upgrade 是 Power Platform 用於 Pending Upgrade 的特殊 Solution。它不是一閃而過的畫面狀態，也不會幾分鐘後自動消失。

只要還沒有執行 Apply Solution Upgrade，這兩個 Solution 就會繼續存在。

流程可以理解為：

原 Managed Solution
        ↓
Stage for Upgrade
        ↓
MyBusinessSolution
MyBusinessSolution_Upgrade
        ↓
進行必要確認、資料移行、Dependency 處理等
        ↓
Apply Solution Upgrade
        ↓
MyBusinessSolution

Apply Solution Upgrade 完成之後，Pending Upgrade 會被正式套用，新版不存在的舊 Component 也會被清理，最後再次只剩一個正式 Solution。

五、兩個 Solution 是否代表有兩個 Canvas App？

不是。

這是 Stage for Upgrade 最容易誤解的地方。

例如 Stage 後看到：

MyBusinessSolution
└─ MainCanvasApp

MyBusinessSolution_Upgrade
└─ MainCanvasApp

這並不代表環境中存在：

MainCanvasApp_舊版
MainCanvasApp_新版

兩套獨立 App。

只要兩邊所列的是同一個 Canvas App Component，它們實際指向的仍然是同一個 App Component。

差別在於這個 Component 存在不同的 Solution Layer。

概念上比較接近：

同一個 MainCanvasApp
        │
        ├─ Base Solution Layer
        │
        └─ Pending Upgrade Layer
                ↑
              上層

也就是說，Solution 是元件的「封裝與 Layer 管理單位」，並不是每一個 Solution 都保存一套完全獨立的 Canvas App。

六、從兩個 Solution 入口進入，看到的是不是同一個 App？

如果 Base Solution 和 _Upgrade Solution 中都列出了同一個 Canvas App，那麼兩個入口指向的是同一個 App Component。

因此不存在：

從 MyBusinessSolution 打開 → 執行舊版 App

從 MyBusinessSolution_Upgrade 打開 → 執行新版 App

這種選擇方式。

Stage for Upgrade 並不是建立一套可以與正式 App 完全隔離運行的「新版測試 App」。

七、那 Stage for Upgrade 後應該怎麼測試？

可以直接進入 Power Apps 左側的：

アプリ
    ↓
MainCanvasApp
    ↓
Play

也可以從 Solution 中找到該 Canvas App 再打開。

兩種方式最終執行的仍然是目前這個環境中的同一個 Canvas App。

因此 Stage for Upgrade 後真正需要確認的是整個環境目前實際運行的狀態，例如：

  • Canvas App 畫面與操作是否正常
  • Dataverse Table、Column 是否正常
  • Power Automate Flow 是否正常
  • Connection Reference 是否正常
  • Environment Variable 是否正確
  • Security Role 與資料權限是否正常
  • 資料移行是否完成
  • 舊 Component 是否仍存在 Dependency

需要注意的是，Pending Upgrade 會形成新的 Solution Layer。對大多數採用「Top wins」規則的 Component，較上層 Layer 可以影響實際 Runtime。

因此不能把 Stage for Upgrade 理解為：

舊版仍然正式運行
新版完全隔離在 _Upgrade 裡等待測試

這並不是一個獨立的測試環境。

八、為什麼 Apply Solution Upgrade 後還要再測一次？

因為 Stage 階段與 Apply 完成後的狀態並不完全相同。

例如舊版有：

Canvas App
Table A
Flow A

新版只有：

Canvas App
Table A

Stage for Upgrade 階段，Flow A 可能仍然暫時存在。

但執行：

Apply Solution Upgrade

之後，Flow A 才會因為新版已經不包含它而被正式清理。

因此比較完整的確認流程是：

Stage for Upgrade
        ↓
第一次確認
        ↓
資料移行 / Dependency 處理
        ↓
Apply Solution Upgrade
        ↓
舊 Component 清理
        ↓
第二次 Smoke Test

尤其是存在 Table、Column、Relationship、Flow 等刪除操作時，Apply 後的最終確認非常重要。

九、Stage for Upgrade 主要是拿來做什麼？

Stage for Upgrade 並不是一般版本發布時必須使用的功能。

它更適合這類情況：

新版準備刪除舊 Table / Column / Component
        ↓
但正式刪除之前
還需要搬資料、解除 Dependency 或完成其他處理
        ↓
Stage for Upgrade
        ↓
完成必要工作
        ↓
Apply Solution Upgrade

如果只是普通的 Canvas App 功能更新，通常沒有必要刻意使用 Stage for Upgrade。

十、一般建議的 Dev → Sandbox → Production 流程

比較簡單而且乾淨的方式是：

Development
Unmanaged Solution
        ↓
提高 Solution Version
        ↓
Export Managed Solution
        ↓
Sandbox
        ↓
Upgrade
        ↓
完整測試
        ↓
同一個 Managed ZIP
        ↓
Production
        ↓
Upgrade
        ↓
Smoke Test

例如：

Development
1.0.0.0
        ↓
修改 Canvas App / Flow / Table
        ↓
1.1.0.0
        ↓
Export Managed
        ↓
Sandbox：Import → Upgrade
        ↓
測試 OK
        ↓
Production：匯入同一個 Managed ZIP → Upgrade

這樣 Production 實際部署的，就是 Sandbox 已經驗證過的同一份 Artifact。

十一、三種方式最簡單的記法

Update
= 更新新版內容
= 不主動清除新版已刪除的舊 Component

Upgrade
= 更新新版內容
= 同時完成舊 Component 清理

Stage for Upgrade
= 把 Upgrade 拆成兩個階段
= 先 Pending Upgrade
= 完成必要處理後再 Apply Solution Upgrade

而對 _Upgrade 最重要的理解則是：

兩個 Solution
≠
兩套 Canvas App

而是：

同一個 Component
+
不同的 Solution Layer

因此在一般 ALM 中，可以把 Upgrade 當作正常版本發布方式；只有在正式清理舊 Component 之前還需要進行資料移行、解除 Dependency 等特殊操作時，再考慮使用 Stage for Upgrade。

This article was last edited at