本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 最佳實務
<a name="best-practices"></a>

實作新的 DevSecOps 機制時，請務必考慮各種程式碼撰寫來源，以及如何獲得授權或可能遭到封鎖。通常，工程師只能與其中一個來源連接。不過，引進新的機制可能會將新的作者身分來源帶入前線，或強調先前未考慮的來源的挑戰。讓我們更詳細地探索下列各個層面：
+ [應用程式團隊開發人員](code-authorship.md#application-team-developers) – 這些是負責核心應用程式程式碼的開發人員。他們必須有權視需要變更和更新應用程式程式碼，但其工作也必須與新的 DevSecOps 機制保持一致。
+ [中央基礎設施開發人員](code-authorship.md#central-infrastructure-developers) – 此團隊負責組織的核心基礎設施，例如雲端資源、聯網和安全性。他們必須參與將基礎設施定義為程式碼 (IaC) 和部署程序，以確保新機制無縫整合。
+ [第三方和開放原始碼基礎](third-party.md) – 使用第三方程式庫和開放原始碼元件很常見。不過，這些來源必須在新的 DevSecOps 機制中受到謹慎管理和保護。
+ [可重複使用的程式碼和成品](reusable-artifacts.md) – 提升可重複使用程式碼和成品的建立和使用可提高效率和一致性，但必須明確定義這些共用資源的擁有權和管理。
+ [共用儲存庫和貢獻](shared-repositories.md) – 透過共用儲存庫啟用協作式程式碼撰寫會很有幫助，但需要謹慎管理存取、合併政策和程式碼檢閱，以維護品質和安全性。
+ [IaC 的分支策略](branching-strategies.md) – Git 方法與常見的基礎設施設計模式不直接相容。傳統的分支策略可能需要針對 IaC 進行調整，以因應管理基礎設施的獨特挑戰。這可能包括開發專門的工作流程，以考慮基礎設施的狀態本質、偏離的可能性，以及在對即時環境進行變更時仔細協調。
+ [狀態管理](state.md) – 管理基礎設施的狀態在 IaC 中至關重要。適當的狀態管理可確保實際基礎設施符合定義的程式碼，並防止衝突或意外的變更。實作強大的狀態管理實務，例如使用遠端狀態儲存和狀態鎖定機制，對於維持一致性和防止多使用者環境中的衝突至關重要。
+ [安全性](security.md) - 在 IaC 和 DevSecOps 的環境中，安全性必須在基礎設施生命週期的每個階段整合。這包括保護 IaC 程式碼基礎本身、實作最低權限的存取控制、加密敏感資料，以及定期掃描基礎設施程式碼和產生的部署資源中的漏洞。自動化安全檢查和合規驗證應納入持續整合和持續交付 (CI/CD) 管道，以確保持續套用安全最佳實務。

設計可有效授權和支援不同團隊的 DevSecOps 機制，需要您識別程式碼作者的所有潛在來源，並了解他們的需求和挑戰。此方法有助於確保在整個組織中順利實作和採用新機制。

設計 DevSecOps 機制遠遠超過技術層面。DevSecOps 機制的設計和實作具有深遠的影響。負責的團隊必須仔細考慮文化、組織和人為因素。此考量有助於確保解決方案不僅符合技術需求，也為所有利益相關者培養正面、有生產力且吸引人的工作環境。追求正確的平衡對於長期成功和員工滿意度至關重要。

請考慮下列與設計和部署 DevSecOps 機制相關的案例：
+ **擴增開發人員與維護人員之間的差異** – 實作可讓急迫開發人員快速交付解決方案的系統，可能會無意中突顯維護人員明顯缺少工作。*維護者*是具有開發人員標題的個人，但其day-to-day責任已轉換為支援和穩定現有應用程式。維護者缺乏新的貢獻在歷史上可能較不明顯。這種情況可能會導致組織低估這些維護者的關鍵知識和專業知識，進而可能導致不滿和士氣下降。
+ **使用過度受管的解決方案來拒絕開發人員** – 建置高度受管的 DevSecOps 解決方案，讓急於開發人員使用可能會吸引維護者。不過，解決方案可能會讓組織需要的人員離開，以推動創新。強制開發人員學習其應用程式和程式設計語言以外的專屬 CI/CD 機制，可能是採用的重大障礙。高度受管的 DevSecOps 解決方案可能對有才能的開發人員來說是不利的。
+ **風險文化不相容和中斷** – 實作與組織現有工作方式在文化上不相容的 DevSecOps 機制，可能會產生嚴重的摩擦和阻力。如果機制的方法 （例如，與諮詢相比的方案） 不符合組織的文化，則可能不會採用它。因此，有些利益相關者可能會感到沮喪，並認為組織正在朝不必要的官僚主義邁進。