營運傑出 - DevOps 模式


深入瞭解結構良好的作業傑出 → DevOps 作法

模式

要尋找的位置良好的外觀
版本控制設定✅ 所有使用 Salesforce DX 專案結構以 Git 來源格式儲存的中繼資料,其中 .forceignore 設定為排除不相關的檔案;所有小組成員都會從中央存放庫複製
臨時組織用量✅ 開發人員從來源建立功能工作的臨時組織、將變更認可回版本控制,並在功能完成後捨棄臨時組織
認可訊息✅ 每個認可都包含清楚且簡要的訊息,說明變更的內容與原因;訊息遵循小組慣例 (例如「feat:」、「fix:」、「docs:」)
變更追蹤✅ 使用作者身分、時間戳記和顯示完全相符變更的 diff 控制,在版本中收集的每個中繼資料修改
程式碼審查流程✅ 所有繫結生產的變更會在合併前透過需要檢閱批准的提取要求進行流程;陳述性組態會收到與程式碼相同的檢查
回復程序✅ 先前版本可透過 Checkout 或回復作業從 Git 歷程記錄中復原;小組已記錄在非生產環境中測試的回復程序
稽核追蹤✅ 在版本控制支援合規性需求與安全性調查中保留的完整變更歷程記錄
分支策略✅ 一致的 Git 分支模型 (GitFlow、GitHub 流程或以 trunk 為基礎),適合小組大小與發行頻率;已記錄並強制執行
從以組織為基礎的移轉✅ 轉換至解決方案生命週期早期完成以來源為導向的開發,再根據以組織為基礎的開發增強習慣
.gitignore 組態✅ 存放庫不包含產生的檔案、使用者特定的設定和認證;僅包含意圖版本的來源檔案小組

反模式

要尋找的位置看起來怎麼壞
組織作為事實來源⚡️ 開發會直接在共用 Sandbox 中進行,其中中繼資料會依照考量匯出至版本控制;組織和版本控制會分歧,進而導致部署失敗
.gitignore 不夠⚡️ 存放庫包含產生的檔案、使用者特定的設定、大型二進位檔案或認證;會膨脹存放庫並造成安全性暴露的風險
模糊認可訊息⚡️ 如「修正錯誤」或「更新」等認可不會提供變更或原因的內容;會阻礙稽核調查和未來維護
大型非經常認可⚡️ 開發人員每週認可大型變更集,而非每日多次認可小增量;難以檢閱,難以區隔失敗
直接認可至主要⚡️ 開發人員會略過檢閱與驗證,將變更直接推送至主要/生產部門;減少品質缺口
無分支策略⚡️ 小組缺少一致的分支模型;開發人員建立任意分支名稱和合併模式;產生混淆和合併衝突
Git 中的二進位檔案⚡️ 認可至 Git 大型二進位檔案 (PDF、影片、歸檔) 膨脹儲存庫大小並使複製作業速度變慢
認可認證⚡️ 認可至版本控制的 API 金鑰、密碼、整合認證或安全性權杖;即使從後續認可移除後,仍會建立安全性漏洞
忽略合併衝突⚡️ 透過接受一方而不經分析解決的合併衝突;遺失變更或產生錯誤
無認可驗證⚡️ 小組永不驗證認可中繼資料是否實際代表預期的變更;中繼資料格式錯誤或非預期的變更會流失

模式

要尋找的位置良好的外觀
Developer Sandbox✅ 個別開發人員使用 Developer Sandbox 進行功能工作、單元測試和快速迭代;每個開發人員都有專屬的環境
Developer Pro Sandbox✅ 開發受管理封裝或需要更高儲存空間限制的小組會使用 Developer Pro Sandbox 進行協同合作
部分複製 Sandbox✅ 整合測試使用透過資料範本設定的「部分複製」Sandbox,其中包含代表資料樣本 (10,000 個記錄每個物件)
完整複製 Sandbox✅ 效能測試、類似生產的暫存和資料移轉驗證使用包含完整生產資料和組態的完整複製 Sandbox
資料敏感度控制✅ 完整複製 Sandbox 存取權僅限於需要生產資料的角色;適當時套用 Shield Platform Encryption 資料遮蔽以用於非生產使用
整合端點組態✅ 每個 Sandbox 層級都會連線至對應的測試端點以進行外部整合;生產整合一律不會從 Sandbox 連線
環境特定的組態✅ 整合結構使用自訂中繼資料類型或自訂設定來針對每個環境外部化端點 URL、認證和功能標記
重新整理後自動化✅ Sandbox 重新整理會觸發自動 Salesforce CLI 指令檔,以還原 Sandbox 特定設定,包括整合認證、測試資料種子、功能標記狀態和電子郵件傳遞性
重新整理排程✅ 已記錄並傳達 Sandbox 重新整理排程;在低活動期間計畫重新整理,以儘量減少小組中斷
資料範本✅ Partial Copy Sandbox 使用設計良好的資料範本,在維護參照完整性的物件之間選取代表資料
命名慣例✅ Sandbox 遵循明確的命名慣例,指出用途、擁有者和重新整理週期 (例如「dev-integration-q2」、「uat-release-2-4」)

