Salesforce 發布火車：發布管理的實用方法

顧名思義，發布管理是通過不同階段和環境管理、計劃、調度和控制軟件構建的過程； 包括測試和部署軟件版本（Humble & Farley，2011）。

它本身就是一個相當大的話題，只有通過與開發團隊嘗試不同的迭代並匹配業務需求或功能發布，才能隨著時間的推移而完善。 我們將嘗試涵蓋用於管理組織發布列車的元數據管理、CI 構建和沙盒管理的行業實踐。

但什麼是發布火車？

發布列車是一種增量且可預測的功能交付技術。 它要求開發人員建立一個正式的流程來接受在開發環境中所做的任何更改並將它們部署到生產環境中。

發布火車大致可以分為三個部分：

• 元數據管理
• 持續集成構建
• 沙盒管理

元數據管理

元數據是提供有關其他數據的信息的數據。 Salesforce 通過其元數據 API提供豐富而強大的元數據模型。 您的應用程序元數據描述並包含一組方法，這些方法提供對您組織的源代碼和配置的編程訪問。

元數據 API 是在 Salesforce 中管理自定義的最佳方式。 它支持create 、 read 、 update和delete方法。 您可以使用變更集、Force.com IDE 和 Ant 遷移工具將元數據從一個組織遷移到另一個，因為它們都通過 API 提供遷移。

每種工具都有自己的優勢，選擇一種時需要考慮以下幾點：

表 1：元數據遷移工具比較

在 Force.com 平台上開發和遷移更改時，元數據 API 非常適合其用途。 但有一個小問題 - 並非所有 Salesforce 元數據都受元數據 API 支持。 官方文檔提供了不支持的組件列表。

如果您的組織正在進行元數據 API 不支持的更改，您必須確保在目標組織中手動複製這些更改。 跟踪這些更改的最佳方法是使用電子表格。 如果您必須採用這種方法，則始終建議一個人進行這些更改並進行跟踪。

這將是一個很好的通用列列表，可用於跟踪電子表格中的這些更改：

• 組件名稱
• 組件類型
• 更改所有者
• 功能描述
• 能力映射
• 與其他組件的依賴關係
• 審稿人/審稿人姓名
• 網址
• 組織名稱/ID
• 其他的建議

版本控制和持續集成

將更改遷移到生產應該是一個平穩的過程，因為它只是在測試和暫存環境中應用更改的重複。 儘管如此，事情總是有可能向南發展，然後你需要一個後備計劃。 保留組織元數據的備份非常重要，這就是版本控制和CI 構建的目的。

版本控制對於任何組織都是絕對必要的。 它允許開發人員以協作、高效和安全的方式工作。 管理多開發人員、多沙箱代碼開發和遷移是 Salesforce 的一項挑戰。 Salesforce 也有自己的發布和維護時間表。 這些更新提供了新功能，但它們可能會在元數據 API 中引入更改，這可能會破壞您的 CI 構建。 因此，除了開發人員相互覆蓋更改的情況外，版本控制還可以幫助您構建回滾策略。 當您的應用程序在 Force.com 上運行時，必須有一個回滾策略。

以下流程圖描述了版本控制和 CI 的實用結構。 我們將嘗試為您簡要介紹該圖表所代表的內容。

1. 開發人員將檢查他們在版本控制系統中的更改。
2. CI Server/Jenkins 會將最新的構建部署到 CI 沙箱並運行測試類。
3. 如果步驟 2 中的部署成功，則將更改合併到 QA 分支中。
4. 然後 CI 會將來自 QA 分支的最新提交部署到 QA 沙箱。
5. 如果 QA 因測試失敗而拒絕更改，則應再次執行步驟 1 到 3，直到 QA 清除更改。
6. 在更改通過 QA 測試後，更改將合併到 Master 分支中。
7. 來自 Master 分支的最新更改將部署到 Master 沙箱。

可以根據組織的需要選擇添加更多分支機構。 但上述結構適用於中型到企業級開發結構。

沙盒管理

要充分利用組織的 DevOps 流程，設置沙盒結構非常重要。 在深入探討之前，讓我們討論一下 Salesforce 為我們提供的不同類型的沙盒。

