階段 3 - 目標環境設定

5 分鐘

您正在為您的團隊每天努力奠定基礎。這裡的決策會影響他們在身份驗證、協作和軟體交付方面的體驗。專注於清晰度、一致性，並做出不會讓用戶感到驚訝的選擇。

驗證環境類型和身分驗證

GitHub Enterprise Cloud 提供具有不同功能和需求的不同環境類型。

環境類型

瞭解差異有助於您驗證您的設定：

標準 - 具有單一登入覆疊的傳統 GitHub 帳戶
企業管理使用者（EMU） - 完全由企業管理的身分識別
資料落地：具有額外區域資料裝載保證的 EMU

驗證您目前的設定

使用下列命令來檢查您的環境狀態：

# Check SAML SSO status for enterprise
gh api /enterprises/{enterprise}/settings/saml

# Check SAML SSO status for organization
gh api /orgs/{org}/settings/saml

# Verify your user authentication
gh api /user --hostname github.com

# Check enterprise configuration flags
gh api /enterprises/{enterprise} --jq '{login, managed_users_enabled, data_residency_enabled}'

安全性狀態驗證

在移轉之前，請確定這些安全性設定已就緒：

SAML SSO - 為您的企業或組織設定並啟用
小組同步 - 如果您使用身分識別提供者群組，則會啟用
SCIM 佈建 - 已啟用於 EMU 或資料駐留環境
雙因素驗證 - 在整個組織中強制執行
稽核記錄 - 已啟用合規性和安全性監視

在繼續移轉之前，請先解決此安全基礎中的任何差距。在移轉過程中，驗證和身分識別問題的複雜性會成倍增加。

組織與團隊設計

從您的企業如何協作開始，而不是工具的預設值。選擇團隊會認可的結構。

組織模式

請考慮以下常見方法：

單一組織 - 更簡單的原則和更輕鬆的跨團隊共同作業（建議在大部分情況下）
多個組織 - 針對不同的治理需求、合規性界限或規模考慮
混合式方法 - 從單一組織開始簡單，然後在業務需求需要時再拆分

團隊結構原則

反映現實的設計團隊：

盡可能與您的身分識別提供者（IDP）同步處理 - 如果可用，請透過 EMU SCIM 或其他 SCIM 型整合，將 IDP 群組直接對應至 GitHub 小組。這可確保成員資格與您的事實來源保持同步，減少手動開銷，並支援合規性/稽核需求。

這很重要

如果 SCIM 無法使用，請記錄一個備援方案（例如手動管理或定期透過 API 推動的同步），以防止漂移。

反映實際的團隊界限 - 平台、產品和安全團隊應對應至組織結構圖中的現有架構。對於跨職能群組（例如事件回應、網站可靠性或公會），請將 GitHub 小組分層在 IDP 同步群組之上，而不是中斷同步模型。
保持許可權可預測 - 例如：開發人員取得寫入存取權、系統管理員取得系統管理員存取權、安全性小組取得分類存取權

使用 CODEOWNERS 來明確所有權

讓程式碼擁有權可見且可操作，以便審查自動且可預測地進行。

備註

如今，許多企業不會有一致的所有權做法。
將 CODEOWNERS 視為 一個前進的標準——立即將其應用於新的存儲庫和項目，並隨著時間的推移逐漸將其引入到舊存儲庫中。

範例 CODEOWNERS 檔案結構：

# Global ownership
* @enterprise/repository-admins

# Application code areas
/src/ @enterprise/product-a-developers
/api/ @enterprise/backend-team

# Infrastructure and automation
/terraform/ @enterprise/platform-engineering
/.github/ @enterprise/platform-engineering

# Security-sensitive areas
/security/ @enterprise/security
/auth/ @enterprise/security @enterprise/product-a-leads

建立治理和存放庫標準

這些模式代表建議的最終狀態做法。它們對於長期健康至關重要，但應分階段採用，以避免壓垮傳統做法的團隊。將它們定位為「前進預設值」，新的存放庫和作用中的專案必須遵循它們，而舊版存放庫可以隨著時間進行補救。

儲存庫命名和可見性

建立一致的模式以減少認知負荷：

清晰、具描述性的名稱 - 使用product-api、platform-tools或security-scanner等格式
預設為私人可見度 - 預設為私人、共用程式庫和檔案為內部、僅透過明確原則公開
一致的描述模式 - 幫助團隊快速了解存儲庫的用途和範圍