反模式

要尋找的位置看起來怎麼壞
共用開發 Sandbox⚡️ 所有開發人員都在單一共用的 Sandbox 中工作,以覆寫彼此的變更;對可部署狀態造成混淆
過時的 Sandbox⚡️ 數月未重新整理的 Sandbox 與生產組態有明顯差異;在不具代表性的環境中進行測試會導致部署失敗
沒有完整複本的資料管理⚡️ 完整複製包含生產 PII、財務資料、HIPAA 資料的 Sandbox,無須存取控制或資料遮蔽即可存取整個開發小組
Sandbox 的生產整合⚡️ Sandbox 直接連線至生產整合端點,造成影響生產資料或外部系統的測試交易風險
手動後續整理組態⚡️ Sandbox 重新整理需要數小時的手動重新設定還原設定;額外負責不建議視需要經常重新整理 Sandbox
無 Sandbox 文件⚡️ 小組缺少有關 Sandbox 用途、重新整理排程、資料內容或存取程序的文件;開發人員猜測要用於何種用途的環境
單一環境類型⚡️ 小組只會針對所有用途使用一個 Sandbox 類型 (通常是 Developer 或 Full Copy);忽略每個活動適當 Sandbox 策略的優點
Sandbox 儲存⚡️ 已配置給個人或專案的 Sandbox,且不再在不再需要時發行;儘管有可用的授權,但人工稀缺
測試資料不足⚡️ Sandbox 中的測試資料不代表生產資料特性 (數量、關係、邊緣個案);在不實際環境中測試會忽略生產問題

模式

要尋找的位置良好的外觀
來源認可階段✅ 開發人員使用明確的認可訊息將變更認可至 Git 中的功能分支,說明內容與原因
靜態分析階段✅ Salesforce Code Analyzer 會掃描 Apex 安全性漏洞 (OWASP 熱門 10 個項目)、效能反模式 (迴圈中的 SOQL、迴圈中的 DML)、程式碼品質問題 (複雜性、重複性) 和管理員限制風險;以秒為單位執行,提供立即的回饋意見
單元測試階段✅ Apex 測試會在短暫臨時組織或專屬整合 Sandbox 中執行驗證業務邏輯和管理員限制合規性;適當隔離的測試會在 5 分鐘內完成
驗證部署階段✅ 使用具有 –checkonly 標記的 Salesforce CLI 將中繼資料部署至整合 Sandbox,以執行僅限驗證部署的執行測試,而不認可變更
整合測試階段✅ 自動測試會根據使用測試資料管理的共用整合環境,驗證多元件工作流程、外部整合契約、平台事件流程和非同步處理鏈
安全性掃描階段✅ 額外的安全性工具會掃描硬式編碼認證、弱點相依性、CRUD/FLS 違規和規範原則違規;重要發現損毀組建
UAT 部署階段✅ 傳遞所有自動化門的變更會部署至使用者接受度測試環境以進行業務驗證;部署可能會自動化或需要根據變更風險手動批准
生產部署階段✅ UAT 批准後,系統會透過自動按一下執行、全方位記錄和立即回復功能,將變更部署至生產環境
銷售管道執行時間✅ 一般變更可快速提供回饋意見時,端對端銷售管道會在 15 分鐘內完成;大型部署或廣泛測試套件的時間較長
建立成品✅ Pipeline 會保留部署封裝、測試結果、安全性掃描報告和執行記錄以進行合規性和疑難排解
銷售管道工具✅ 小組使用 Salesforce DevOps Center 進行平台原生 CI/CD,或與外部平台整合 (GitHub 動作、GitLab CI、Azure DevOps、CircleCI、Jenkins、Copado、Gearset、AutoRABIT)
失敗通知✅ 銷售管道失敗會觸發認可作者和相關管道的通知,並使用可快速修復的診斷內容
分支保護✅ 保護需要在合併前通過 CI 檢查和已批准審查的主要/生產分支;防止直接認可
環境促銷✅ 透過每個階段的驗證,透過定義的促銷路徑 (dev → integration → UAT → production) 來變更流程

