本篇參考：
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實際使用中，特別是大型的項目使用場景下，配置項以及細節考慮特別多。對這些部署模式感興趣的可以查看頭部的相關的官方文檔去進行深入的學習。篇中有錯誤地方歡迎指出，有不懂歡迎留言。