基準存放庫範本

建立標準範本，其中包含：

README.md 具有清晰的項目描述和入門說明
適用於審查指派的 CODEOWNERS 檔案
CONTRIBUTING.md 包含貢獻指南
適用於一致通訊的問題和提取要求範本
.github/workflows/ 資料夾（如果使用 GitHub Actions）
預設分支已設定為 main (含壓縮合併和自動主分支刪除)

儲存庫規則集

實施安全和品質控制，保護重要分支機構，同時實現協作。

範例企業安全規則集：

name: 'Enterprise Security Ruleset'
target: 'branch'
enforcement: 'active'
conditions:
ref_name:
include: ['refs/heads/main', 'refs/heads/develop']
rules:
- type: 'required_status_checks'
parameters:
required_status_checks:
- context: 'build'
- context: 'security-scan'
- type: 'required_signatures'
- type: 'pull_request'
parameters:
dismiss_stale_reviews: true
require_code_owner_review: true
required_approving_review_count: 2

從足夠限制的保護開始，以保護主要分支和敏感區域，然後根據小組意見反應和共同作業需求進行調整。

集中式控管的組織規則集

組織規則集現在是企業治理的建議方法，可在所有存放庫中提供集中式原則管理。與存放庫層級分支保護不同，規則集在整個組織範圍內一致適用，並且需要最少的持續維護。

在目標環境設定期間設定組織層級規則集：

導覽至 組織設定 → 存放庫規則集
建立強制執行設定為「作用中」的推送規則集
以所有存放庫和主要分支（main， master， develop）為目標

新增核心 GitHub 流程規則：

{
"name": "Enterprise GitHub Flow",
"enforcement": "active",
"target": {"repositories": "all", "branches": ["main", "master"]},
"rules": [
{
"type": "pull_request",
"parameters": {
"required_approving_review_count": 1,
"dismiss_stale_reviews_on_push": true,
"require_code_owner_review": true
}
},
{
"type": "required_status_checks",
"parameters": {
"required_status_checks": ["ci/build", "ci/test", "security/scan"]
}
},
{"type": "non_fast_forward", "parameters": {}}
]
}

優點：新儲存庫會自動繼承原則、治理更新會在整個組織套用，以及合規性報告集中式。

存放庫層級補充：使用存放庫規則集來針對專案特定需求，例如檔案路徑限制或不適用於整個組織的提交訊息模式。

配置 Azure 集成以支持混合工作流程

在轉換期間，您可能需要維護 GitHub 存放庫與 Azure DevOps Services 之間的連線。

Azure Boards 整合功能

如需完整的雙向連結和工作項目可追溯性：

gh ado2gh integrate-boards \
--ado-org "$ADO_ORG" \
--ado-team-project "$ADO_TEAM_PROJECT" \
--github-org "$GITHUB_ORG" \
--github-repo "$GITHUB_REPO" \
--verbose

如果您需要基本連結且希望簡化設定，這些簡便的自動連結參考可以協助您：

gh ado2gh configure-autolink \
--github-org "$GITHUB_ORG" \
--github-repo "$GITHUB_REPO" \
--ado-org "$ADO_ORG" \
--ado-team-project "$ADO_TEAM_PROJECT" \
--verbose

Azure Pipelines 混合式設定

當您想要將程式碼移轉與發行程式現代化分離時：

跨團隊專案共用服務連線：

gh ado2gh share-service-connection \
--ado-org "$ADO_ORG" \
--ado-team-project "$TARGET_TEAM_PROJECT" \
--service-connection-id "$SERVICE_CONNECTION_ID" \
--verbose

更新現有管線以參考 GitHub 存放庫：

gh ado2gh rewire-pipeline \
--ado-org "$ADO_ORG" \
--ado-team-project "$ADO_TEAM_PROJECT" \
--ado-pipeline "$PIPELINE_PATH_OR_NAME" \
--github-org "$GITHUB_ORG" \
--github-repo "$GITHUB_REPO" \
--service-connection-id "$SERVICE_CONNECTION_ID" \
--verbose

這些混合組態可讓您移轉程式碼儲存庫，同時維護現有的部署自動化，從而降低生產系統的轉換風險。

意見反應

此頁面對您有幫助嗎？