反模式

要尋找的位置看起來怎麼壞
手動部署⚡️ 透過變更集或 Salesforce CLI 指令手動部署的變更 (步驟不一致);人力錯誤、錯過步驟、缺少稽核追蹤
無靜態分析⚡️ 銷售管道略過 Salesforce Code Analyzer 或類似工具;安全性漏洞、效能反模式、程式碼品質問題達到生產環境
測試不足⚡️ 銷售管道只會驗證最低 75% 涵蓋範圍,而無須執行整合測試或驗證主要使用者流程;迴歸會跳過
無安全性掃描⚡️ 銷售管道絕不會掃描硬式編碼認證、易受攻擊的相依性或 CRUD/FLS 違規;在生產或安全性檢閱中發現的安全性問題
緩慢銷售管道執行⚡️ 端對端銷售管道花費 45-60+ 分鐘的時間,不鼓勵頻繁認可並減緩回饋意見迴圈;開發人員認可的頻率較低,累積更大的變更
忽略的銷售管道失敗⚡️ 小組會忽略或覆寫銷售管道失敗以符合期限;品質門會變成劇院而非實際控制
無測試環境等同⚡️ CI/CD 會在與生產環境不同的組態、限制或資料特性中進行驗證;通過驗證不會保證生產成功
遺失回復功能⚡️ 銷售管道會自動化部署,但不會提供自動回復;由於部署錯誤而復原,需要手動緊急程序
無部署記錄⚡️ 部署在未進行全方位記錄的情況下執行;疑難排解失敗或稽核部署變得難以執行
全部或無全部測試⚡️ 無論變更為何,管道都會針對每個變更執行所有測試;即使是文件更新的 30 分鐘測試套件也會執行

模式

要尋找的位置良好的外觀
功能標記✅ 透過在自訂中繼資料類型或自訂設定組態後停用的功能部署高風險變更;可在生產環境中進行測試,而無須讓使用者接觸、逐步首展至區段、A/B 測試,以及透過組態變更立即回復
功能標記範圍✅ 專為影響重要業務流程、效能敏感性作業或新整合模式的高風險變更保留的功能標記;並非所有功能都需要標記
Canary 部署✅ 業務關鍵變更會先發佈至小型使用者子集 (5-10% 透過權限集或使用者屬性篩選);在展開首展之前,會密切監視 24-48 小時的 canary cohort,以測量成功率、效能和錯誤率
部署視窗✅ 在低用量期間排程的部署,由「事件監視 API」用量記錄通知,其中顯示實際的流量模式;避免使用峰值、月份結束、季度結束、主要業務事件
部署通訊✅ 利害關係人會收到部署時段的預先通知,包括預期的持續時間、受影響的功能和回復決策時間表
回復程序✅ 針對每個部署類型已記錄和測試的回復程序;小組可以視需要在 30 分鐘內執行回復
結轉測試✅ 在確保存在復原功能的重要部署之前,在非生產環境中驗證的回復程序
部署驗證✅ 部署後的煙草測試會在發行後立即驗證重要使用者流程、整合端點和關鍵功能
變更協調✅ 當變更跨多個系統或需要跨 Salesforce 和外部平台同步化的版本時,協調的部署策略
部署期間監視✅ 在部署時段和部署後觀察期間 (24-48 小時) 啟用增強型監視,監視錯誤率高峰、效能降低或使用者流程失敗
整合的藍綠色模式✅ 在 Salesforce 前線的外部服務使用藍綠色部署,維護兩種類似生產環境,先部署為未啟用,然後在驗證後切換流量

反模式

