本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 建置內部開發人員平台的原則
## 採用產品思維
成功的關鍵原則是將內部開發人員平台視為一般應用程式或具有一組功能和藍圖的產品。這可協助您定義內部開發人員平台將提供的一組工具和程序。此外，它還可協助您識別如何衡量如何成功採用平台功能，例如改善軟體交付週期或減少操作事件的數量。透過採用產品思維，您可以量化內部開發人員平台提供的價值，並確保它正在實現您的原始目標。
## 專注於您的客戶
另一個重要的原則是識別您內部開發人員平台的客戶。基本上，您的客戶就是您的開發人員。了解您的客戶非常重要，因為平台的目標是滿足開發人員的需求，並在他們所在的位置滿足他們。這表示平台藍圖應該對齊。根據開發人員的需求排定功能的優先順序。
## 隨需自動提供自助服務功能
成功的另一個原則是，平台應該透過自助服務機制提供其功能，以隱藏開發人員的任何複雜性。無論團隊使用的是雲端供應商還是 Amazon Elastic Kubernetes Service (Amazon EKS) 之類的運算服務，開發人員都不應該關心這些詳細資訊。內部開發人員平台需要提供簡單的界面，例如圖形化使用者介面 (GUI)、API 或命令列界面 (CLI)，以協助開發人員交付價值。若要提供成功的自助式機制，請務必從正確的範本設計開始。範本應包含自動化功能交付所需的最低參數。它應該自動化測試程序，以協助開發人員滿足品質閘道和安全要求，而且還應該在功能部署後提供有關關鍵指標的意見回饋。
自助式機制有助於減少開發人員的認知負載。它減少了開發人員必須用來部署到生產環境的 服務和工具數量。簡化使用者體驗可協助您將平台行銷給更多團隊。每當開發人員想要使用時，請務必確保內部開發人員平台可隨需使用。然後，您必須準備在加入更多團隊時擴展內部開發人員平台。
## 使用選用的 並啟用特定功能的使用
並非所有團隊都可以在第一天使用內部開發人員平台。例如，有些團隊使用容器來現代化工作負載，有些則使用無伺服器解決方案。內部開發人員平台從支援一個旅程開始，並隨著時間開發更多功能。選用使用平台及其功能，直到平台擴展且更成熟的模式準備好為開發人員提供服務。
這並不表示團隊無法使用內部開發人員平台。有些團隊仍然可以管理其工具和程序，也可以採用內部開發人員平台的特定功能。例如，團隊可能會採用 CI/CD 管道來準備基礎設施。平台透過減少管理基礎設施所需的時間來提供價值，協助開發人員專注於其應用程式程式碼。
## 定義符合您安全標準的黃金路徑
黃金路徑是內部開發人員平台應提供的最基本功能。這是因為黃金路徑包含最佳實務和標準，協助您的開發人員在幾分鐘內開始使用。從開發到可觀測性，黃金路徑可簡化軟體開發生命週期 (SDLC) 體驗。它們可自動化開發人員使用的大部分功能，例如原始程式碼儲存庫、測試、部署和可觀測性。
不過，黃金路徑不僅在於提供自動化模式。它們也提供控管，以協助開發人員以符合組織合規要求的安全方式部署工作負載。開發人員的主要挑戰之一是在開發生命週期的早期解決安全性問題。因此，請務必將安全性掃描和policy-as-code工具作為黃金路徑中的階段來移除此挑戰。這可以為開發人員提供早期意見回饋，並提供部署的控管架構。
設計黃金路徑時，請勿讓程序變得不必要的困難。目標是不在一開始就自動化 SDLC 中的每個階段。目標是提供抽象層，可隱藏使用不同工具或基礎設施的所有複雜性。這有助於開發人員快速入門並專注於功能開發，而不是與基礎服務互動。黃金路徑的範例是範本，開發人員可以提供一些指向原始程式碼儲存庫的參數。內部開發人員平台可自動化所有其他階段，例如測試、安全性、掃描和部署。
## 記錄並簡化加入體驗
內部開發人員平台成功的另一個重要原則是文件。內部開發人員平台需要包含文件，為開發人員提供easy-to-follow的入門指南。本指南應著重於開發人員如何為專案做出貢獻，而不是解釋界面或平台的隱藏複雜性。例如，入門指南不應描述平台在 Amazon EKS 上執行，或描述 AWS 帳戶 的基準。本指南應說明服務相依性和黃金路徑。對於微服務架構，它也可以說明服務的連線方式。
文件和簡單的入門體驗可將開發人員了解和使用內部開發人員平台所需的時間降至最低。如果您想要測量文件的有效性，*程式碼變更磁碟區指標*會很有用。此指標可以提供有關誰進行最大數量的程式碼變更，以及哪些儲存庫在一段時間內最活躍的資料。您可以在開發人員或儲存庫層級收集資料。