本篇參考：
https://help.salesforce.com/s/articleView?id=sf.deploy_sandboxes_intro.htm&type=5
https://guides.github.com/introduction/flow/
https://developer.salesforce.com/docs/atlas.en-us.224.0.sfdx_dev.meta/sfdx_dev
一. Application Lifecycle Management(ALM)
我們都知道，聊起來salesforce的實施，想到的前三個詞中大概率就會包括敏捷這個詞，當然每個人站在不同的位置對這個詞就有不同的含義。對於開發人員來說，敏捷可能意味著2、3週一次上線。對於專案管理來說，可能需要根據客戶的需求去分析去根據優先順序以及resource情況排sprint計劃等等。敏捷不代表沒有流程性，相反敏捷對於團隊成員的整體能力以及流程要求更高。Salesforce提供了一套應用的生命週期的管理流程以及針對這種管理模型對應的三種開發模式。我們可以通過下圖檢視到一個應用的生命週期流程涉及到的階段，各階段含義的相關介紹如下。
1. 計劃釋出階段：一個專案啟動以後，不是開發直接幹就完事了，而是應該先由一個計劃來開始我們的自定製或者開發的專案。收集需求並進行分析，讓產品經理（或同等級別的人員）建立設計規範，並與開發團隊共享這些規範以供實施。隨著專案在ALM週期中的進展，確定團隊需要的各種開發和測試環境。
2. 開發階段：在開發的sandbox上按照設計文件進行程式的開發工作。使用宣告性工具（Process Builder、Custom Object Wizard和有UI介面的其他的功能）和程式設計工具（develop console、sublime 或 visual code studio等）的適當組合在Lightning平臺上開發。
3. 測試階段：在我們和其他人的工作整合以前，需要先檢查一下我們的更改內容是否按照預期來工作。在開發步驟中使用的相同型別的環境中進行測試，但要將開發環境和整合測試環境分開。通過下圖可以看到，當我們在測試階段出現一些問題情況下，我們應該針對開發階段以及測試階段有一個可以自動測試的持續的整合過程（CI）。
4. 構建釋出階段：將當前release在開發階段建立或修改的所有資產聚合到一個用來部署到生產環境中的定製包中。從這一點開始，關注你將要釋出的team所有人的內容，而不是個人的貢獻。
5. 測試釋出階段：測試實際要部署的內容，但要在儘可能模擬生產的環境中安全地進行測試，使用實際數量的代表性生產資料。將測試環境與所有外部系統連線起來，以模擬生產系統的整合點。在此步驟中執行完整的迴歸和最終效能測試。與一小群經驗豐富的測試人員一起測試發行版（一種稱為使用者驗收測試的技術UAT）。
6. 釋出階段：完成測試並達到質量基準後，可以將定製部署到生產環境中。培訓員工和合作夥伴，讓他們瞭解變化。如果某個版本對使用者有重大影響，請為培訓使用者建立一個具有真實資料的單獨環境。
當然，上述說的內容是一個比較common的，不同的場景可能大步驟還是這樣，執行起來好多就可以忽略。比如一個專案特別小，就是一個CR，做一做 report ，修復修復bug這種打補丁相關的專案，我們就可以省略了釋出階段的使用者培訓這個步驟。我們的一個釋出版本可以根據改動大小分成三種不同的種類：
- Patch：這種打補丁的釋出的種類通常用於Bug修復和簡單更改。簡單的更改包括報告、儀表板、列表檢視和電子郵件模板。
- Minor（較小變更）：影響有限的更改，例如影響單個業務流程的新workflow或者trigger。這些版本通常需要測試，但只需要有限的培訓和更改管理。通常，一個團隊會在幾周內為一個小版本交付更改。
- Major（較大的變更）：具有重大影響的更改，包括具有一個或多個依賴項的更改。因為這些版本會極大地影響使用者體驗和資料質量，所以它們需要徹底的測試、培訓和仔細的更改管理。主要版本通常每季度釋出一次（Salesforce每年釋出三次）。
二. 開發模式淺談
Salesforce 提供了三種開發模式或者開發模型。Change Set 開發模型 、 Org 開發模型 以及Package 開發模型。當然，我想大部分人對第一種開發模型很熟悉，事實上，好多的國內專案現在還在用 change set進行部署管理。那麼這三種模型有啥使用場景以及優缺點呢？這裡進行一個簡單的描述，後續看一下是否有必要每個進行單獨的講解。
1. Change Set Development Model
這種應該是大部分人都比較熟悉的一種模式。我們在專案啟動到專案上線(上線後維護)，通常的階段會是：
Dev: 專案的開發階段，進行程式碼的開發等。
SIT: 專案的系統整合測試，進行多端系統的整合的測試。
UAT: 使用者接受測試，實際的客戶進行功能測試。
PROD: UAT客戶驗收以後，實際生產環境。
HOTFIX：生產環境出現緊急問題的補丁的sandbox。
我們實際做專案時，UAT以前如果有程式碼質量review等操作，基本上要在上UAT以前進行此操作。因為不同的sandbox需要履行的事情不同，所以對sandbox的型別的使用也各不相同。PROD沒有說的必要，肯定用生產環境，不涉及到 sandbox的選用。 FULL環境理論上需要和生產環境的配置以及資料等等相同，進行實際生產環境的mock以及進行大資料量的效能測試等，所以UAT環境需要使用 FULL SANDBOX。SIT 需要和各個外部環境進行整合測試，在保證資料量，功能等情況，以及可能需要帶入一些實際生產資料等考慮，通常SIT會使用 Partial Copy Sandbox，使用時需要考慮他的重新整理的週期以及儲存量等是否可以滿足使用。HOTFIX通常都是專案 Release以後部署完生產環境以後要儘快的弄成和生產環境配置相同，所以可以使用 Developer Pro Sandbox，好處是重新整理的週期是1天，即使上線以後出現了一些問題，也可以通過 hotfix去緊急對應，然後以 hotfix進行部署上線。
Change Set Develop Model使用的優缺點：
優點：
1. 宣告式操作，不管是source sandbox的 outbound change set還是target sandbox的 inbound changeset，只需要在UI上面操作，動一動你的手指頭便可以搞定。
2. 對於有關聯關係的元件，部署簡單。類之間相互引用等這種有級聯關係的，使用 change set部署很容易。
缺點：
1. 如果公司有多個BU，然後有多個生產環境，並且生產環境需要部署同樣的東西， change set方式便會愛莫能助因為 changeset 基於 sandbox的 deployment setting去設定 source and target關係，也只能繫結到一個production環境，涉及到多個生產環境無法實現。
2. 宣告式的方式就註定涉及到大量的元件的部署，會相對不方便。
3. 無法實現自動部署，因為只有人工的點選部署按鈕，才可以進行資源的部署。
4. profile / permission set等部署會很棘手，這兩樣部署以前需要檢視文件中針對這兩個內容的特殊的注意事項，所以老人好多時候就說，如果資源不多，profile就不部署了吧，直接手動生產配置。
5. 追蹤元件資源的變更也會很麻煩。
所以我們使用 change set develop model通常用於minor的這種變更，比如針對 trigger / apex class等一些變動，或者增加 修改一個 record type相對應的變更等，可以使用 change set。
2. org development model
相對於 change set模式的缺點， org developmet model就特別適合一個大型專案的運作了。 org development model優點很多，但是針對 change set模式最好的兩個特性： 自動部署 & 自動追蹤變更。org development model有一個很重要的點就是 VCS（version control system）。國內專案因為體量等原因實際用起來的專案不是特別多，目前對日以及對歐美專案基於 org development model的相對挺多的。印象中之前做過的一個對日專案，專案有幾個特性。
1. 專案週期很長，一期專案從0到1的上線持續了1年到1年半的時間；
2. 開發人員很多，相對複雜。每個sprint中針對機能可能會有一些修改或者回滾操作。針對機能的每個版本變更很在意，後續有回滾或者基於哪版繼續開發機率高；
3. 每個人一個 sandbox進行開發，使用 git作為程式碼倉庫，開發部署完以後，需要重新部署到各自開發人員以及SIT等環境的sandbox容易並且耗時少，最好可以實現自動化部署。
當然，其他的特點還有很多，上述只是羅列了3點，即： 週期長，版本管理重要，部署要方便。這種場景使用 org development model便會極為的方便，針對後續部署時，哪些內容上，哪些內容不上，複雜的迭代場景也會更加的友好。
當然，org development model也不是萬能的，目前salesforce不是所有的metadata都支援使用metadata api或者CLI來部署，針對 org development model不支援的場景，仍然需要走 manual 的操作。這裡引申一道題：
Universal Containers has an active production org; and they are planning to release some new features to it next month. The team is working to prepare .1 deployment plan and reached out to the technical architect for inputs on rollback strategy. What should a technical architect recommend? A. Backup the existing metadata using the ANT Migration Tool. To roll back deployment, deploy again to production using backed up metadata. B. Create a sandbox from production to take the backup of existing metadata. To roll back deployment, manually delete new components and then deploy again to production using metadata from this sandbox. C. Create a sandbox from production to take the backup of existing metadata. To roll back deployment, use destructivechanges.xml to delete new components and then deploy again to production using metadata from this sandbox. D. Backup the existing metadata using ANT Migration Tool. To roll back deployment, manually delete new components and deploy again to production using backed up metadata.
我認為這道題應該選擇C的。之所以ANT MIGRATION TOOL去備份 metadata不選擇，就是有一些是不支援部署的，全量備份還是需要重新整理 sandbox去備份，更穩妥。如果有不同理解並且認為我的答案是錯的，歡迎相互交流。
3. package development model
我們在實際專案中使用sandbox的缺點是什麼呢？我們新起了一個專案，特別小。可能就是寫一個 trigger更新一個欄位等等。那開發環境的 sandbox因為很久沒有重新整理，這個表的欄位不全，怎麼辦，現在的做法最穩妥的就是重新整理一下 sandbox。 這種場景引申一下，所以我們會發現。如果涉及到 sandbox資源和生產不完整的場景，好多時候我們開發以前的第一步都是要先重新整理sandbox保證兩邊相同，隨著生產環境的資源以及儲存等區別以及sandbox template type的區別，重新整理時間並不完全確定，以 developer Pro sandbox為例，重新整理週期是1天。當然，如果生產環境資源少，可能很快就重新整理完成，但是如果多的話，可能需要1天。如果我們的工作可能半天就搞定，但是需要等1天的重新整理時間，是不是很得不償失。 salesforce提供了一個新的開發模式，基於包的開發模式，也不需要建立sandbox，可以直接建立 scratch org來進行資源獲取以及資源部署。
針對 package development model，推薦一些中文的連結：
https://www.jianshu.com/p/651925a1dd03
Salesforce LWC學習(一)Salesforce DX配置
https://www.jianshu.com/p/aab15e748e48
這裡有對 scratch org / package development model以及 salesforce DX配置的一些簡單介紹。
總結：篇中只是針對這三種模式很淺的介紹， change set相對容易一些，針對 org development model 以及 package development model實際使用中，特別是大型的專案使用場景下，配置項以及細節考慮特別多。對這些部署模式感興趣的可以檢視頭部的相關的官方文件去進行深入的學習。篇中有錯誤地方歡迎指出，有不懂歡迎留言。