要尋找的位置看起來怎麼壞
Big Bang 部署⚡️ 包含許多功能、重新設定及同時部署變更的大型版本,沒有漸進式推出;失敗會立即影響所有使用者
峰小時部署⚡️ 當用量最高且問題的使用者影響最大化時,排程在高營業時間 (中日、月末、季末) 期間的發行
無回復計畫⚡️ 部署在未經記錄和測試過的回復程序的情況下進行;當出現問題時,小組會捲動以找出復原方法
功能切換為追蹤⚡️ 當發生問題時會反應地新增功能標記,而非主動針對高風險變更進行設計;將回復選項限制為完整部署撤銷
無部署驗證⚡️ 變更已部署至生產環境,但未進行後續部署煙霧測試;小組假設部署成功且繼續進行;使用者在數小時後發現的問題
未經測試的回復程序⚡️ 已記錄但未在非生產環境中測試的回復程序;實際事件發生期間,程序會失敗或證明不適當
同時多系統變更⚡️ 在未進行同步化或相容性測試的情況下部署 Salesforce 和外部系統之間的協調變更;建立整合失敗
無監視增強功能⚡️ 部署在部署期間會在沒有增強型監視的情況下進行;透過使用者抱怨而非主動警示偵測到的問題
週末部署⚡️ 當通話涵蓋範圍降低且廠商支援可用性受到限制時,在週五晚上或週末部署的主要版本

模式

要尋找的位置良好的外觀
單元測試涵蓋範圍✅ 有意義的測試涵蓋範圍,驗證業務規則、邊緣個案、錯誤路徑和管理員限制方法;明顯超過 75% 的最低需求
單元測試品質✅ 測試會驗證業務邏輯,而非平台功能;正確撰寫的單元測試快速 (毫秒)、隔離 (無共用狀態) 和專注 (每個測試都會驗證一個行為)
測試資料策略✅ 測試針對常見測試資料使用 @TestSetup 方法;盡可能避免在測試中使用 SOQL 查詢;使用 Test.loadData() 載入靜態資源
模擬外部相依性✅ 單元測試使用測試長條和相依性插入模擬外部呼叫,讓執行快速而不需要實際的 HTTP 要求
整合測試✅ 使用代表測試資料在 Sandbox 中執行的觸發、流程、平台事件、批次工作和外部呼叫之間的驗證互動
整合測試可靠性✅ 整合測試可重複且可決定性;透過如平台事件重新執行識別碼和批次工作輪詢等同步化機制解決偶發失敗
端對端測試✅ 自動瀏覽器測試 (Selenium、Playwright、Provar) 會在使用者互動時完全驗證業務關鍵流程的完整使用者旅程。
E2E 測試焦點✅ E2E 測試由於執行速度緩慢 (每個測試分鐘) 和 UI 變更造成的維護負擔較高,因此專注於最高值的使用者路徑
載入測試✅ 使用 Salesforce 載入測試服務或第三方工具在實際的同時使用者載入和資料量下驗證的效能;顯示管理員限制問題、鎖定爭用、效能降低
載入測試頻率✅ 載入測試會在主要版本之前執行,並定期執行 (每季),以驗證目前生產量 3x-5x 的效能
測試金字塔圖✅ 平衡測試分佈:許多單元測試 (百分鐘)、較少的整合測試 (十幾分鐘)、較少的 E2E 測試 (20 分鐘以下);在基端快速回饋意見,在頂端全面驗證
測試隔離✅ 測試彼此不相依;可依任何順序執行;每個測試都會使系統保持在清除狀態,或使用 @TestSetup 作為一致的起點
負測試個案✅ 測試會驗證錯誤處理、驗證規則強制執行、強制執行權限,以及在不良狀況下大幅降級
管理員限制測試✅ 測試會特別驗證接近管理員限制的行為,包括 SOQL 查詢限制、DML 限制、CPU 時間、堆疊大小
連續測試執行✅ 測試會在透過 CI/CD 管道的每個認可時自動執行;失敗的測試會防止部署至較高的環境

反模式

要尋找的位置看起來怎麼壞
測試涵蓋範圍⚡️ 僅撰寫以達到 75% 最低涵蓋範圍的測試,而無須驗證業務規則或邊緣個案;無須判斷或測試不明確程式碼路徑的測試
測試平台功能⚡️ 測試會驗證 Salesforce 是否儲存記錄或 SOQL 查詢的運作,而非驗證業務邏輯;會浪費在平台保固上的精力
無模擬策略⚡️ 單元測試對外部系統進行實際呼叫;測試速度緩慢、對外部系統可用性不佳,且耗用 API 限制
偶發測試失敗⚡️根據執行時間、資料狀態或測試執行順序,測試無法預期地通過或失敗;小組學習忽略失敗並重新執行,直到測試通過為止
無整合測試⚡️ 僅存在單元測試;小組永遠不會驗證觸發、流程、平台事件和批次工作是否正確一起運作
僅手動 E2E 測試⚡️ 每個版本之前手動驗證的重要使用者流程;沒有自動化的 E2E 測試;當手動測試錯過案例時在生產環境中發現的迴歸
無負載測試⚡️ 在實際的同時負載下未驗證的效能;在生產環境中發現的管理員限制問題、鎖定爭用或效能降低
測試資料相依性⚡️ 測試取決於組織中存在的特定記錄或假設特定使用者組態;當重新整理 Sandbox 或組態變更時會中斷
無負數測試個案⚡️ 測試只會驗證快樂路徑情況;絕不測試錯誤處理、強制驗證或權限檢查;無法發現失敗模式
略過測試⚡️ @isTest 中加上註解且略過而非修正的失敗測試;測試套件會隨著忽略更多測試而隨著時間降級