沙盒幾乎是一個生產元數據的精確副本。 沙盒通常用於開發、測試、登台和培訓目的。 沙箱有四種類型，在選擇沙箱時應適當考慮。 完整副本沙箱可能會花費很多錢！

下表列出了 Salesforce 對不同沙盒實施的限制。

表 2：限制比較

我們可以看到，價格並不是沙盒之間的唯一區別。

開發者沙箱有一天的刷新周期，適合開發，但只能容納200MB的數據，沒有生產數據。 相反，完整副本沙箱具有生產數據的精確副本； 甚至記錄ID都相同。 這可能使其非常適合測試和登台，但 29 天的刷新期使得在完整副本沙箱中獲取最新的生產元數據和數據變得困難。

下表作為選擇沙箱的經驗法則：

表 3：沙盒選擇用例

以下是中型項目採用的典型組織結構。 對於企業級客戶，組織結構變得更加複雜，但大致遵循以下模型。

Salesforce 開發通常在開發人員沙箱（紅色）中完成，並且更改被移動到集成沙箱（綠色），該沙箱通常是開發人員專業版或部分複製沙箱。 然後，來自多個集成沙箱的更改被向上移動到匯總沙箱（黃色），該沙箱應該是部分複製沙箱。

如果您的組織與需要執行集成測試和負載測試的第三方系統有任何集成，則需要有一組穩定的數據，不會因發布而改變。 所以，最好有一個完整的副本或部分副本沙箱。

然後將這些更改移至執行測試的集成測試沙箱。 然後將更改移動到暫存沙箱，它應該是一個完整的複製沙箱。 所有測試類都在部署之前運行。 應執行部署驗證以確保部署順利進行。

這個過程幫助我們確保更改通過多輪測試和多對眼睛。 它有一個嚴重的缺點，即需要大量時間來開發、測試和部署更改。

很多時候，迫切需要執行錯誤修復或補丁。 為了快速處理這些問題，應該保留一個開發人員沙箱，它將小補丁直接推送到匯總沙箱。

如前所述，沙盒幾乎是生產元數據的精確複製品，但並不完全。 有一個在沙盒中禁用的組件/功能的官方列表。

刷新沙箱時要考慮的另一件事是它只複製生產元數據和數據。 無法將元數據從一個沙箱複製到另一個沙箱，甚至無法在沒有任何元數據配置的情況下創建一個空沙箱（例如免費的開發人員組織）。 這有時會成為現實生活中的挑戰。 Salesforce 已計劃解決此問題，並且此功能可能很快就會普遍可用。

此外，如果您在生產中有一些敏感數據，您認為您的開發或測試團隊不應該訪問這些數據，您可以為完全和部分複制的沙箱創建沙箱模板。

部署時要考慮什麼

我們已經介紹了 Salesforce 生態系統中應用程序生命週期管理的行業實踐。 元數據和沙盒管理在創建部署包和有效負載方面發揮著非常重要的作用。 對於大型和復雜的 Salesforce 應用程序，版本控制有助於確保跟踪元數據更改，同時還有助於創建回滾策略。

沙盒管理對於大型或複雜項目至關重要。 但沙盒在 Salesforce 生態系統中的成本很高，無論是在財務資源還是時間方面。 制定沙盒管理策略對於發布管理過程始終至關重要。

我們將為您留下一些額外的要點，在您下次部署時請牢記：

1. 一次只能部署 10,000 個文件或 39 MB 的 ZIP 文件。 當然，如果有效負載太大，您必須將包分成多個部分，然後進行部署。
2. 如果由於request timeout錯誤而導致部署失敗，請嘗試從包中刪除對象、自定義字段和配置文件。 這些組件需要更長的時間來部署。
3. 如果更改了字段類型，或者角色層次結構發生了變化，那麼由於數據重新計算可能會出現很長的延遲，需要一些時間才能完成。
4. Salesforce 會鎖定係統中用戶當前正在使用的任何組件。 如果我們在這種情況下嘗試部署，部署將失敗。

希望此概述將在您的下一個 Salesforce 版本中對您有所幫助。

來源