模式

要尋找的位置良好的外觀
檢閱涵蓋範圍✅ 所有繫結生產的變更都會透過需要合併前批准的提取要求進行程式碼審查;包括 Apex、Aura、LWC、流程、驗證規則、權限集、共用規則
檢閱條件檢查清單✅ 涵蓋安全性的明確檢查清單 (CRUD/FLS 強制執行、輸入驗證)、效能 (大量處理、SOQL 最佳化)、管理員限制合規性 (處理模式、迴歸防止)、可維護性 (命名、文件、複雜性)、測試涵蓋範圍 (有意義的測試、邊緣個案)、結構一致性 (設計模式、疑慮分隔)
檢閱大小限制✅ 提取要求會保留在 400 行內的有意義變更,以便進行完整審查;大型功能會拆分為可個別檢閱且可獨立部署的較小增量變更
檢閱時間✅ 在一個工作日內完成的審查可維持開發動力並提供快速回饋意見;延遲審查會造成內容切換的負擔
自動預覽檢查✅ 靜態分析、單元測試和安全性掃描會在人類審查要求之前自動執行;自動檢查會抓住機械問題,讓審查者專注於設計和業務邏輯
散佈審查責任✅ 跨小組分配程式碼審查責任,避免瓶頸和共用 Knowledge;初級開發人員在審查期間檢閱高級程式碼並解釋自己的程式碼
檢閱註解品質✅ 檢閱者提供具體且可採取動作的回饋意見,並有合理理由;區分必要變更 (封鎖問題) 與建議 (善用改善)
檢閱文件✅ 提取要求描述說明變更的項目、變更的原因、完成的測試項目,以及任何特殊的部署考量事項或回復程序
宣告組態檢閱✅ 流程、驗證規則和權限變更會收到與程式碼相同的審查嚴格性;組態是結構式且值得仔細檢查
註解的後續追蹤✅ 合併前討論的所有檢閱註解;已回答的問題、已實作的變更,或為未採用建議的原因提供的理由

反模式

要尋找的位置看起來怎麼壞
無程式碼審查⚡️ 變更會直接認可至生產部門,而無需對等審查;移除主要瑕疵偵測機制
橡膠戳記⚡️ 檢閱者會在幾秒內批准提取要求,而不實際檢查變更;檢閱會變成核取方塊合規性,而非品質門
單一檢閱者瓶頸⚡️ 僅有一位資深開發人員獲授權檢閱程式碼;建立瓶頸與單一失敗點;集中而非分散 Knowledge
大量提取要求⚡️ 包含跨多個功能數千行變更的提取要求;無法徹底檢閱,進而進行概觀檢查
延遲審查⚡️ 提取要求會在幾天或幾週內保持未檢閱狀態;開發人員會失去內容並移至其他工作;當開發人員切換心理內容時,即會出現檢閱註解
無檢閱條件⚡️ 小組缺乏檢閱者應檢查的明確條件;檢閱品質因檢閱者而異;有些檢閱者專注於樣式,有些則專注於邏輯,沒有全面的檢閱者
未經測試的檢閱⚡️ 檢閱者僅根據程式碼檢查批准變更,而無須提取分支和本機測試或驗證自動測試通過
忽略的自動檢查⚡️ 檢閱者會批准提取要求,儘管靜態分析、安全性掃描或單元測試失敗;失敗自動化品質門的目的
敵對審查文化⚡️ 評論會變成個人批評或競爭運動,而非協同合作品質改善;不鼓勵學習和心理安全
無宣告審查⚡️ 流程、驗證規則、權限集和共用規則會在 Apex 程式碼收到檢查時未經檢閱地部署;在陳述性組態中產生品質缺口