From 3341fbbb3c47640b0c1b3e8828c19258543a34c3 Mon Sep 17 00:00:00 2001 From: "well-architected-sync-bot[bot]" <235114805+well-architected-sync-bot[bot]@users.noreply.github.com> Date: Thu, 11 Jun 2026 18:09:49 +0000 Subject: [PATCH 1/2] Sync from github/github-well-architected-internal (main) Source Repository: github/github-well-architected-internal Source Branch: main Source SHA: 19df7eb80cb63be9f9f42048ccf315e876108117 --- CONTRIBUTING.md | 91 ++--- archetypes/default.md | 59 ++- config/_default/hugo.yaml | 13 +- content/_index.md | 1 + content/index.yml | 5 + content/library/_index.md | 19 - .../library/application-security/_index.md | 13 +- .../library/application-security/checklist.md | 2 +- .../application-security/design-principles.md | 2 +- .../library/application-security/index.yml | 5 + .../library/application-security/overview.md | 16 + .../application-security/quick-links.md | 2 +- .../recommendations/_index.md | 10 +- .../index.md => actions-security.md} | 5 +- .../{threat-model => assets}/image1.png | Bin .../{threat-model => assets}/image2.png | Bin .../index.md => enforce-ghas-at-scale.md} | 1 + .../recommendations/index.yml | 4 + .../managing-dependency-threats.md | 3 +- .../recommendations/overview.md | 13 + .../index.md => prioritizing-alerts.md} | 5 +- .../recommendations/schema.json | 37 ++ .../securing-developer-workspace.md | 1 + .../index.md => threat-model.md} | 17 +- .../library/application-security/schema.json | 40 ++ content/library/architecture/_index.md | 13 +- content/library/architecture/checklist.md | 2 +- .../library/architecture/design-principles.md | 2 +- content/library/architecture/index.yml | 5 + content/library/architecture/overview.md | 17 + content/library/architecture/quick-links.md | 2 +- .../architecture/recommendations/_index.md | 9 +- ...-injected-larger-runners-architecture.webp | Bin .../deploying-actions-runner-controller.md | 7 +- ...anding-enterprise-custom-agents-context.md | 5 +- ...md => hosted-runner-private-networking.md} | 22 +- .../implementing-polyrepo-engineering.md | 384 +++++------------- .../architecture/recommendations/index.yml | 3 + .../architecture/recommendations/overview.md | 14 + .../scaling-git-repositories/_index.md | 15 +- .../scaling-git-repositories/index.yml | 3 + .../large-git-repositories.md | 3 +- .../scaling-git-repositories/overview.md | 20 + .../repository-architecture-strategy.md | 1 + .../scaling-git-repositories/schema.json | 40 ++ .../when-to-use-git-lfs.md | 5 +- .../architecture/recommendations/schema.json | 40 ++ content/library/architecture/schema.json | 40 ++ content/library/collaboration/_index.md | 13 +- content/library/collaboration/checklist.md | 2 +- .../collaboration/design-principles.md | 2 +- content/library/collaboration/index.yml | 5 + content/library/collaboration/overview.md | 16 + content/library/collaboration/quick-links.md | 2 +- .../collaboration/recommendations/_index.md | 10 +- .../applying-devops-methodology.md | 5 +- .../champion-handbook.pdf | Bin .../champion-handbook.png | Bin .../champion-program-charter.pdf | Bin .../champion-program-charter.png | Bin .../index.md => champion-program.md} | 25 +- .../collaboration/recommendations/index.yml | 3 + .../collaboration/recommendations/overview.md | 13 + ...ndex.md => scaling-actions-reusability.md} | 1 + .../collaboration/recommendations/schema.json | 40 ++ content/library/collaboration/schema.json | 40 ++ content/library/governance/_index.md | 13 +- content/library/governance/checklist.md | 4 +- .../library/governance/design-principles.md | 2 +- content/library/governance/index.yml | 5 + content/library/governance/overview.md | 16 + content/library/governance/quick-links.md | 2 +- .../governance/recommendations/_index.md | 10 +- .../enterprise-account-model-1.png | Bin .../enterprise-account-model-2.png | Bin .../enterprise-account-model-3.png | Bin .../enterprise-account-overview.png | Bin .../image1.png | Bin .../image2.png | Bin ...> governance-administration-essentials.md} | 21 +- ... => governance-policies-best-practices.md} | 13 +- .../governing-agentic-workflows.md | 2 +- .../recommendations/governing-agents.md | 15 +- .../governance/recommendations/index.yml | 3 + .../recommendations/managing-ai-credits.md | 2 +- .../managing-repositories-at-scale/_index.md | 17 +- .../custom-properties-best-practices.md | 7 +- .../managing-repositories-at-scale/index.yml | 3 + .../overview.md | 22 + .../rulesets-best-practices.md | 7 +- .../schema.json | 40 ++ .../governance/recommendations/overview.md | 13 + .../governance/recommendations/schema.json | 40 ++ content/library/governance/schema.json | 40 ++ content/library/index.yml | 2 + content/library/overview/_index.md | 107 ----- .../library/overview/about-the-assessment.md | 2 +- .../overview/getting-started-checklist.md | 12 +- content/library/overview/index.yml | 4 + content/library/overview/layers.md | 2 +- content/library/overview/overview.md | 115 ++++++ .../library/overview/release-notes/2025-q1.md | 4 +- .../library/overview/release-notes/2025-q2.md | 4 +- .../library/overview/release-notes/2025-q3.md | 8 +- .../library/overview/release-notes/2025-q4.md | 6 +- .../library/overview/release-notes/2026-q1.md | 14 +- .../library/overview/release-notes/index.md | 12 +- .../overview/release-notes/schema.json | 36 ++ content/library/overview/schema.json | 40 ++ content/library/productivity/_index.md | 12 +- content/library/productivity/checklist.md | 6 +- .../library/productivity/design-principles.md | 2 +- content/library/productivity/index.yml | 5 + content/library/productivity/overview.md | 16 + content/library/productivity/quick-links.md | 4 +- .../productivity/recommendations/_index.md | 10 +- .../index.md => adopting-copilot-at-scale.md} | 7 +- .../engineering-system-metrics.md | 44 +- .../productivity/recommendations/index.yml | 3 + .../productivity/recommendations/overview.md | 13 + .../productivity/recommendations/schema.json | 40 ++ content/library/productivity/schema.json | 40 ++ content/library/scenarios/_index.md | 33 +- content/library/scenarios/anti-patterns.md | 2 +- content/library/scenarios/index.yml | 4 + .../scenarios/measuring-genai-impact.md | 14 +- .../library/scenarios/migrations/_index.md | 29 +- .../01-project-planning.md | 2 +- .../02-source-environment-assessment.md | 4 +- .../03-target-environment.md | 8 +- .../04-migration-testing.md | 2 +- .../05-repository-migration.md | 2 +- .../azure-devops-migration-guide/_index.md | 243 +---------- .../azure-devops-migration-guide/index.yml | 3 + .../azure-devops-migration-guide/overview.md | 246 +++++++++++ .../azure-devops-migration-guide/schema.json | 40 ++ .../library/scenarios/migrations/index.yml | 3 + .../library/scenarios/migrations/overview.md | 31 ++ .../migrations/repository-checklist.md | 3 +- .../library/scenarios/migrations/schema.json | 37 ++ content/library/scenarios/monorepos.md | 25 +- .../scenarios/nist-ssdf-implementation.md | 1 + content/library/scenarios/overview.md | 34 ++ content/library/scenarios/schema.json | 40 ++ content/library/schema.json | 15 + content/schema.json | 16 + docs/README.md | 2 +- docs/contributing-learn.md | 158 +++++++ layouts/partials/home.html | 8 +- layouts/shortcodes/child-pages.html | 14 +- package.json | 6 +- src/markdown-includer/includeMarkdown.js | 213 ++++++++++ src/markdown-includer/includeMarkdown.test.js | 179 ++++++++ src/markdown-includer/package.json | 14 + src/markdown-includer/readme.md | 47 +++ src/resolve-hugo-links/adjust-hugo-links.js | 186 +++++++++ src/resolve-hugo-links/reduce-link-depth.js | 103 +++++ tools/new-content | 71 ++++ tools/server | 11 + 159 files changed, 2777 insertions(+), 1132 deletions(-) create mode 100644 content/index.yml delete mode 100644 content/library/_index.md create mode 100644 content/library/application-security/index.yml create mode 100644 content/library/application-security/overview.md rename content/library/application-security/recommendations/{actions-security/index.md => actions-security.md} (99%) rename content/library/application-security/recommendations/{threat-model => assets}/image1.png (100%) rename content/library/application-security/recommendations/{threat-model => assets}/image2.png (100%) rename content/library/application-security/recommendations/{enforce-ghas-at-scale/index.md => enforce-ghas-at-scale.md} (99%) create mode 100644 content/library/application-security/recommendations/index.yml create mode 100644 content/library/application-security/recommendations/overview.md rename content/library/application-security/recommendations/{prioritizing-alerts/index.md => prioritizing-alerts.md} (99%) create mode 100644 content/library/application-security/recommendations/schema.json rename content/library/application-security/recommendations/{threat-model/index.md => threat-model.md} (99%) create mode 100644 content/library/application-security/schema.json create mode 100644 content/library/architecture/index.yml create mode 100644 content/library/architecture/overview.md rename content/library/architecture/recommendations/{hosted-runner-private-networking => assets}/actions-vnet-injected-larger-runners-architecture.webp (100%) rename content/library/architecture/recommendations/{hosted-runner-private-networking/index.md => hosted-runner-private-networking.md} (89%) create mode 100644 content/library/architecture/recommendations/index.yml create mode 100644 content/library/architecture/recommendations/overview.md create mode 100644 content/library/architecture/recommendations/scaling-git-repositories/index.yml create mode 100644 content/library/architecture/recommendations/scaling-git-repositories/overview.md create mode 100644 content/library/architecture/recommendations/scaling-git-repositories/schema.json create mode 100644 content/library/architecture/recommendations/schema.json create mode 100644 content/library/architecture/schema.json create mode 100644 content/library/collaboration/index.yml create mode 100644 content/library/collaboration/overview.md rename content/library/collaboration/recommendations/{champion-program => assets}/champion-handbook.pdf (100%) rename content/library/collaboration/recommendations/{champion-program => assets}/champion-handbook.png (100%) rename content/library/collaboration/recommendations/{champion-program => assets}/champion-program-charter.pdf (100%) rename content/library/collaboration/recommendations/{champion-program => assets}/champion-program-charter.png (100%) rename content/library/collaboration/recommendations/{champion-program/index.md => champion-program.md} (94%) create mode 100644 content/library/collaboration/recommendations/index.yml create mode 100644 content/library/collaboration/recommendations/overview.md rename content/library/collaboration/recommendations/{scaling-actions-reusability/index.md => scaling-actions-reusability.md} (99%) create mode 100644 content/library/collaboration/recommendations/schema.json create mode 100644 content/library/collaboration/schema.json create mode 100644 content/library/governance/index.yml create mode 100644 content/library/governance/overview.md rename content/library/governance/recommendations/{governance-administration-essentials => assets}/enterprise-account-model-1.png (100%) rename content/library/governance/recommendations/{governance-administration-essentials => assets}/enterprise-account-model-2.png (100%) rename content/library/governance/recommendations/{governance-administration-essentials => assets}/enterprise-account-model-3.png (100%) rename content/library/governance/recommendations/{governance-administration-essentials => assets}/enterprise-account-overview.png (100%) rename content/library/governance/recommendations/{governance-policies-best-practices => assets}/image1.png (100%) rename content/library/governance/recommendations/{governance-policies-best-practices => assets}/image2.png (100%) rename content/library/governance/recommendations/{governance-administration-essentials/index.md => governance-administration-essentials.md} (98%) rename content/library/governance/recommendations/{governance-policies-best-practices/index.md => governance-policies-best-practices.md} (94%) create mode 100644 content/library/governance/recommendations/index.yml create mode 100644 content/library/governance/recommendations/managing-repositories-at-scale/index.yml create mode 100644 content/library/governance/recommendations/managing-repositories-at-scale/overview.md create mode 100644 content/library/governance/recommendations/managing-repositories-at-scale/schema.json create mode 100644 content/library/governance/recommendations/overview.md create mode 100644 content/library/governance/recommendations/schema.json create mode 100644 content/library/governance/schema.json create mode 100644 content/library/index.yml create mode 100644 content/library/overview/index.yml create mode 100644 content/library/overview/overview.md create mode 100644 content/library/overview/release-notes/schema.json create mode 100644 content/library/overview/schema.json create mode 100644 content/library/productivity/index.yml create mode 100644 content/library/productivity/overview.md rename content/library/productivity/recommendations/{adopting-copilot-at-scale/index.md => adopting-copilot-at-scale.md} (97%) create mode 100644 content/library/productivity/recommendations/index.yml create mode 100644 content/library/productivity/recommendations/overview.md create mode 100644 content/library/productivity/recommendations/schema.json create mode 100644 content/library/productivity/schema.json create mode 100644 content/library/scenarios/index.yml create mode 100644 content/library/scenarios/migrations/azure-devops-migration-guide/index.yml create mode 100644 content/library/scenarios/migrations/azure-devops-migration-guide/overview.md create mode 100644 content/library/scenarios/migrations/azure-devops-migration-guide/schema.json create mode 100644 content/library/scenarios/migrations/index.yml create mode 100644 content/library/scenarios/migrations/overview.md create mode 100644 content/library/scenarios/migrations/schema.json create mode 100644 content/library/scenarios/overview.md create mode 100644 content/library/scenarios/schema.json create mode 100644 content/library/schema.json create mode 100644 content/schema.json create mode 100644 docs/contributing-learn.md create mode 100644 src/markdown-includer/includeMarkdown.js create mode 100644 src/markdown-includer/includeMarkdown.test.js create mode 100644 src/markdown-includer/package.json create mode 100644 src/markdown-includer/readme.md create mode 100644 src/resolve-hugo-links/adjust-hugo-links.js create mode 100644 src/resolve-hugo-links/reduce-link-depth.js create mode 100755 tools/new-content diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f6352a0..d946178 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -48,6 +48,7 @@ Thank you for contributing! We look forward to working with you. ❤️ - :octocat: See [GitHub Well-Architected Framework overview] to understand the program and purpose. - 🗳️ We use [GitHub Flow] to manage changes. It is the most effective way to collaborate with all stakeholders on this project. - 🐙 [Issues] are used to **track work**, such as bug reports and feature requests. They are also used to keep track of ideas that may not yet be ready to work on. +- :writing_hand: [Frontmatter and metadata](docs/contributing-learn.md) make content discoverable and publishable. - 🚢 [Pull requests] are the best way to collaborate on reviews. --- @@ -131,39 +132,25 @@ Once you're ready to start, fork the repository and begin authoring. We **strong #### Create your article -There are three options to create a new article: - -##### Option 1. Use the command `hugo new content` to create a new file (recommended in Codespaces) - -```shell -# For recommendations: -hugo new content library/{PILLAR}/recommendations/{ARTICLE-NAME}.md -# For scenarios: -hugo new content library/scenarios/{ARTICLE-NAME}.md -``` - -For example, - -```shell -hugo new content library/productivity/recommendations/my-article.md -``` +There are two options for creating a new article. > [!IMPORTANT] -> When you use this method, you do not need to put `content/` in the command since Hugo considers it the root. +> Hugo-based authoring workflows are deprecated in this repository. Rely on standard Markdown file creation and editing for article authoring. Hugo remains part of local preview/build behind the repository scripts. -##### Option 2. Use a page bundle to create a new article with associated files like images +##### Option 1. Use the template helper command (recommended) -Add a folder (instead of one markdown file) at that location and bundle the files together. The format is: +Run: -```plaintext -content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/index.md -content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/image1.png -content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/image2.png +```shell +# For recommendations: +tools/new-content recommendation {PILLAR} {ARTICLE-NAME} +# For scenarios: +tools/new-content scenario {ARTICLE-NAME} ``` -##### Option 3. Copy/paste the template into a new file +Replace `{PILLAR}` and `{ARTICLE-NAME}` with real values. -Simply copy [`archetypes/default.md`] and paste it into: +This command copies [`archetypes/default.md`] into the correct destination. For **recommendation** articles: @@ -177,42 +164,30 @@ For **scenario** articles: content/library/scenarios/{ARTICLE-NAME}.md ``` -##### Writing Style: +##### Option 2. Use a page bundle to create a new article with associated files like images -- Always use sentence case -- Keep your files tidy - no rogue spaces or characters, please -- Use dashes for unordered lists (not `*`) -- Use single spaces before and after headings, lists, and paragraphs +Add a folder (instead of one markdown file) at that location and bundle the files together. The format is: -#### Edit front-matter +```plaintext +content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/index.md +content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/page1.md +content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/assets/image1.png +content/library/{PILLAR}/recommendations/{ARTICLE-NAME}/assets/image2.png +``` -Each article (written in markdown) should have front-matter at the top of the file. This front-matter should look like this: +> [!WARNING] +> Do not use `hugo new content` for new article creation in this repository. -```yaml ---- -draft: true # Set to false when ready to publish -title: 'Insert title here' -publishDate: 2024-12-05 # Date the article is published - -# Add author details -params: - authors: - [ - { name: 'Mona', handle: 'octocat' }, - ] - -# Classifications of the framework to drive key concepts, design principles, and architectural best practices -pillars: - - placeholder - - placeholder ---- -``` +#### Writing style -- When you are done with your article, set `draft: false` when you are ready to publish. +- Always use sentence case +- Keep your files tidy - no rogue spaces or characters, please +- Use dashes for unordered lists (not `*`) +- Use single spaces before and after headings, lists, and paragraphs -- Set `publishDate` to the date the article is first merged to `main`. Do not change it on future revisions. +#### Required frontmatter and metadata -- All recommended values for all of these fields are described in [Taxonomies]. **Insert all that apply to your article. This is how your article will be discoverable!** +Articles must include the required frontmatter fields described in [docs/contributing-learn.md](docs/contributing-learn.md). This is critical for the content to be processed and published correctly. --- @@ -356,10 +331,10 @@ There are several primary types of contributions to this project: ### 📝 Content Library Article Submission(s) -Contributions will typically author content articles under `/content/` folder. To start writing, we recommend reviewing these essential framework resources: +Contributions typically involve authoring content articles under the `/content/` folder. To start writing, we recommend reviewing these essential framework resources: - [Framework Overview] - Learn about the WAF mission, vision, objectives, and five pillars -- [Taxonomies](/docs/taxonomies.md) - Explore the design principles, areas, and other classifications +- [Taxonomies] - Explore the design principles, areas, and other classifications **Inspiration for Content Library articles** comes from **Azure Architecture Center**. See the following example articles for your inspiration: 💡 @@ -426,7 +401,7 @@ See [Framework Overview] for details on each pillar. - Avoid unnecessary jargon - Include practical examples - Prefer GitHub Docs links to **Enterprise Cloud**: `https://docs.github.com/enterprise-cloud@latest` (unless the guidance is specific to GitHub Enterprise Server) -- Use Hugo shortcodes to keep articles consistent (see `archetypes/default.md`): +- Use repository shortcodes to keep articles consistent (see [`archetypes/default.md`]): - Further assistance: `{{% seeking-further-assistance-details %}}` - Related links: `{{% related-links-github-docs %}}` @@ -488,7 +463,7 @@ Here are the checklists for code reviewers. ## Code of conduct -By participating, you are expected to the GitHub Community [Code of Conduct]. +By participating, you are expected to follow the GitHub Community [Code of Conduct]. --- diff --git a/archetypes/default.md b/archetypes/default.md index 2dbc5ce..681c874 100644 --- a/archetypes/default.md +++ b/archetypes/default.md @@ -1,72 +1,67 @@ --- draft: false # Set to true to keep the page hidden title: 'Insert title here' -publishDate: YYYY-MM-DD -params: +publishDate: 2006-01-02 # Example format placeholder; replace before merge -# Add and remove authors as needed. Please reserve authorship for significant contributions, not edits and feedback. +# Optional navigation metadata +# weight: 1 +# prev: library/{PILLAR}/previous-page +# next: library/{PILLAR}/next-page -authors: [ -{name: "INSERT_NAME_1", handle: "INSERT_HANDLE_1"}, -{name: "INSERT_NAME_2", handle: "INSERT_HANDLE_2"}, -] +params: + authors: + - name: "INSERT_NAME_1" + handle: "INSERT_HANDLE_1" + - name: "INSERT_NAME_2" + handle: "INSERT_HANDLE_2" # Classifications of the framework to drive key concepts, design principles, and architectural best practices pillars: - -- placeholder -- placeholder + - placeholder + - placeholder # The areas of the GitHub adoption journey. Inspiration taken from docs.github.com areas: - -- placeholder -- placeholder + - placeholder + - placeholder # Classifications of industries who may be at different stages of the customer journey. verticals: - -- placeholder -- placeholder + - placeholder + - placeholder # Individuals in key roles on the customer journey, typically consisting of one or more administrators and the end-user community. personas: - -- placeholder -- placeholder + - placeholder + - placeholder # Deployment options for GitHub Enterprise, including Cloud (GHEC), Server (GHES), and Hybrid. platform: - -- placeholder -- placeholder + - placeholder + - placeholder # GitHub product functions designed to support every stage of development. features: - -- placeholder -- placeholder + - placeholder + - placeholder # Deeper-level topics of the GitHub Platform and its features. They are most often interacted with by end-users. components: - -- placeholder -- placeholder + - placeholder + - placeholder # Associated teams and other GitHub and Partner resources that can provide additional support. github: - -- placeholder -- placeholder - + - placeholder + - placeholder --- diff --git a/config/_default/hugo.yaml b/config/_default/hugo.yaml index 926d64d..111f49e 100644 --- a/config/_default/hugo.yaml +++ b/config/_default/hugo.yaml @@ -4,13 +4,14 @@ languageCode: en-us title: GitHub Well-Architected enableInlineShortcodes: true # https://imfing.github.io/hextra/docs/guide/shortcodes/icon enableGitInfo: true +contentDir: content-processed # import hextra as module module: imports: - path: github.com/imfing/hextra version: v0.8.6 - + build: # cache busting for css changes @@ -18,6 +19,12 @@ build: - source: layouts/.* target: css +# Cascade type: docs to all library pages so Hugo uses the docs layout (sidebar enabled) +cascade: + - _target: + path: /library/** + type: docs + markup: # allow raw html goldmark: @@ -90,7 +97,7 @@ params: displayAuthorInfo: true frontmatter: - publishDate: + publishDate: - publishDate - :filename - date @@ -100,7 +107,7 @@ frontmatter: navbar: displayTitle: true displayLogo: true - logo: + logo: path: media/github-mark.svg dark: media/github-mark-white.svg link: / diff --git a/content/_index.md b/content/_index.md index 9fd4a58..cf34ad8 100644 --- a/content/_index.md +++ b/content/_index.md @@ -1,6 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT +title: GitHub Well-Architected Framework description: The GitHub Well-Architected Framework is an open source-style, community-driven framework to curate the best way to deploy the GitHub platform. params: logosBlock: false diff --git a/content/index.yml b/content/index.yml new file mode 100644 index 0000000..20f740a --- /dev/null +++ b/content/index.yml @@ -0,0 +1,5 @@ + +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: GitHub Well-Architected Framework +description: The GitHub Well-Architected Framework is an open source-style, community-driven framework to curate the best way to deploy the GitHub platform. diff --git a/content/library/_index.md b/content/library/_index.md deleted file mode 100644 index 1302339..0000000 --- a/content/library/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -# SPDX-FileCopyrightText: GitHub and The Project Authors -# SPDX-License-Identifier: MIT -title: Content Library -cascade: # Automatically apply these for all children unless overridden - type: docs # Automatically set docs layout for all children: https://imfing.github.io/hextra/docs/guide/organize-files/#layouts - toc: true # Automatically set table of contents for all children: https://imfing.github.io/hextra/docs/guide/configuration/#table-of-contents - sidebar: # Automatically display sidebar for all children: https://imfing.github.io/hextra/docs/guide/configuration/#main-sidebar - open: true ---- - - - -The GitHub Well-Architected Framework is an open source-style, community-driven framework to curate the best way to deploy the GitHub platform. This is the root of the Content Library. - -{{< cards >}} - {{< card link="overview" title="Overview" icon="sparkles" >}} - {{< card link="overview/layers" title="Layers of GitHub Well-Architected" icon="sparkles" >}} -{{< /cards >}} diff --git a/content/library/application-security/_index.md b/content/library/application-security/_index.md index 55ff9f8..434e4a9 100644 --- a/content/library/application-security/_index.md +++ b/content/library/application-security/_index.md @@ -1,16 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: 🔒 Application Security +title: Overview +linkTitle: Application Security weight: 5 -slug: application-security --- - -The **Application Security** pillar is about ensuring the security of your applications. It could include principles related to using GitHub's security features like Dependabot, security advisories, and code scanning. - -{{< cards >}} - {{< card link="quick-links" title="Quick Links" icon="sparkles" >}} - {{< card link="design-principles" title="Design Principles" icon="book-open" >}} - {{< card link="checklist" title="Assessment Checklist" icon="book-open" >}} - {{< card link="recommendations" title="Recommendations" icon="book-open" >}} -{{< /cards >}} diff --git a/content/library/application-security/checklist.md b/content/library/application-security/checklist.md index 101e9fe..974035d 100644 --- a/content/library/application-security/checklist.md +++ b/content/library/application-security/checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Application Security -weight: 3 +weight: 4 prev: library/application-security/design-principles next: library/application-security/recommendations --- diff --git a/content/library/application-security/design-principles.md b/content/library/application-security/design-principles.md index 390118c..72dea00 100644 --- a/content/library/application-security/design-principles.md +++ b/content/library/application-security/design-principles.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Design Principles -weight: 2 +weight: 3 prev: library/application-security/quick-links next: library/application-security/checklist --- diff --git a/content/library/application-security/index.yml b/content/library/application-security/index.yml new file mode 100644 index 0000000..898e8f1 --- /dev/null +++ b/content/library/application-security/index.yml @@ -0,0 +1,5 @@ +title: Application Security +description: Proactive guidelines for embedding security into every stage of development, from code scanning to compliance. +weight: 5 +slug: application-security +icon: ShieldLockIcon diff --git a/content/library/application-security/overview.md b/content/library/application-security/overview.md new file mode 100644 index 0000000..4a9c69a --- /dev/null +++ b/content/library/application-security/overview.md @@ -0,0 +1,16 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +The **Application Security** pillar is about ensuring the security of your applications. It could include principles related to using GitHub's security features like Dependabot, security advisories, and code scanning. + +{{< cards >}} + {{< card link="./quick-links" title="Quick Links" >}} + {{< card link="./design-principles" title="Design Principles" >}} + {{< card link="./checklist" title="Assessment Checklist" >}} + {{< card link="./recommendations/overview" title="Recommendations" >}} +{{< /cards >}} diff --git a/content/library/application-security/quick-links.md b/content/library/application-security/quick-links.md index d16d4e2..9e1d918 100644 --- a/content/library/application-security/quick-links.md +++ b/content/library/application-security/quick-links.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Quick links -weight: 1 +weight: 2 prev: library/application-security next: library/application-security/design-principles --- diff --git a/content/library/application-security/recommendations/_index.md b/content/library/application-security/recommendations/_index.md index 4b8c454..fae5954 100644 --- a/content/library/application-security/recommendations/_index.md +++ b/content/library/application-security/recommendations/_index.md @@ -1,13 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Recommendations +title: Overview +linkTitle: Recommendations weight: 5 -prev: library/application-security --- - -This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 🔒 **Application Security** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. - -Articles in this section include: - -{{< child-pages >}} diff --git a/content/library/application-security/recommendations/actions-security/index.md b/content/library/application-security/recommendations/actions-security.md similarity index 99% rename from content/library/application-security/recommendations/actions-security/index.md rename to content/library/application-security/recommendations/actions-security.md index 8e3a85f..394c712 100644 --- a/content/library/application-security/recommendations/actions-security/index.md +++ b/content/library/application-security/recommendations/actions-security.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Securing GitHub Actions Workflows' +weight: 5 publishDate: 2024-08-16 params: authors: [{ name: 'Greg Mohler', handle: 'callmegreg' }, { name: 'Kitty Chiu', handle: 'kittychiu' }] @@ -267,13 +268,13 @@ For the most secure footprint, trust no one, review the code, and always use com ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/application-security/recommendations/threat-model/image1.png b/content/library/application-security/recommendations/assets/image1.png similarity index 100% rename from content/library/application-security/recommendations/threat-model/image1.png rename to content/library/application-security/recommendations/assets/image1.png diff --git a/content/library/application-security/recommendations/threat-model/image2.png b/content/library/application-security/recommendations/assets/image2.png similarity index 100% rename from content/library/application-security/recommendations/threat-model/image2.png rename to content/library/application-security/recommendations/assets/image2.png diff --git a/content/library/application-security/recommendations/enforce-ghas-at-scale/index.md b/content/library/application-security/recommendations/enforce-ghas-at-scale.md similarity index 99% rename from content/library/application-security/recommendations/enforce-ghas-at-scale/index.md rename to content/library/application-security/recommendations/enforce-ghas-at-scale.md index d4aa38e..7b8f736 100644 --- a/content/library/application-security/recommendations/enforce-ghas-at-scale/index.md +++ b/content/library/application-security/recommendations/enforce-ghas-at-scale.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Enforce GitHub Advanced Security at Scale' +weight: 6 publishDate: 2024-07-03 params: authors: [{ name: 'Greg Mohler', handle: 'callmegreg' }] diff --git a/content/library/application-security/recommendations/index.yml b/content/library/application-security/recommendations/index.yml new file mode 100644 index 0000000..0ba4f6a --- /dev/null +++ b/content/library/application-security/recommendations/index.yml @@ -0,0 +1,4 @@ +title: Recommendations +weight: 5 +prev: library/application-security +slug: recommendations diff --git a/content/library/application-security/recommendations/managing-dependency-threats.md b/content/library/application-security/recommendations/managing-dependency-threats.md index e21486d..71d050e 100644 --- a/content/library/application-security/recommendations/managing-dependency-threats.md +++ b/content/library/application-security/recommendations/managing-dependency-threats.md @@ -1,6 +1,7 @@ --- draft: false title: 'Defending against dependency supply chain attacks' +weight: 3 publishDate: 2025-12-10 params: authors: [ @@ -303,7 +304,7 @@ Build a comprehensive automated detection system that catches vulnerabilities at **Dependency vulnerabilities:** -Enable [Dependabot security updates](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates) to automatically detect vulnerabilities and create pull requests for updates. Consider grouping patch updates for expedited review, assigning security team reviewers, and scheduling daily scans. Use [auto-triage rules](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-auto-triage-rules/about-dependabot-auto-triage-rules) to reduce alert fatigue by automatically dismissing low-risk alerts or alerts for dependencies that don't affect your usage. For comprehensive guidance on managing security alerts at scale, see [Prioritizing security alert remediation](../prioritizing-alerts/). +Enable [Dependabot security updates](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates) to automatically detect vulnerabilities and create pull requests for updates. Consider grouping patch updates for expedited review, assigning security team reviewers, and scheduling daily scans. Use [auto-triage rules](https://docs.github.com/enterprise-cloud@latest/code-security/dependabot/dependabot-auto-triage-rules/about-dependabot-auto-triage-rules) to reduce alert fatigue by automatically dismissing low-risk alerts or alerts for dependencies that don't affect your usage. For comprehensive guidance on managing security alerts at scale, see [Prioritizing security alert remediation](./prioritizing-alerts). Add the [dependency review action](https://github.com/actions/dependency-review-action) to your pull request workflows and require it as a status check to prevent potential vulnerabilities from being introduced. Configure it to fail on high-severity vulnerabilities, block problematic licenses, and warn on low [OpenSSF Scorecard](https://securityscorecards.dev/) scores. diff --git a/content/library/application-security/recommendations/overview.md b/content/library/application-security/recommendations/overview.md new file mode 100644 index 0000000..ce92f8a --- /dev/null +++ b/content/library/application-security/recommendations/overview.md @@ -0,0 +1,13 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 🔒 **Application Security** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. + +Articles in this section include: + +{{< child-pages >}} diff --git a/content/library/application-security/recommendations/prioritizing-alerts/index.md b/content/library/application-security/recommendations/prioritizing-alerts.md similarity index 99% rename from content/library/application-security/recommendations/prioritizing-alerts/index.md rename to content/library/application-security/recommendations/prioritizing-alerts.md index 89cfa98..e1292f9 100644 --- a/content/library/application-security/recommendations/prioritizing-alerts/index.md +++ b/content/library/application-security/recommendations/prioritizing-alerts.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Prioritizing Security Alert Remediation' +weight: 4 publishDate: 2025-08-05 params: authors: @@ -199,13 +200,13 @@ Currently, security campaigns are only available for code scanning and secret sc ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/application-security/recommendations/schema.json b/content/library/application-security/recommendations/schema.json new file mode 100644 index 0000000..fe13942 --- /dev/null +++ b/content/library/application-security/recommendations/schema.json @@ -0,0 +1,37 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": ["title", "weight"], + "additionalProperties": true +} diff --git a/content/library/application-security/recommendations/securing-developer-workspace.md b/content/library/application-security/recommendations/securing-developer-workspace.md index 260715f..ce4ece5 100644 --- a/content/library/application-security/recommendations/securing-developer-workspace.md +++ b/content/library/application-security/recommendations/securing-developer-workspace.md @@ -1,6 +1,7 @@ --- draft: false title: 'Securing developer workspace' +weight: 2 publishDate: 2025-12-19 params: authors: [ diff --git a/content/library/application-security/recommendations/threat-model/index.md b/content/library/application-security/recommendations/threat-model.md similarity index 99% rename from content/library/application-security/recommendations/threat-model/index.md rename to content/library/application-security/recommendations/threat-model.md index 526ae7d..2a924c6 100644 --- a/content/library/application-security/recommendations/threat-model/index.md +++ b/content/library/application-security/recommendations/threat-model.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false title: 'GitHub Repositories Threat Model' +weight: 7 publishDate: 2024-05-29 params: authors: [ @@ -77,7 +78,7 @@ The scope informs both the threat actors and the threats themselves. The threat actors may contain threats within themselves which highlights the various ways a threat actor could gain access to a GitHub repository. -![Supply Chain](image1.png) +![Supply Chain](./assets/image1.png) *Figure attribution: This diagram is derived from the [SLSA Supply Chain Threats model](https://slsa.dev/spec/v1.0/threats), version 1.0, from the [SLSA Framework](https://github.com/slsa-framework/slsa). Licensed under [Community Specification License 1.0](https://github.com/slsa-framework/slsa/blob/main/LICENSE.md).* @@ -129,7 +130,7 @@ Beyond authentication there are a number of roles within a GitHub repository, there is the concept of GitHub teams which can be assigned a role, and there are outside contributors. -![Trust Boundary](image2.png) +![Trust Boundary](./assets/image2.png) ## Methodology @@ -153,7 +154,7 @@ suggested mitigations against those threats. ## Threat actors TA-01 A threat actor with Internet access - + TA-02 A threat actor who has a GitHub Account TA-03 An threat actor who is an [outside @@ -173,12 +174,12 @@ suggested mitigations against those threats. TA-09 A threat actor who is an insider e.g. a user who makes a mistake, a disgruntled employee, or contractor - + ## Threats T-01 A threat actor searches public repositories with the goal of finding valid secrets e.g. password, access token, API key, etc. - + T-02 A private repository is accessed by an unauthorized threat actor T-03 A threat actor can change settings in the "Danger Zone", @@ -829,7 +830,7 @@ These actions include accounts to GitHub Apps which utilize authentication mechanisms within the customer's Org trust boundary -### T-07 A threat actor compromises a customer's GitHub repository +### T-07 A threat actor compromises a customer's GitHub repository The threat actor could gain elevated access (e.g. write or admin) or exploit a misconfiguration to comprise the repository @@ -1026,12 +1027,12 @@ A threat actor could exploit a script injection or echo out secrets request ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/application-security/schema.json b/content/library/application-security/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/application-security/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/architecture/_index.md b/content/library/architecture/_index.md index 0b0c264..161452d 100644 --- a/content/library/architecture/_index.md +++ b/content/library/architecture/_index.md @@ -1,16 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: 📐 Architecture +title: Overview +linkTitle: Architecture weight: 7 -slug: architecture --- - -The **Architecture** pillar focuses on the technical design and structure of your GitHub deployment. It provides guidance on how to design and deploy your GitHub environment to meet your organization's needs, while addressing technical concepts such as scalability, reliability, and efficiency. - -{{< cards >}} - {{< card link="quick-links" title="Quick Links" icon="sparkles" >}} - {{< card link="design-principles" title="Design Principles" icon="book-open" >}} - {{< card link="checklist" title="Assessment Checklist" icon="book-open" >}} - {{< card link="recommendations" title="Recommendations" icon="book-open" >}} -{{< /cards >}} diff --git a/content/library/architecture/checklist.md b/content/library/architecture/checklist.md index 433439d..d8057e3 100644 --- a/content/library/architecture/checklist.md +++ b/content/library/architecture/checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Architecture -weight: 3 +weight: 4 prev: library/architecture/design-principles next: library/architecture/recommendations --- diff --git a/content/library/architecture/design-principles.md b/content/library/architecture/design-principles.md index ae44fd3..7bf041d 100644 --- a/content/library/architecture/design-principles.md +++ b/content/library/architecture/design-principles.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Design Principles -weight: 2 +weight: 3 prev: library/architecture/quick-links next: library/architecture/checklist --- diff --git a/content/library/architecture/index.yml b/content/library/architecture/index.yml new file mode 100644 index 0000000..94bf985 --- /dev/null +++ b/content/library/architecture/index.yml @@ -0,0 +1,5 @@ +title: Architecture +description: Approaches for designing scalable, resilient, and efficient GitHub environments, including enterprise-level solutions (e.g., GHES), tailored to your organization's needs. +slug: architecture +icon: OrganizationIcon +weight: 7 diff --git a/content/library/architecture/overview.md b/content/library/architecture/overview.md new file mode 100644 index 0000000..6b7e1ac --- /dev/null +++ b/content/library/architecture/overview.md @@ -0,0 +1,17 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +linkTitle: Overview +weight: 1 +--- + + +The **Architecture** pillar focuses on the technical design and structure of your GitHub deployment. It provides guidance on how to design and deploy your GitHub environment to meet your organization's needs, while addressing technical concepts such as scalability, reliability, and efficiency. + +{{< cards >}} + {{< card link="./quick-links" title="Quick Links" >}} + {{< card link="./design-principles" title="Design Principles" >}} + {{< card link="./checklist" title="Assessment Checklist" >}} + {{< card link="./recommendations/overview" title="Recommendations" >}} +{{< /cards >}} diff --git a/content/library/architecture/quick-links.md b/content/library/architecture/quick-links.md index 7f94cf6..f61d214 100644 --- a/content/library/architecture/quick-links.md +++ b/content/library/architecture/quick-links.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Quick links -weight: 1 +weight: 2 prev: library/architecture next: library/architecture/design-principles --- diff --git a/content/library/architecture/recommendations/_index.md b/content/library/architecture/recommendations/_index.md index dc44fde..6ee97fa 100644 --- a/content/library/architecture/recommendations/_index.md +++ b/content/library/architecture/recommendations/_index.md @@ -1,13 +1,8 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Recommendations +title: Overview +linkTitle: Recommendations weight: 5 prev: library/architecture --- - -This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 📐 **Architecture** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. - -Articles in this section include: - -{{< child-pages >}} diff --git a/content/library/architecture/recommendations/hosted-runner-private-networking/actions-vnet-injected-larger-runners-architecture.webp b/content/library/architecture/recommendations/assets/actions-vnet-injected-larger-runners-architecture.webp similarity index 100% rename from content/library/architecture/recommendations/hosted-runner-private-networking/actions-vnet-injected-larger-runners-architecture.webp rename to content/library/architecture/recommendations/assets/actions-vnet-injected-larger-runners-architecture.webp diff --git a/content/library/architecture/recommendations/deploying-actions-runner-controller.md b/content/library/architecture/recommendations/deploying-actions-runner-controller.md index 2cbc978..a2f8592 100644 --- a/content/library/architecture/recommendations/deploying-actions-runner-controller.md +++ b/content/library/architecture/recommendations/deploying-actions-runner-controller.md @@ -1,6 +1,7 @@ --- draft: false title: 'Deploying Actions Runner Controller' +weight: 4 publishDate: 2025-12-19 params: # Add and remove authors as needed. Please reserve authorship for significant contributions, not edits and feedback. @@ -220,7 +221,7 @@ When a container mode is selected, ARC configures the runner pods using a pre-de {{< callout type="warning" >}} ARC scales by requesting pods in Kubernetes according to the provided `template.spec` or `containerMode` template. Kubernetes is then responsible for scheduling and running the pods based on that specification. Misconfigured `template.spec` settings are a common sources of performance, reliability, and scaling issues with ARC. -{{}} +{{< /callout >}} - **Provide a `template.spec` for production use.** For production deployments, it is recommended to comment out the `containerMode` setting and define your runner specifications. If you need the features provided by the `dind`, `kubernetes`, or `kubernetes-novolume` container mode, use the included templates as a starting point. This gives you control over the container settings, allowing you to set requests/limits, security contexts, and a custom runner image. @@ -271,13 +272,13 @@ Kubernetes does not contain a Docker runtime, so this mode does not support Acti ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/architecture/recommendations/expanding-enterprise-custom-agents-context.md b/content/library/architecture/recommendations/expanding-enterprise-custom-agents-context.md index 36b5b40..da18661 100644 --- a/content/library/architecture/recommendations/expanding-enterprise-custom-agents-context.md +++ b/content/library/architecture/recommendations/expanding-enterprise-custom-agents-context.md @@ -1,6 +1,7 @@ --- draft: false title: 'Expanding the context of Enterprise Custom Agents' +weight: 2 publishDate: 2026-03-11 params: # Add and remove authors as needed. Please reserve authorship for significant contributions, not edits and feedback. @@ -416,13 +417,13 @@ Use kebab-case for filenames: `secure-coding-standards.md` ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/architecture/recommendations/hosted-runner-private-networking/index.md b/content/library/architecture/recommendations/hosted-runner-private-networking.md similarity index 89% rename from content/library/architecture/recommendations/hosted-runner-private-networking/index.md rename to content/library/architecture/recommendations/hosted-runner-private-networking.md index 32cef6f..6a965d2 100644 --- a/content/library/architecture/recommendations/hosted-runner-private-networking/index.md +++ b/content/library/architecture/recommendations/hosted-runner-private-networking.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: "Accessing private networks from GitHub Actions Runners" +weight: 5 publishDate: 2024-09-09 params: authors: [ @@ -65,9 +66,7 @@ github: [GitHub-hosted runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) are a cost-effective, secure, and low maintenance option for running your [GitHub Actions](https://docs.github.com/en/actions) workflows. Hosted runners are managed by GitHub, run on GitHub-owned infrastructure, and have access to the public internet by default. -Many customers need to access private resources from their GitHub Actions workflows to perform actions such as deploying software to private infrastructure or using private package managers. Accessing these resources is -not possible with the default GitHub-hosted runner configurations without enabling access to the internet. This article presents a few options for enabling GitHub-hosted runners to access private resources, and focuses on the [Azure Private Networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) feature which is the most -comprehensive solution for private network access. +Many customers need to access private resources from their GitHub Actions workflows to perform actions such as deploying software to private infrastructure or using private package managers. Accessing these resources is not possible with the default GitHub-hosted runner configurations without enabling access to the internet. This article presents a few options for enabling GitHub-hosted runners to access private resources, and focuses on the [Azure Private Networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) feature which is the most comprehensive solution for private network access. ## Potential Solutions @@ -78,10 +77,7 @@ GitHub offers a few potential solutions to enable access to private resources: 1. Using Azure Private Networking {{< callout type="info" >}} -Some of these features require the use of GitHub-hosted larger runners. GitHub offers both [standard](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) and -[larger](https://docs.github.com/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners) hosted runners. -[GitHub-hosted larger runners](https://docs.github.com/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners) are provisioned specifically for your enterprise or organization, -as opposed to standard runners which are common pools of runners used across all of GitHub. Larger runners offer a few capabilities that aren't available on standard runners for an added cost. +Some of these features require the use of GitHub-hosted larger runners. GitHub offers both [standard](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) and [larger](https://docs.github.com/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners) hosted runners. [GitHub-hosted larger runners](https://docs.github.com/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners) are provisioned specifically for your enterprise or organization, as opposed to standard runners which are common pools of runners used across all of GitHub. Larger runners offer a few capabilities that aren't available on standard runners for an added cost. {{< /callout >}} ### Using Static IP Addresses @@ -98,8 +94,7 @@ This pattern is most useful when the private resources you need to access from y ### Using Azure Private Networking -[Azure private networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) allows you to maintain -complete control over the networking configuration of your GitHub-hosted larger runners. Azure private networking enables larger runners to privately connect to your network and resources through an Azure Virtual Network, without opening ports or enabling access to those resources from the public internet. This not only enables private access to Azure resources; when combined with Azure [ExpressRoute](https://azure.microsoft.com/en-us/products/expressroute) or [VPN Gateway](https://azure.microsoft.com/en-us/products/vpn-gateway) it can also enable access to resources in your private on-premise networks as well. +[Azure private networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) allows you to maintain complete control over the networking configuration of your GitHub-hosted larger runners. Azure private networking enables larger runners to privately connect to your network and resources through an Azure Virtual Network, without opening ports or enabling access to those resources from the public internet. This not only enables private access to Azure resources; when combined with Azure [ExpressRoute](https://azure.microsoft.com/en-us/products/expressroute) or [VPN Gateway](https://azure.microsoft.com/en-us/products/vpn-gateway) it can also enable access to resources in your private on-premise networks as well. The disadvantages of this approach are that an Azure presence is required and the configuration requires some access permissions in your Azure subscription. These requirements are covered in detail below. @@ -109,10 +104,9 @@ The disadvantages of this approach are that an Azure presence is required and th Azure private networking leverages an Azure pattern known as VNET injection to deploy the GitHub-hosted runner's network interface card (NIC) into your private Azure VNET, while the runner VM resides in GitHub-owned infrastructure. The result is that you are in complete control of the runner's network access controls. -This diagram and the other content from the [About Azure private networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) documentation -describes the general architecture and how this feature is implemented in GitHub and Azure. There is no need to repeat that documentation here, however below we touch on a few aspects that may be of particular interest to those using this feature. +This diagram and the other content from the [About Azure private networking](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise) documentation describes the general architecture and how this feature is implemented in GitHub and Azure. There is no need to repeat that documentation here, however below we touch on a few aspects that may be of particular interest to those using this feature. -![Architecture](actions-vnet-injected-larger-runners-architecture.webp) +![Architecture](./assets/actions-vnet-injected-larger-runners-architecture.webp) The main points from the diagram are: @@ -216,12 +210,12 @@ The `terraform-github-runner-vnet` project is maintained by a few GitHub enginee ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/architecture/recommendations/implementing-polyrepo-engineering.md b/content/library/architecture/recommendations/implementing-polyrepo-engineering.md index f25e89f..822d3d3 100644 --- a/content/library/architecture/recommendations/implementing-polyrepo-engineering.md +++ b/content/library/architecture/recommendations/implementing-polyrepo-engineering.md @@ -4,6 +4,7 @@ draft: false title: 'Implementing polyrepo on GitHub' +weight: 3 publishDate: 2026-02-24 params: authors: @@ -97,82 +98,47 @@ See our CONTRIBUTING doc for submission details and additional writing style gui ## Scenario overview -Enterprises building software as a polyrepo system—one component per -repository—gain autonomy, clearer ownership, and scalable team boundaries. -They also inherit complexity: cross-repo change coordination, dependency -compatibility, consistent CI/CD policy, security remediation at scale, and -release governance. - -GitHub primitives (issues, pull requests, workflows) are repo-scoped by -design. There is no native "multi-repo change object," so organizations -must model one. Reusable workflows improve standardization but introduce -questions of adoption, drift, failures, and versioning. Security -remediation and platform migrations are continuous and inherently -cross-repo. Leaders need enterprise dashboards while teams need a -low-friction workflow that preserves autonomy. - -This article presents a GitHub-first operating model for polyrepo -engineering, centered on an **integration layer (meta-repo)** pattern, -**reusable workflows** as a versioned platform interface, and **orchestration for multi-repo execution**. The design emphasizes -repeatability, auditability, and enterprise-scale observability while -minimizing friction for individual service teams. +Enterprises building software as a polyrepo system—one component per repository—gain autonomy, clearer ownership, and scalable team boundaries. They also inherit complexity: cross-repo change coordination, dependency compatibility, consistent CI/CD policy, security remediation at scale, and release governance. + +GitHub primitives (issues, pull requests, workflows) are repo-scoped by design. There is no native "multi-repo change object," so organizations must model one. Reusable workflows improve standardization but introduce questions of adoption, drift, failures, and versioning. Security remediation and platform migrations are continuous and inherently cross-repo. Leaders need enterprise dashboards while teams need a low-friction workflow that preserves autonomy. + +This article presents a GitHub-first operating model for polyrepo engineering, centered on an **integration layer (meta-repo)** pattern, **reusable workflows** as a versioned platform interface, and **orchestration for multi-repo execution**. The design emphasizes repeatability, auditability, and enterprise-scale observability while minimizing friction for individual service teams. ## Key design strategies and checklist 1. **Integration layer (meta-repo) for composition validation** - - Maintain a dedicated repository that answers "do these versions of - components work together?" by pinning each component to an immutable - reference (tag or SHA) in a manifest file. - - Without an integration layer, cross-repo contract changes and release - candidate validation rely on ad-hoc coordination, which breaks down - at scale. - - Anti-pattern: treating the integration repo as a monorepo that - contains code. It should hold only manifests, integration tests, and - CI configuration. - -2. **Change sets for cross-repo coordination** - - Model a "change set" as a parent tracking issue in the integration - repo, with child issues created in each affected component repo. PRs - and branches include a change set identifier (for example, `CHG-1042`) - for traceability. - - This creates a single coordination spine without requiring monorepo - consolidation. - - Anti-pattern: relying solely on Slack threads or spreadsheets for - cross-repo coordination, which lack auditability and automation hooks. - -3. **Branching and merge coordination model** - - Choose a merge coordination approach—integration branches, meta-repo - manifest, versioned artifacts, or linked PRs with merge gating—based - on the risk and scope of each type of cross-repo change. - - Establish consistent branch naming conventions and protect long-lived - branches with repository rulesets. - - Anti-pattern: allowing each team to invent its own branching - convention, which fragments automation and makes cross-repo - coordination brittle. - -4. **Reusable workflows as a versioned platform interface** - - Treat shared CI/CD workflows like a product: stable - inputs/secrets/outputs contract, semantic versioning with major tags - (`v1`, `v2`), changelogs, and migration guides. - - Protect the workflow repo with CODEOWNERS, required reviews, and - strict permissions. - - Anti-pattern: publishing workflows without versioning or breaking - changes without a migration path. - -5. **Component releases vs. system releases** - - Decouple individual component release cadences from system-level - releases. Components release independently (for example, `v1.8.2`), - while system releases happen in the integration repo (for example, - `system-2026.01.30`). + + - Maintain a dedicated repository that answers "do these versions of components work together?" by pinning each component to an immutable reference (tag or SHA) in a manifest file. + - Without an integration layer, cross-repo contract changes and release candidate validation rely on ad-hoc coordination, which breaks down at scale. + - Anti-pattern: treating the integration repo as a monorepo that contains code. It should hold only manifests, integration tests, and CI configuration. + +1. **Change sets for cross-repo coordination** + + - Model a "change set" as a parent tracking issue in the integration repo, with child issues created in each affected component repo. PRs and branches include a change set identifier (for example, `CHG-1042`) for traceability. + - This creates a single coordination spine without requiring monorepo consolidation. + - Anti-pattern: relying solely on Slack threads or spreadsheets for cross-repo coordination, which lack auditability and automation hooks. + +1. **Branching and merge coordination model** + + - Choose a merge coordination approach—integration branches, meta-repo manifest, versioned artifacts, or linked PRs with merge gating—based on the risk and scope of each type of cross-repo change. + - Establish consistent branch naming conventions and protect long-lived branches with repository rulesets. + - Anti-pattern: allowing each team to invent its own branching convention, which fragments automation and makes cross-repo coordination brittle. + +1. **Reusable workflows as a versioned platform interface** + + - Treat shared CI/CD workflows like a product: stable inputs/secrets/outputs contract, semantic versioning with major tags (`v1`, `v2`), changelogs, and migration guides. + - Protect the workflow repo with CODEOWNERS, required reviews, and strict permissions. + - Anti-pattern: publishing workflows without versioning or breaking changes without a migration path. + +1. **Component releases vs. system releases** + + - Decouple individual component release cadences from system-level releases. Components release independently (for example, `v1.8.2`), while system releases happen in the integration repo (for example, `system-2026.01.30`). - This avoids coupling all repos to a single cadence. -6. **Orchestration with a safety model** - - Use an orchestrator (GitHub App or service) for cross-repo discovery - and coordination, with repo-scoped automated execution for implementing - changes and opening PRs. - - Enforce repository rulesets and CODEOWNERS against - automation. Label artifacts for governance and - reporting. +1. **Orchestration with a safety model** + + - Use an orchestrator (GitHub App or service) for cross-repo discovery and coordination, with repo-scoped automated execution for implementing changes and opening PRs. + - Enforce repository rulesets and CODEOWNERS against automation. Label artifacts for governance and reporting. ### Quick checklist @@ -189,50 +155,30 @@ minimizing friction for individual service teams. | Pinning policy | Pin workflows and dependencies to stable tags or SHAs; avoid floating refs in production | {{< callout type="info" >}} -This article focuses on design thinking and coordination patterns for -polyrepo engineering. GitHub Docs remains the source of truth for -configuring individual features such as reusable workflows, rulesets, -and GitHub Advanced Security. +This article focuses on design thinking and coordination patterns for polyrepo engineering. GitHub Docs remains the source of truth for configuring individual features such as reusable workflows, rulesets, and GitHub Advanced Security. {{< /callout >}} ## Assumptions and preconditions -- The organization uses GitHub Enterprise Cloud (GHEC) or GHEC with - Enterprise Managed Users (EMU). -- Multiple component repositories already exist (or are planned), each - with clear ownership and bounded CI/CD. -- Teams have adopted or are willing to adopt GitHub Actions for CI/CD - workflows. -- GitHub Advanced Security (GHAS) is enabled for code scanning, Dependabot, - and secret scanning. -- The organization has an analytics or observability backend (for example, - Splunk, Datadog, Elastic, or Microsoft Sentinel) for workflow governance - dashboards. -- Teams have sufficient GitHub Actions minutes and runner capacity for - integration validation workflows. -- Organization administrators have approved the creation of integration - and workflow repositories. +- The organization uses GitHub Enterprise Cloud (GHEC) or GHEC with Enterprise Managed Users (EMU). +- Multiple component repositories already exist (or are planned), each with clear ownership and bounded CI/CD. +- Teams have adopted or are willing to adopt GitHub Actions for CI/CD workflows. +- GitHub Advanced Security (GHAS) is enabled for code scanning, Dependabot, and secret scanning. +- The organization has an analytics or observability backend (for example, Splunk, Datadog, Elastic, or Microsoft Sentinel) for workflow governance dashboards. +- Teams have sufficient GitHub Actions minutes and runner capacity for integration validation workflows. +- Organization administrators have approved the creation of integration and workflow repositories. ## Recommended implementation ### 1. Establish the integration layer (meta-repo) -Create a dedicated integration repository that serves as the composition -boundary for multi-repo validation and system releases. This repo should -contain: +Create a dedicated integration repository that serves as the composition boundary for multi-repo validation and system releases. This repo should contain: -- A **manifest file** (for example, `release.yaml`, `components.lock`, or - `versions.json`) mapping components to immutable references. -- **Integration and contract test suites** that validate component - compatibility. -- **CI workflows** that resolve the manifest, check out each component at - its pinned ref, build the composed system, and publish an integration - artifact. +- A **manifest file** (for example, `release.yaml`, `components.lock`, or `versions.json`) mapping components to immutable references. +- **Integration and contract test suites** that validate component compatibility. +- **CI workflows** that resolve the manifest, check out each component at its pinned ref, build the composed system, and publish an integration artifact. -Use release tags as the preferred reference type for production manifests. -Commit SHAs provide strong reproducibility. PR SHAs can be used for -pre-merge integration candidates but should be promoted to tags before -production. +Use release tags as the preferred reference type for production manifests. Commit SHAs provide strong reproducibility. PR SHAs can be used for pre-merge integration candidates but should be promoted to tags before production. Example manifest structure: @@ -262,15 +208,11 @@ A standard integration validation workflow: Because GitHub lacks a cross-repo change primitive, model one explicitly: -- Assign a **change set identifier** (for example, `CHG-1042`) to each - cross-repo change. -- Create a **parent tracking issue** in the integration repo with scope, - impacted repos, and acceptance criteria. -- Generate **child issues** in each affected component repo, linked to the - parent. +- Assign a **change set identifier** (for example, `CHG-1042`) to each cross-repo change. +- Create a **parent tracking issue** in the integration repo with scope, impacted repos, and acceptance criteria. +- Generate **child issues** in each affected component repo, linked to the parent. - Include the change set ID in PR titles and branch names for traceability. -- Update the integration manifest to reference PR SHAs during validation, - then promote to tags on success. +- Update the integration manifest to reference PR SHAs during validation, then promote to tags on success. Lifecycle of a multi-repo change: @@ -283,34 +225,17 @@ flowchart LR E --> F[Promote to RC
and production tags] ``` -Use GitHub Projects to track all issues and PRs in a change set. Configure -custom fields for change set ID, team, priority, SLA date, and status. -Automate status transitions from PR events and check results. +Use GitHub Projects to track all issues and PRs in a change set. Configure custom fields for change set ID, team, priority, SLA date, and status. Automate status transitions from PR events and check results. ### 3. Choose a branching and merge coordination model -Polyrepo systems need an explicit strategy for merging coordinated -changes across repositories. Unlike a monorepo where a single PR can -touch all affected code, polyrepo changes produce separate PRs that must -converge. Choose the model that matches your coordination frequency, -risk tolerance, and team maturity. +Polyrepo systems need an explicit strategy for merging coordinated changes across repositories. Unlike a monorepo where a single PR can touch all affected code, polyrepo changes produce separate PRs that must converge. Choose the model that matches your coordination frequency, risk tolerance, and team maturity. #### Option 1: Integration branch (release-train model — most reliable) -Each repo maintains `main` plus an `integration/` (or -`release/x.y`) branch. Coordinated PRs target the integration branch. A -central workflow checks out all repos at their integration refs and runs -end-to-end tests. If green, you promote by merging integration → `main` -in each repo, typically in an enforced order. - -Example: A breaking API change spans `auth-service`, `billing-api`, and -`web-frontend`. Each repo creates a branch -`integration/CHG-1042-auth-v3`. Developers open PRs against that branch. -A workflow in the integration repo checks out all three repos at their -`integration/CHG-1042-auth-v3` HEAD, builds the composed system, and -runs contract tests. Once green, a promotion script merges -integration → `main` in `auth-service` first (the provider), then the -two consumers, and tags each with `v3.0.0`. +Each repo maintains `main` plus an `integration/` (or `release/x.y`) branch. Coordinated PRs target the integration branch. A central workflow checks out all repos at their integration refs and runs end-to-end tests. If green, you promote by merging integration → `main` in each repo, typically in an enforced order. + +Example: A breaking API change spans `auth-service`, `billing-api`, and `web-frontend`. Each repo creates a branch `integration/CHG-1042-auth-v3`. Developers open PRs against that branch. A workflow in the integration repo checks out all three repos at their `integration/CHG-1042-auth-v3` HEAD, builds the composed system, and runs contract tests. Once green, a promotion script merges integration → `main` in `auth-service` first (the provider), then the two consumers, and tags each with `v3.0.0`. ```text auth-service main ─────────────────●── (merge + tag v3.0.0) @@ -329,16 +254,9 @@ web-frontend main ─────────────────● #### Option 2: Meta-repo manifest (common in enterprises) -A dedicated repo holds a manifest (lockfile) pinning each component to -an immutable ref. PRs in component repos trigger automated manifest -updates. CI validates the meta repo by checking out each repo at pinned -SHAs. Once the meta-repo PR merges, you tag the component repos -accordingly. See [Section 1](#1-establish-the-integration-layer-meta-repo) -for manifest structure. +A dedicated repo holds a manifest (lockfile) pinning each component to an immutable ref. PRs in component repos trigger automated manifest updates. CI validates the meta repo by checking out each repo at pinned SHAs. Once the meta-repo PR merges, you tag the component repos accordingly. See [Section 1](#1-establish-the-integration-layer-meta-repo) for manifest structure. -Example: A developer merges a feature in `billing-api` repo. Automation -updates the meta-repo manifest `release.yaml`, CI validates, and on success the -`integration` repo cuts a system release: +Example: A developer merges a feature in `billing-api` repo. Automation updates the meta-repo manifest `release.yaml`, CI validates, and on success the `integration` repo cuts a system release: ```mermaid flowchart LR @@ -355,33 +273,15 @@ flowchart LR #### Option 3: Versioned artifacts (decouple merges entirely) -Components merge and release independently, publishing immutable -artifacts (packages, containers) with a version tag. Downstream repos -consume artifacts at explicit versions. Coordination becomes -version-bump PRs rather than simultaneous merges. +Components merge and release independently, publishing immutable artifacts (packages, containers) with a version tag. Downstream repos consume artifacts at explicit versions. Coordination becomes version-bump PRs rather than simultaneous merges. -Example: `auth-service` publishes a container image -`ghcr.io/org/auth-service:v2.5.0`. The `web-frontend` repo has -Dependabot or a custom workflow that detects the new version and opens a -PR bumping the reference. The `web-frontend` team reviews and merges on their own cadence. No -cross-repo branch coordination is needed. +Example: `auth-service` publishes a container image `ghcr.io/org/auth-service:v2.5.0`. The `web-frontend` repo has Dependabot or a custom workflow that detects the new version and opens a PR bumping the reference. The `web-frontend` team reviews and merges on their own cadence. No cross-repo branch coordination is needed. #### Option 4: Linked PRs with merge gating (lighter-weight) -Keep PRs in each repo, link them, and only merge when all are ready. -Each PR references the others via labels (for example, -`changeset:CHG-1042`) or description links. A required status check -verifies all linked PRs are approved and passing before any can merge. -A bot merges them in a defined order. - -Example: A shared logging format change touches `auth-service` and -`billing-api`. Each repo gets a PR against `main` with the label -`changeset:CHG-1099`. A required status check (for example, a GitHub -Actions workflow triggered by `pull_request` events) queries the GitHub -API to verify that every PR with the same `changeset:CHG-1099` label is -approved and has passing checks. Only when all linked PRs are ready does -the bot merge them in the declared order: `auth-service` first, then -`billing-api`. +Keep PRs in each repo, link them, and only merge when all are ready. Each PR references the others via labels (for example, `changeset:CHG-1042`) or description links. A required status check verifies all linked PRs are approved and passing before any can merge. A bot merges them in a defined order. + +Example: A shared logging format change touches `auth-service` and `billing-api`. Each repo gets a PR against `main` with the label `changeset:CHG-1099`. A required status check (for example, a GitHub Actions workflow triggered by `pull_request` events) queries the GitHub API to verify that every PR with the same `changeset:CHG-1099` label is approved and has passing checks. Only when all linked PRs are ready does the bot merge them in the declared order: `auth-service` first, then `billing-api`. ```mermaid flowchart LR @@ -400,59 +300,36 @@ flowchart LR #### Selecting a coordination model -Most organizations use more than one of these options depending on the -type of change: +Most organizations use more than one of these options depending on the type of change: -- **Breaking API or contract changes** that span multiple repos typically - warrant the **integration branch** or **meta-repo manifest** approach - for strongest pre-merge validation. -- **Routine dependency updates** are best handled through **versioned - artifacts**, where each component releases independently and consumers - update at their own pace. -- **Small, low-risk cross-repo changes** (for example, a shared - configuration tweak affecting two repos) can use **linked PRs with - merge gating** to avoid process overhead. +- **Breaking API or contract changes** that span multiple repos typically warrant the **integration branch** or **meta-repo manifest** approach for strongest pre-merge validation. +- **Routine dependency updates** are best handled through **versioned artifacts**, where each component releases independently and consumers update at their own pace. +- **Small, low-risk cross-repo changes** (for example, a shared configuration tweak affecting two repos) can use **linked PRs with merge gating** to avoid process overhead. #### Branching conventions -Regardless of coordination model, establish consistent branch naming -across repos: - -- Use a shared prefix for coordinated work, for example - `changeset/CHG-1042/short-description` or - `integration/2026-q1-release`. -- Protect long-lived branches (`main`, `release/*`, `integration/*`) - with [repository rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) - to enforce required reviews, status checks, and linear history where - appropriate. -- Delete feature and changeset branches after merge to keep repos clean. - Configure - [automatic branch deletion](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches) - in repository settings. +Regardless of coordination model, establish consistent branch naming across repos: + +- Use a shared prefix for coordinated work, for example `changeset/CHG-1042/short-description` or `integration/2026-q1-release`. +- Protect long-lived branches (`main`, `release/*`, `integration/*`) with [repository rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) to enforce required reviews, status checks, and linear history where appropriate. +- Delete feature and changeset branches after merge to keep repos clean. Configure [automatic branch deletion](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches) in repository settings. {{< callout type="warning" >}} -Linked-PR merge gating without automation is fragile. Race conditions -can leave repos in an inconsistent state if merges happen out of order. -Always pair this approach with a merge-ordering bot or automation script. +Linked-PR merge gating without automation is fragile. Race conditions can leave repos in an inconsistent state if merges happen out of order. Always pair this approach with a merge-ordering bot or automation script. {{< /callout >}} ### 4. Set up reusable workflow governance -Create a centralized workflow repository and treat it as an internal -platform product: +Create a centralized workflow repository and treat it as an internal platform product: - Define stable contracts with documented inputs, secrets, and outputs. -- Use **semantic versioning** with major tags (`v1`, `v2`) and full - version tags (`v1.2.3`). -- Protect the repository with CODEOWNERS, required reviews, and branch - rulesets. +- Use **semantic versioning** with major tags (`v1`, `v2`) and full version tags (`v1.2.3`). +- Protect the repository with CODEOWNERS, required reviews, and branch rulesets. - Publish changelogs and migration guides for breaking changes. #### Workflow governance dashboard -GitHub does not provide a single enterprise-wide reusable workflow usage -report. Build a dashboard using your analytics backend with two -complementary data feeds: +GitHub does not provide a single enterprise-wide reusable workflow usage report. Build a dashboard using your analytics backend with two complementary data feeds: **Inventory (references)**: Shared workflows with the called ref. @@ -475,14 +352,10 @@ Recommended dashboard views: ### 5. Define the release governance model -Separate component releases from system releases to avoid coupling all -repos to one cadence: +Separate component releases from system releases to avoid coupling all repos to one cadence: -- **Component releases** happen per repo using version tags (for example, - `v1.8.2`). -- **System releases** happen in the integration repo (for example, - `system-2026.01.30`). The system release manifest provides a - reproducible bill of materials. +- **Component releases** happen per repo using version tags (for example, `v1.8.2`). +- **System releases** happen in the integration repo (for example, `system-2026.01.30`). The system release manifest provides a reproducible bill of materials. Promotion pipeline: @@ -494,26 +367,20 @@ Promotion pipeline: | Production | Manifest points to stable tags; system release cut | Final validation | {{< callout type="warning" >}} -Avoid floating refs (`@main`) in production paths. Pin workflows and -dependencies to stable references: reusable workflows at `@vN` or -`@vN.N.N`, and integration manifests at release tags or SHAs. Use PR -SHAs only in integration candidates, then promote to tags. +Avoid floating refs (`@main`) in production paths. Pin workflows and dependencies to stable references: reusable workflows at `@vN` or `@vN.N.N`, and integration manifests at release tags or SHAs. Use PR SHAs only in integration candidates, then promote to tags. {{< /callout >}} ### 6. Implement security campaigns with GHAS -Use GitHub Advanced Security capabilities as the system of record for -detection: +Use GitHub Advanced Security capabilities as the system of record for detection: - **Code scanning** for vulnerability detection in source code - **Dependabot alerts** for dependency vulnerabilities - **Secret scanning** for exposed credentials -Create a Security Campaign with included repos, clear SLA processes, -assigned ownership, and progress and exception reporting. +Create a Security Campaign with included repos, clear SLA processes, assigned ownership, and progress and exception reporting. -If policy requires an issue per alert, implement alert-to-issue automation -with: +If policy requires an issue per alert, implement alert-to-issue automation with: - Severity thresholds to control issue volume - Deduplication by alert identifier @@ -524,15 +391,11 @@ with: Use the **orchestrator/executor pattern** for multi-repo operations: -- **Orchestrator** (GitHub App or service): Handles cross-repo discovery, - creates standardized issues across repos, and coordinates work via - GitHub Projects. -- **Executor** (repo-scoped automated execution): Implements changes and opens PRs - within a single repository where it has local context. +- **Orchestrator** (GitHub App or service): Handles cross-repo discovery, creates standardized issues across repos, and coordinates work via GitHub Projects. +- **Executor** (repo-scoped automated execution): Implements changes and opens PRs within a single repository where it has local context. {{< callout type="info" >}} -This recommendation focuses on automation in general. Automated execution -can range from deterministic scripts to generative agents. +This recommendation focuses on automation in general. Automated execution can range from deterministic scripts to generative agents. {{< /callout >}} Multi-repo issue creation by the orchestrator should include: @@ -544,56 +407,33 @@ Multi-repo issue creation by the orchestrator should include: Safety model for automated execution: -- Use GitHub Apps with least-privilege permissions instead of personal - access tokens. +- Use GitHub Apps with least-privilege permissions instead of personal access tokens. - Enforce repository rulesets and CODEOWNERS against automation. - Rate-limit and stage rollouts across repos. - Label all automated artifacts for governance and reporting. ### 8. Compose a unified experience -A single pane of glass for polyrepo engineering is created by combining -multiple views: +A single pane of glass for polyrepo engineering is created by combining multiple views: -- **GitHub Projects** as the work hub for cross-repo tracking, containing - parent tracking issues, child issues, and linked PRs with custom fields - for change set, team, priority, and SLA date. -- **Workflow governance dashboards** for enterprise CI visibility (adoption, - reliability, performance, and version migration progress). -- **GHAS overview** plus execution boards for security posture and - remediation tracking. -- Correlation identifiers (change set IDs, workflow version refs) that tie - views together. +- **GitHub Projects** as the work hub for cross-repo tracking, containing parent tracking issues, child issues, and linked PRs with custom fields for change set, team, priority, and SLA date. +- **Workflow governance dashboards** for enterprise CI visibility (adoption, reliability, performance, and version migration progress). +- **GHAS overview** plus execution boards for security posture and remediation tracking. +- Correlation identifiers (change set IDs, workflow version refs) that tie views together. -Some enterprises add an **internal developer portal** that aggregates the -current system release manifest, active change sets, workflow health -metrics, and security posture summaries. This portal is backed by GitHub -APIs, analytics queries, and service catalog metadata. +Some enterprises add an **internal developer portal** that aggregates the current system release manifest, active change sets, workflow health metrics, and security posture summaries. This portal is backed by GitHub APIs, analytics queries, and service catalog metadata. ## Additional solution detail and trade-offs to consider ### Why a meta-repo instead of a monorepo -The integration layer pattern preserves team autonomy by keeping component -code in separate repositories while adding a thin coordination layer. -Unlike a monorepo, it does not require teams to share a single build -system, CI pipeline, or branching strategy. However, it introduces -additional operational overhead: the manifest must be kept current, and -integration CI must be reliable enough to serve as a gate. +The integration layer pattern preserves team autonomy by keeping component code in separate repositories while adding a thin coordination layer. Unlike a monorepo, it does not require teams to share a single build system, CI pipeline, or branching strategy. However, it introduces additional operational overhead: the manifest must be kept current, and integration CI must be reliable enough to serve as a gate. -**When this is not a good fit**: Organizations with fewer than ten -repositories or tightly coupled components may find a monorepo simpler. -The meta-repo pattern adds value primarily when teams operate at different -cadences, when component ownership boundaries are clear, and when the -organization needs to validate cross-repo compatibility at scale. +**When this is not a good fit**: Organizations with fewer than ten repositories or tightly coupled components may find a monorepo simpler. The meta-repo pattern adds value primarily when teams operate at different cadences, when component ownership boundaries are clear, and when the organization needs to validate cross-repo compatibility at scale. ### Change set overhead -The change set pattern adds a layer of process (parent/child issues, -naming conventions, manifest updates) that may feel heavyweight for small -teams. The benefit scales with the number of repos and teams involved in -cross-cutting changes. Start with lightweight conventions (a consistent -issue title prefix) and formalize only as coordination pain increases. +The change set pattern adds a layer of process (parent/child issues, naming conventions, manifest updates) that may feel heavyweight for small teams. The benefit scales with the number of repos and teams involved in cross-cutting changes. Start with lightweight conventions (a consistent issue title prefix) and formalize only as coordination pain increases. ### Tradeoffs of branching and coordination options @@ -604,11 +444,7 @@ issue title prefix) and formalize only as coordination pain increases. | Versioned artifacts | Most scalable; fully decoupled release cadences | Requires mature artifact and versioning discipline; slower feedback on integration issues | Teams with clear producer/consumer relationships and mature CI/CD pipelines | | Linked PRs with merge gating | Minimal branching complexity; works with existing `main` flow | Not atomic; race conditions without a merge-ordering bot | Small-scope cross-repo changes where process overhead must be minimal | -Many organizations start with **linked PRs** for simplicity and graduate -to the **integration branch** or **meta-repo manifest** model as the -number of coordinated cross-repo changes grows. **Versioned artifacts** -work well in parallel for components with clear producer/consumer -boundaries. +Many organizations start with **linked PRs** for simplicity and graduate to the **integration branch** or **meta-repo manifest** model as the number of coordinated cross-repo changes grows. **Versioned artifacts** work well in parallel for components with clear producer/consumer boundaries. ### Reusable workflow versioning trade-offs @@ -618,24 +454,16 @@ boundaries. | Pin to exact version (`@v1.2.3`) | Full reproducibility | Requires manual updates for every fix | | Pin to SHA | Strongest immutability | Difficult to audit and manage at scale | -In most organizations, pinning to major tags with a documented -compatibility contract strikes the best balance. Use exact versions or -SHAs for regulated or high-assurance pipelines. +In most organizations, pinning to major tags with a documented compatibility contract strikes the best balance. Use exact versions or SHAs for regulated or high-assurance pipelines. ### Automated execution guardrails -Automated execution, especially agentic execution operating across repos, -can amplify both productivity and risk. -Without guardrails, they can create excessive issues, open low-quality -PRs, or consume significant Actions compute. Key mitigations: +Automated execution, especially agentic execution operating across repos, can amplify both productivity and risk. Without guardrails, they can create excessive issues, open low-quality PRs, or consume significant Actions compute. Key mitigations: - Scope each execution to a single repo with limited permissions. -- Use repository rulesets and required reviews to gate all automated - changes. -- Implement rate limits at the orchestrator level to prevent runaway - execution. -- Monitor automated execution activity through labels and dashboards to detect anomalies - early. +- Use repository rulesets and required reviews to gate all automated changes. +- Implement rate limits at the orchestrator level to prevent runaway execution. +- Monitor automated execution activity through labels and dashboards to detect anomalies early. ### Phased adoption roadmap @@ -658,4 +486,4 @@ Adopt these patterns incrementally rather than all at once: ### External resources -- [Exploring repository architecture strategy]({{< relref "scaling-git-repositories/repository-architecture-strategy.md" >}}) +- [Exploring repository architecture strategy](./scaling-git-repositories/repository-architecture-strategy) diff --git a/content/library/architecture/recommendations/index.yml b/content/library/architecture/recommendations/index.yml new file mode 100644 index 0000000..57eac37 --- /dev/null +++ b/content/library/architecture/recommendations/index.yml @@ -0,0 +1,3 @@ +title: Recommendations +slug: recommendations +weight: 5 diff --git a/content/library/architecture/recommendations/overview.md b/content/library/architecture/recommendations/overview.md new file mode 100644 index 0000000..ca90de1 --- /dev/null +++ b/content/library/architecture/recommendations/overview.md @@ -0,0 +1,14 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +prev: library/architecture +--- + + +This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 📐 **Architecture** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. + +Articles in this section include: + +{{< child-pages >}} diff --git a/content/library/architecture/recommendations/scaling-git-repositories/_index.md b/content/library/architecture/recommendations/scaling-git-repositories/_index.md index 8b61561..c6f11e1 100644 --- a/content/library/architecture/recommendations/scaling-git-repositories/_index.md +++ b/content/library/architecture/recommendations/scaling-git-repositories/_index.md @@ -2,16 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish -title: 'Scaling Git repositories' +title: Overview +linkTitle: Scaling Git repositories +weight: 6 --- - -As software projects grow in size and complexity, managing Git repositories becomes increasingly challenging. -One common scenario that many teams face is dealing with a monorepo, where all the code for multiple projects is stored in a single repository. -There can also be varying definitions of what constitutes a "monorepository". -While monorepos offer benefits such as simplified dependency management and easier code sharing, they also present unique challenges. -These challenges include longer clone times, increased storage requirements, and more complex CI/CD pipelines. -In the following guides, we will explore various strategies and best practices for scaling Git repositories to handle large codebases efficiently. - -- [Exploring repository architecture strategies]({{< relref "repository-architecture-strategy.md" >}}) -- [Managing large Git repositories]({{< relref "large-git-repositories.md" >}}) -- [When to use Git LFS]({{< relref "when-to-use-git-lfs.md" >}}) diff --git a/content/library/architecture/recommendations/scaling-git-repositories/index.yml b/content/library/architecture/recommendations/scaling-git-repositories/index.yml new file mode 100644 index 0000000..b3f1a83 --- /dev/null +++ b/content/library/architecture/recommendations/scaling-git-repositories/index.yml @@ -0,0 +1,3 @@ +title: Scaling Git repositories +slug: scaling-git-repositories +weight: 6 diff --git a/content/library/architecture/recommendations/scaling-git-repositories/large-git-repositories.md b/content/library/architecture/recommendations/scaling-git-repositories/large-git-repositories.md index aeba3b7..88ace86 100644 --- a/content/library/architecture/recommendations/scaling-git-repositories/large-git-repositories.md +++ b/content/library/architecture/recommendations/scaling-git-repositories/large-git-repositories.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Managing large Git Repositories' +weight: 3 publishDate: 2024-09-03 params: authors: [{ name: 'Steffen Hiller', handle: 'steffen' }] @@ -115,7 +116,7 @@ This section defines the key design strategies that a company could employ to im ### 2. **Efficient Storage Management** -- **Using Git LFS**: Using Git Large File Storage (LFS) to manage large files outside of the Git repository will help keep the repository size mangeable and improve performance for standard Git operations. Moving files to LFS after they have already been committed to the repository will require rewriting history. See [When to use Git LFS](/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs/). +- **Using Git LFS**: Using Git Large File Storage (LFS) to manage large files outside of the Git repository will help keep the repository size mangeable and improve performance for standard Git operations. Moving files to LFS after they have already been committed to the repository will require rewriting history. See [When to use Git LFS](./when-to-use-git-lfs). - **Managing Old Data**: A well-maintained repository not only improves collaboration but also reduces potential workload on Git servers. Cleaning up stale pull requests and removing or archiving obsolete branches and tags helps streamline the repository and minimize storage usage. Consistently maintaining a tidy repository will keep the size manageable and reduce the likelihood of performance issues. ### 3. **History and Version Control Optimization** diff --git a/content/library/architecture/recommendations/scaling-git-repositories/overview.md b/content/library/architecture/recommendations/scaling-git-repositories/overview.md new file mode 100644 index 0000000..4dbd4cf --- /dev/null +++ b/content/library/architecture/recommendations/scaling-git-repositories/overview.md @@ -0,0 +1,20 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +draft: false # Set to false when ready to publish +title: Overview +linkTitle: Scaling Git repositories +weight: 1 +--- + + +As software projects grow in size and complexity, managing Git repositories becomes increasingly challenging. +One common scenario that many teams face is dealing with a monorepo, where all the code for multiple projects is stored in a single repository. +There can also be varying definitions of what constitutes a "monorepository". +While monorepos offer benefits such as simplified dependency management and easier code sharing, they also present unique challenges. +These challenges include longer clone times, increased storage requirements, and more complex CI/CD pipelines. +In the following guides, we will explore various strategies and best practices for scaling Git repositories to handle large codebases efficiently. + +- [Exploring repository architecture strategies](./repository-architecture-strategy) +- [Managing large Git repositories](./large-git-repositories) +- [When to use Git LFS](./when-to-use-git-lfs) diff --git a/content/library/architecture/recommendations/scaling-git-repositories/repository-architecture-strategy.md b/content/library/architecture/recommendations/scaling-git-repositories/repository-architecture-strategy.md index 3012fb6..f6f0bd8 100644 --- a/content/library/architecture/recommendations/scaling-git-repositories/repository-architecture-strategy.md +++ b/content/library/architecture/recommendations/scaling-git-repositories/repository-architecture-strategy.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Exploring repository architecture strategy' +weight: 2 publishDate: 2024-09-03 params: authors: [{ name: 'Steffen Hiller', handle: 'steffen' }] diff --git a/content/library/architecture/recommendations/scaling-git-repositories/schema.json b/content/library/architecture/recommendations/scaling-git-repositories/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/architecture/recommendations/scaling-git-repositories/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs.md b/content/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs.md index d8e3cb7..79a38e1 100644 --- a/content/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs.md +++ b/content/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'When to use Git LFS' +weight: 4 publishDate: 2024-09-03 params: authors: [ @@ -237,13 +238,13 @@ Compression ratio: 84.9% To our beloved friend John ([@jwiebalk](https://github.com/jwiebalk)), a Hubber who was always there to help and never wanted the credit. ❤️ ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/architecture/recommendations/schema.json b/content/library/architecture/recommendations/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/architecture/recommendations/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/architecture/schema.json b/content/library/architecture/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/architecture/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/collaboration/_index.md b/content/library/collaboration/_index.md index 04f94a6..084595e 100644 --- a/content/library/collaboration/_index.md +++ b/content/library/collaboration/_index.md @@ -1,16 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: 👥 Collaboration +title: Overview +linkTitle: Collaboration weight: 4 -slug: collaboration --- - -The **Collaboration** pillar emphasizes the tools and practices that enhance teamwork within and across teams. It could involve principles related to pull requests, code reviews, project boards, and other collaborative features of GitHub. - -{{< cards >}} - {{< card link="quick-links" title="Quick Links" icon="sparkles" >}} - {{< card link="design-principles" title="Design Principles" icon="book-open" >}} - {{< card link="checklist" title="Assessment Checklist" icon="book-open" >}} - {{< card link="recommendations" title="Recommendations" icon="book-open" >}} -{{< /cards >}} diff --git a/content/library/collaboration/checklist.md b/content/library/collaboration/checklist.md index 930b60a..8ead308 100644 --- a/content/library/collaboration/checklist.md +++ b/content/library/collaboration/checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Collaboration -weight: 3 +weight: 4 prev: library/collaboration/design-principles next: library/collaboration/recommendations --- diff --git a/content/library/collaboration/design-principles.md b/content/library/collaboration/design-principles.md index bd9cbdb..307c2e1 100644 --- a/content/library/collaboration/design-principles.md +++ b/content/library/collaboration/design-principles.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Design Principles -weight: 2 +weight: 3 prev: library/collaboration/quick-links next: library/collaboration/checklist --- diff --git a/content/library/collaboration/index.yml b/content/library/collaboration/index.yml new file mode 100644 index 0000000..a58c397 --- /dev/null +++ b/content/library/collaboration/index.yml @@ -0,0 +1,5 @@ +title: Collaboration +description: Inclusive practices and transparent project management to foster open knowledge sharing, enhance teamwork, and boost overall productivity. +weight: 4 +slug: collaboration +icon: PeopleIcon diff --git a/content/library/collaboration/overview.md b/content/library/collaboration/overview.md new file mode 100644 index 0000000..d732322 --- /dev/null +++ b/content/library/collaboration/overview.md @@ -0,0 +1,16 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +The **Collaboration** pillar emphasizes the tools and practices that enhance teamwork within and across teams. It could involve principles related to pull requests, code reviews, project boards, and other collaborative features of GitHub. + +{{< cards >}} + {{< card link="./quick-links" title="Quick Links" >}} + {{< card link="./design-principles" title="Design Principles" >}} + {{< card link="./checklist" title="Assessment Checklist" >}} + {{< card link="./recommendations/overview" title="Recommendations" >}} +{{< /cards >}} diff --git a/content/library/collaboration/quick-links.md b/content/library/collaboration/quick-links.md index 00c5e9a..52b9fee 100644 --- a/content/library/collaboration/quick-links.md +++ b/content/library/collaboration/quick-links.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Quick links -weight: 1 +weight: 2 prev: library/collaboration next: library/collaboration/design-principles --- diff --git a/content/library/collaboration/recommendations/_index.md b/content/library/collaboration/recommendations/_index.md index c175275..fae5954 100644 --- a/content/library/collaboration/recommendations/_index.md +++ b/content/library/collaboration/recommendations/_index.md @@ -1,13 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Recommendations +title: Overview +linkTitle: Recommendations weight: 5 -prev: library/collaboration --- - -This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 👥 **Collaboration** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. - -Articles in this section include: - -{{< child-pages >}} diff --git a/content/library/collaboration/recommendations/applying-devops-methodology.md b/content/library/collaboration/recommendations/applying-devops-methodology.md index f999702..ecb458d 100644 --- a/content/library/collaboration/recommendations/applying-devops-methodology.md +++ b/content/library/collaboration/recommendations/applying-devops-methodology.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Applying DevOps methodology' +weight: 4 publishDate: 2024-07-31 params: authors: [ @@ -119,13 +120,13 @@ The public cloud's growth has added complexity but also enabled faster, more fre By closing the development-operations gap and fostering better collaboration, organizations can achieve more efficient and reliable software delivery. Learn more by checking out the GitHub blog article on [The evolving role of operations in DevOps](https://github.blog/enterprise-software/devops/the-evolving-role-of-operations-in-devops/). ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/collaboration/recommendations/champion-program/champion-handbook.pdf b/content/library/collaboration/recommendations/assets/champion-handbook.pdf similarity index 100% rename from content/library/collaboration/recommendations/champion-program/champion-handbook.pdf rename to content/library/collaboration/recommendations/assets/champion-handbook.pdf diff --git a/content/library/collaboration/recommendations/champion-program/champion-handbook.png b/content/library/collaboration/recommendations/assets/champion-handbook.png similarity index 100% rename from content/library/collaboration/recommendations/champion-program/champion-handbook.png rename to content/library/collaboration/recommendations/assets/champion-handbook.png diff --git a/content/library/collaboration/recommendations/champion-program/champion-program-charter.pdf b/content/library/collaboration/recommendations/assets/champion-program-charter.pdf similarity index 100% rename from content/library/collaboration/recommendations/champion-program/champion-program-charter.pdf rename to content/library/collaboration/recommendations/assets/champion-program-charter.pdf diff --git a/content/library/collaboration/recommendations/champion-program/champion-program-charter.png b/content/library/collaboration/recommendations/assets/champion-program-charter.png similarity index 100% rename from content/library/collaboration/recommendations/champion-program/champion-program-charter.png rename to content/library/collaboration/recommendations/assets/champion-program-charter.png diff --git a/content/library/collaboration/recommendations/champion-program/index.md b/content/library/collaboration/recommendations/champion-program.md similarity index 94% rename from content/library/collaboration/recommendations/champion-program/index.md rename to content/library/collaboration/recommendations/champion-program.md index b0fd7b6..2eae9a8 100644 --- a/content/library/collaboration/recommendations/champion-program/index.md +++ b/content/library/collaboration/recommendations/champion-program.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Champion Program' +weight: 2 publishDate: 2025-09-15 params: authors: [{ name: 'Kyle Bridgford', handle: 'kbridgford' }] @@ -102,9 +103,6 @@ Champion programs are different than train-the-trainer programs. Train-the-train ## Recommended program deployment -{{< tabs items="🏗️ Foundation,📋 Structure,🔍 Recruit,🎓 Onboard,🚀 Launch,📈 Scale" >}} - -{{< tab >}} **Foundation phase** Set the groundwork for your champion program. @@ -115,9 +113,7 @@ Set the groundwork for your champion program. {{< callout type="info" emoji="🏆" >}} Executive sponsorship is critical for program success and champion protection. {{< /callout >}} -{{< /tab >}} -{{< tab >}} **Program structure** Define how your program will operate. @@ -129,9 +125,7 @@ Define how your program will operate. {{< callout type="info" emoji="📐" >}} Clear role definitions prevent confusion and ensure champions know their responsibilities. {{< /callout >}} -{{< /tab >}} -{{< tab >}} **Recruit champions** Find the right people to drive your program. @@ -142,9 +136,7 @@ Find the right people to drive your program. {{< callout type="info" emoji="🎯" >}} The most effective champions are often individual contributors who are already enthusiastic about the technology. {{< /callout >}} -{{< /tab >}} -{{< tab >}} **Onboard champions** Prepare your champions for success. @@ -156,9 +148,7 @@ Prepare your champions for success. {{< callout type="info" emoji="💡" >}} Invest heavily in champion onboarding - well-prepared champions are more effective advocates. {{< /callout >}} -{{< /tab >}} -{{< tab >}} **Launch community** Kick off your program with momentum. @@ -170,9 +160,7 @@ Kick off your program with momentum. {{< callout type="info" emoji="🚀" >}} A strong launch creates visibility and establishes the program's importance in the organization. {{< /callout >}} -{{< /tab >}} -{{< tab >}} **Iterate and scale** Continuously improve and expand your program. @@ -185,17 +173,14 @@ Continuously improve and expand your program. {{< callout type="info" emoji="🔄" >}} Regular reflection and iteration ensure your program stays relevant and effective as your organization evolves. {{< /callout >}} -{{< /tab >}} - -{{< /tabs >}} ## Templates and resources To help get started, here is a charter template and champion handbook that can be customized to fit your organization's needs. {{< cards >}} -{{< card link="https://gh.io/waf-cp-charter" title="Champion program charter" image="champion-program-charter.png" >}} -{{< card link="https://gh.io/waf-cp-handbook" title="Champion handbook" image="champion-handbook.png" >}} +{{< card link="https://gh.io/waf-cp-charter" title="Champion program charter" image="../assets/champion-program-charter.png" >}} +{{< card link="https://gh.io/waf-cp-handbook" title="Champion handbook" image="../assets/champion-handbook.png" >}} {{< /cards >}} ## Additional solution detail and trade-offs to consider @@ -206,13 +191,13 @@ Champions have their own full-time jobs. The program asks them to voluntarily ta ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/collaboration/recommendations/index.yml b/content/library/collaboration/recommendations/index.yml new file mode 100644 index 0000000..c02f586 --- /dev/null +++ b/content/library/collaboration/recommendations/index.yml @@ -0,0 +1,3 @@ +title: Recommendations +weight: 5 +slug: recommendations diff --git a/content/library/collaboration/recommendations/overview.md b/content/library/collaboration/recommendations/overview.md new file mode 100644 index 0000000..6b9316a --- /dev/null +++ b/content/library/collaboration/recommendations/overview.md @@ -0,0 +1,13 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 👥 **Collaboration** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. + +Articles in this section include: + +{{< child-pages >}} diff --git a/content/library/collaboration/recommendations/scaling-actions-reusability/index.md b/content/library/collaboration/recommendations/scaling-actions-reusability.md similarity index 99% rename from content/library/collaboration/recommendations/scaling-actions-reusability/index.md rename to content/library/collaboration/recommendations/scaling-actions-reusability.md index 0a67f6e..c1e1da5 100644 --- a/content/library/collaboration/recommendations/scaling-actions-reusability/index.md +++ b/content/library/collaboration/recommendations/scaling-actions-reusability.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false title: 'Scaling GitHub Actions Reusability in the Enterprise' +weight: 3 publishDate: 2025-04-10 params: authors: [{ name: 'Suleiman Suleiman', handle: 'ssulei7' }] diff --git a/content/library/collaboration/recommendations/schema.json b/content/library/collaboration/recommendations/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/collaboration/recommendations/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/collaboration/schema.json b/content/library/collaboration/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/collaboration/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/governance/_index.md b/content/library/governance/_index.md index 4c7c816..f7eb629 100644 --- a/content/library/governance/_index.md +++ b/content/library/governance/_index.md @@ -1,16 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: 📜 Governance +title: Overview +linkTitle: Governance weight: 6 -slug: governance --- - -The **Governance** pillar focuses on managing and overseeing the use of GitHub in a way that meets the organization's needs and complies with its policies. It could involve principles related to permissions, access controls, and audit logs. - -{{< cards >}} - {{< card link="quick-links" title="Quick Links" icon="sparkles" >}} - {{< card link="design-principles" title="Design Principles" icon="book-open" >}} - {{< card link="checklist" title="Assessment Checklist" icon="book-open" >}} - {{< card link="recommendations" title="Recommendations" icon="book-open" >}} -{{< /cards >}} diff --git a/content/library/governance/checklist.md b/content/library/governance/checklist.md index 69da138..79fd7c0 100644 --- a/content/library/governance/checklist.md +++ b/content/library/governance/checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Governance -weight: 3 +weight: 4 prev: library/governance/design-principles next: library/governance/recommendations --- @@ -16,7 +16,7 @@ This assessment checklist focuses on evaluating and enhancing the **Governance** - Leverage pull requests and enforce branch rules to maintain code quality. - Verify that required status checks are enabled. - Ensure code review requirements are set. - + - **Compliance Checks:** - Review compliance checks for code and dependencies. - Ensure automated tools are integrated for continuous compliance. diff --git a/content/library/governance/design-principles.md b/content/library/governance/design-principles.md index d6e4767..3bb1cb2 100644 --- a/content/library/governance/design-principles.md +++ b/content/library/governance/design-principles.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Design Principles -weight: 2 +weight: 3 prev: library/governance/quick-links next: library/governance/checklist --- diff --git a/content/library/governance/index.yml b/content/library/governance/index.yml new file mode 100644 index 0000000..c27ffe4 --- /dev/null +++ b/content/library/governance/index.yml @@ -0,0 +1,5 @@ +title: Governance +description: Clear policies and controls that balance innovation with oversight, ensuring compliance, access management, and accountability at scale. +weight: 6 +slug: governance +icon: LawIcon diff --git a/content/library/governance/overview.md b/content/library/governance/overview.md new file mode 100644 index 0000000..21fd616 --- /dev/null +++ b/content/library/governance/overview.md @@ -0,0 +1,16 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +The **Governance** pillar focuses on managing and overseeing the use of GitHub in a way that meets the organization's needs and complies with its policies. It could involve principles related to permissions, access controls, and audit logs. + +{{< cards >}} + {{< card link="./quick-links" title="Quick Links" >}} + {{< card link="./design-principles" title="Design Principles" >}} + {{< card link="./checklist" title="Assessment Checklist" >}} + {{< card link="./recommendations/overview" title="Recommendations" >}} +{{< /cards >}} diff --git a/content/library/governance/quick-links.md b/content/library/governance/quick-links.md index 0143691..9307600 100644 --- a/content/library/governance/quick-links.md +++ b/content/library/governance/quick-links.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Quick links -weight: 1 +weight: 2 prev: library/governance next: library/governance/design-principles --- diff --git a/content/library/governance/recommendations/_index.md b/content/library/governance/recommendations/_index.md index 25b6f87..fae5954 100644 --- a/content/library/governance/recommendations/_index.md +++ b/content/library/governance/recommendations/_index.md @@ -1,13 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Recommendations +title: Overview +linkTitle: Recommendations weight: 5 -prev: library/governance --- - -This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 📜 **Governance** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. - -Articles in this section include: - -{{< child-pages >}} diff --git a/content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-1.png b/content/library/governance/recommendations/assets/enterprise-account-model-1.png similarity index 100% rename from content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-1.png rename to content/library/governance/recommendations/assets/enterprise-account-model-1.png diff --git a/content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-2.png b/content/library/governance/recommendations/assets/enterprise-account-model-2.png similarity index 100% rename from content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-2.png rename to content/library/governance/recommendations/assets/enterprise-account-model-2.png diff --git a/content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-3.png b/content/library/governance/recommendations/assets/enterprise-account-model-3.png similarity index 100% rename from content/library/governance/recommendations/governance-administration-essentials/enterprise-account-model-3.png rename to content/library/governance/recommendations/assets/enterprise-account-model-3.png diff --git a/content/library/governance/recommendations/governance-administration-essentials/enterprise-account-overview.png b/content/library/governance/recommendations/assets/enterprise-account-overview.png similarity index 100% rename from content/library/governance/recommendations/governance-administration-essentials/enterprise-account-overview.png rename to content/library/governance/recommendations/assets/enterprise-account-overview.png diff --git a/content/library/governance/recommendations/governance-policies-best-practices/image1.png b/content/library/governance/recommendations/assets/image1.png similarity index 100% rename from content/library/governance/recommendations/governance-policies-best-practices/image1.png rename to content/library/governance/recommendations/assets/image1.png diff --git a/content/library/governance/recommendations/governance-policies-best-practices/image2.png b/content/library/governance/recommendations/assets/image2.png similarity index 100% rename from content/library/governance/recommendations/governance-policies-best-practices/image2.png rename to content/library/governance/recommendations/assets/image2.png diff --git a/content/library/governance/recommendations/governance-administration-essentials/index.md b/content/library/governance/recommendations/governance-administration-essentials.md similarity index 98% rename from content/library/governance/recommendations/governance-administration-essentials/index.md rename to content/library/governance/recommendations/governance-administration-essentials.md index 48c6924..4c8c905 100644 --- a/content/library/governance/recommendations/governance-administration-essentials/index.md +++ b/content/library/governance/recommendations/governance-administration-essentials.md @@ -4,6 +4,7 @@ draft: false title: 'Essentials of governance and administration with GitHub Enterprise' publishDate: 2026-04-23 +weight: 3 params: authors: - handle: 'rhoticity' @@ -80,7 +81,7 @@ Each section offers opinionated, prescriptive guidance on architecture and polic GHEC provides a number of flexible configuration options, allowing each business to configure the platform to best meet their unique needs. While there is no single "best" way to implement GHEC, there are common patterns and steps you should carefully consider. GHEC has four structural layers that should be treated as separate control planes: enterprise account, organization, repository, and team. Each provides different levels of administrative control and policy enforcement, and understanding how they interact is essential for sound governance. -![GHEC structural layers: enterprise account, enterprise teams, organizations, repositories, and teams](enterprise-account-overview.png) +![GHEC structural layers: enterprise account, enterprise teams, organizations, repositories, and teams](./assets/enterprise-account-overview.png) ### Enterprise account @@ -198,7 +199,7 @@ The following three models represent the most common organization architecture p ### Model 1: Single organization -![Model 1: Single organization](enterprise-account-model-1.png) +![Model 1: Single organization](./assets/enterprise-account-model-1.png) A single organization serves all or the vast majority of repositories. This model works well when your collaboration, compliance, and access needs can be managed within a single administrative boundary using teams and repository permissions. @@ -208,7 +209,7 @@ Slight variations on this model exist to handle extenuating circumstances. For e ### Model 2: Red-green-sandbox-archive -![Enterprise account: Red-green-sandbox-archive model](enterprise-account-model-2.png) +![Enterprise account: Red-green-sandbox-archive model](./assets/enterprise-account-model-2.png) This model uses two primary organizations plus a sandbox: @@ -219,7 +220,7 @@ This model uses two primary organizations plus a sandbox: ### Model 3: Portfolio company -![Model 3: Portfolio company](enterprise-account-model-3.png) +![Model 3: Portfolio company](./assets/enterprise-account-model-3.png) There are a few scenarios in which the red-green model may not adequately match your company's internal structures. Very large companies with tens of thousands of employees divided into relatively static business units may find this model insufficient. Also in this camp are portfolio companies with operating units that function independently of one another. These companies may also experience regular mergers, acquisitions, and divestitures. @@ -381,7 +382,7 @@ Configurations and policies not applied at the enterprise level are managed in e It's a best practice to review your policies and configurations with all stakeholders, including members from development, security, operations, and any other affiliated teams. You want to optimize for both the collaboration and flexibility your end users need to get their work done, as well as the compliance and security requirements you need to protect your company. {{< callout type="info" >}} -Enterprise policy and settings require ongoing maintenance and review to make sure that they are up to date and meet the evolving needs of your organization. For more details, see [governance policies best practices]({{< relref "../governance-policies-best-practices/index.md" >}}) page. +Enterprise policy and settings require ongoing maintenance and review to make sure that they are up to date and meet the evolving needs of your organization. For more details, see [governance policies best practices](./governance-policies-best-practices) page. {{< /callout >}} ## Billing, licensing, and consumption services @@ -450,7 +451,7 @@ Anyone with read access to a repository can see what rulesets are actively appli Rules can be set to "evaluate" mode to check how they would apply before enforcement. The [rule insights page](https://docs.github.com/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#viewing-insights-for-rulesets) shows which actions would be affected. {{< callout type="info" >}} -Branch protection rules are a legacy method of mergeability control. Rulesets are more flexible and functional and are the preferred approach going forward. For deep guidance on rulesets, see [repository rulesets best practices]({{< relref "../managing-repositories-at-scale/rulesets-best-practices.md" >}}) page. +Branch protection rules are a legacy method of mergeability control. Rulesets are more flexible and functional and are the preferred approach going forward. For deep guidance on rulesets, see [repository rulesets best practices](./managing-repositories-at-scale/rulesets-best-practices) page. {{< /callout >}} ### Repository settings @@ -463,7 +464,7 @@ For any repository-level settings, these must be set to be more restrictive than Custom properties let you define a structured metadata schema for repositories. You can classify repositories by data sensitivity, team ownership, compliance scope, or any other dimension that drives governance decisions. Properties can be required, with allowed values enforced at repository creation time and monitored for drift. Custom properties can be defined at both the [organization](https://docs.github.com/enterprise-cloud@latest/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) and [enterprise](https://docs.github.com/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/managing-custom-properties-for-repositories-in-your-enterprise) levels. Enterprise-level custom properties apply across all organizations, ensuring a consistent metadata schema without per-organization duplication. -Custom properties are most powerful when paired with enterprise-level rulesets. You can target a ruleset to apply only to repositories with a specific property value, for example enforcing signed commits only on repositories tagged `data-classification: restricted`. This decouples policy enforcement from organizational structure: you govern repositories by what they are, not which organization they happen to live in. For detailed guidance on defining a property schema and automating governance workflows around it, see [custom properties best practices]({{< relref "../managing-repositories-at-scale/custom-properties-best-practices.md" >}}) page. +Custom properties are most powerful when paired with enterprise-level rulesets. You can target a ruleset to apply only to repositories with a specific property value, for example enforcing signed commits only on repositories tagged `data-classification: restricted`. This decouples policy enforcement from organizational structure: you govern repositories by what they are, not which organization they happen to live in. For detailed guidance on defining a property schema and automating governance workflows around it, see [custom properties best practices](./managing-repositories-at-scale/custom-properties-best-practices) page. ## Quick checklist @@ -510,9 +511,9 @@ Custom properties are most powerful when paired with enterprise-level rulesets. ## Related guidance -- [Governance policies best practices]({{< relref "../governance-policies-best-practices/index.md" >}}) -- [Repository rulesets best practices]({{< relref "../managing-repositories-at-scale/rulesets-best-practices.md" >}}) -- [Custom properties best practices]({{< relref "../managing-repositories-at-scale/custom-properties-best-practices.md" >}}) +- [Governance policies best practices](./governance-policies-best-practices) +- [Repository rulesets best practices](./managing-repositories-at-scale/rulesets-best-practices) +- [Custom properties best practices](./managing-repositories-at-scale/custom-properties-best-practices) ## Seeking further assistance diff --git a/content/library/governance/recommendations/governance-policies-best-practices/index.md b/content/library/governance/recommendations/governance-policies-best-practices.md similarity index 94% rename from content/library/governance/recommendations/governance-policies-best-practices/index.md rename to content/library/governance/recommendations/governance-policies-best-practices.md index 90ca866..a80b91e 100644 --- a/content/library/governance/recommendations/governance-policies-best-practices/index.md +++ b/content/library/governance/recommendations/governance-policies-best-practices.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false title: 'GitHub Enterprise Policies & Best Practices' +weight: 5 publishDate: 2024-07-29 params: authors: [ @@ -65,13 +66,13 @@ github: Adopting GitHub's general platform best practices is crucial for effectively managing software development projects. These practices provide a structured framework that ensures projects are secure, maintainable, and scalable. By fostering a collaborative and efficient environment, these guidelines help organizations avoid common pitfalls, maintain high-quality codebases, and streamline project workflows. Ultimately, adhering to these best practices leads to successful and sustainable software projects. -For enterprise governance architecture decisions — including structural components, user access models, organization strategies, enterprise policies, billing, repository governance, teams and roles, programmatic access, and audit logs — use the companion guide [Essentials of governance and administration with GitHub Enterprise]({{< relref "../governance-administration-essentials/index.md" >}}). +For enterprise governance architecture decisions — including structural components, user access models, organization strategies, enterprise policies, billing, repository governance, teams and roles, programmatic access, and audit logs — use the companion guide [Essentials of governance and administration with GitHub Enterprise](./governance-administration-essentials). This article remains focused on high-impact policy guardrails. For additional topic-specific guidance, see also: -- [Repository rulesets best practices]({{< relref "../managing-repositories-at-scale/rulesets-best-practices.md" >}}) -- [Custom properties best practices]({{< relref "../managing-repositories-at-scale/custom-properties-best-practices.md" >}}) +- [Repository rulesets best practices](./managing-repositories-at-scale/rulesets-best-practices) +- [Custom properties best practices](./managing-repositories-at-scale/custom-properties-best-practices) ## Key design strategies and checklist @@ -100,20 +101,20 @@ Use these key strategies as a baseline to implement GitHub's best practices for 11. Webhooks should be configured to **use SSL**. 12. Always use **Repository Rulesets** with fine grained policy enforcements around checks needing pull request review, required checks, and leverage protected branches. - ![image1](image1.png) + ![image1](./assets/image1.png) 13. **Define CODEOWNERS**: To protect a repository against unauthorized changes, you also need to define owners using a `CODEOWNERS` file. The most secure method is to define a `CODEOWNERS` file in the `.github` directory of the repository and define the repository owner as the owner of either the `CODEOWNERS` file (`/.github/CODEOWNERS @owner_username`) or the whole directory (`/.github/ @owner_username`). 14. Initiate and impose **commit signing** whenever possible. This will deter malicious actors from creating a commit with malicious code and help prevent a possible supply chain attack. - > **Note:** Copilot cloud agent signs its commits automatically. For broader agent governance guidance, see [Governing agents in GitHub Enterprise]({{< relref "governing-agents.md" >}}) + > **Note:** Copilot cloud agent signs its commits automatically. For broader agent governance guidance, see [Governing agents in GitHub Enterprise](./governing-agents) 15. **Bypass of rulesets should not be allowed** under the Repository Ruleset configuration. Enforcing policies around repo ruleset is designed for a reason and allowing users to bypass rulesets might allow an attacker to gain access as a user who is allowed to bypass ruleset and compromise the integrity of the codebase. 16. **Runner groups should be limited** to a select number of repositories. Configuring a runner group for all repositories can expose vulnerabilities or allow malicious actors to exploit misconfigured runners. Additionally, maintaining runner groups for specific repositories ensures that self-hosted runners are used for their intended specialized workloads. Granting access to everyone in the organization can lead to wasting resources on unnecessary execution tasks. 17. **Bypass Push Protection:** By default, anyone with write access can bypass a commit blockage due to protection. Considering the criticality of leaked secrets, it is recommended to have bypass capability limited to spefic roles and teams. - ![image2](image2.png) + ![image2](./assets/image2.png) 18. **Audit log streaming** is often overlooked by enterprises when implementing GitHub. Streaming audit logs from GitHub is crucial for monitoring platform usage trends. The extensive data captured in these logs provides valuable insights into potential unwanted activities occurring on the platform. diff --git a/content/library/governance/recommendations/governing-agentic-workflows.md b/content/library/governance/recommendations/governing-agentic-workflows.md index b804f2f..7c9da8d 100644 --- a/content/library/governance/recommendations/governing-agentic-workflows.md +++ b/content/library/governance/recommendations/governing-agentic-workflows.md @@ -3,7 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish - +weight: 6 title: 'Governing agentic workflows with gh-aw and APM' publishDate: 2026-06-01 params: diff --git a/content/library/governance/recommendations/governing-agents.md b/content/library/governance/recommendations/governing-agents.md index 67db16c..feb7fee 100644 --- a/content/library/governance/recommendations/governing-agents.md +++ b/content/library/governance/recommendations/governing-agents.md @@ -5,6 +5,7 @@ draft: false # Set to false when ready to publish title: 'Governing agents in GitHub Enterprise' +weight: 4 publishDate: 2026-04-13 params: authors: @@ -179,7 +180,7 @@ For enterprises managing multiple business units, the question is not _whether_ - **GitHub Copilot Business or Enterprise** licenses are assigned. See [comparing Copilot plans](https://docs.github.com/en/copilot/get-started/plans#comparing-copilot-plans) for current feature availability by plan. - **GitHub Actions** is enabled for your enterprise and organizations. The cloud agent runs on Actions runners and consumes Actions minutes. - You have a **SIEM platform** (e.g., Splunk, Microsoft Sentinel, Datadog) capable of ingesting GitHub audit log streams. -- Your enterprise already has [foundational code security practices]({{< relref "/library/application-security/checklist" >}}) in place (CI checks, pull review, secret scanning). Agent governance is an additive layer, not a replacement. +- Your enterprise already has [foundational code security practices](../../application-security/checklist) in place (CI checks, pull review, secret scanning). Agent governance is an additive layer, not a replacement. - This recommendation does **not** cover GitHub Enterprise Server (GHES) deployments — agent capabilities are cloud-only at this time. - The term **custom instructions** as used throughout this article broadly encompasses the full agentic configuration layer — including agent definitions (custom agents) and skill definitions (`SKILL.md`) — unless otherwise specified. @@ -266,7 +267,7 @@ Before deploying a custom agent enterprise-wide, test it in a sandbox repository The [GitHub MCP Registry](https://github.com/mcp) provides a curated list of community MCP servers. For enterprise use, you can layer your own governance: 1. Maintain an internal list of reviewed and approved MCP servers with their endpoints, allowed scopes, and review status. -2. Use [rulesets]({{< relref "rulesets-best-practices.md" >}}) to protect MCP configuration files (`.github/copilot/mcp.json` or `.mcp.json`) in repositories. +2. Use [rulesets](./managing-repositories-at-scale/rulesets-best-practices) to protect MCP configuration files (`.github/copilot/mcp.json` or `.mcp.json`) in repositories. 3. [Configure an MCP registry](https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry) to curate a discoverable set of pre-approved servers. If your policy requires strict control, set the [MCP allowlist policy](https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-server-access) to "Registry only." For enterprises where teams need to experiment, use "Allow all" with rulesets on `.github/copilot/mcp.json` and `.mcp.json` (step 2) so changes require review. Registry enforcement matches on server name, can be bypassed, and [does not apply to the cloud agent](https://docs.github.com/en/copilot/concepts/mcp-management#supported-surfaces) — treat it as a governance signal and discoverability layer for IDEs, not a hard security boundary. Rulesets on `mcp.json` (step 2) are the primary technical control against unauthorized MCP endpoints across all surfaces except for cloud agent. @@ -370,7 +371,7 @@ Copilot agents consume both [GitHub Actions minutes and premium requests](https: - **Actions minutes add up.** Each agent session consumes GitHub Actions minutes for the duration of the agent's work. Monitor Actions usage to ensure agent workloads do not impact your CI/CD capacity. - **Model selection amplifies cost.** Different models have different [request multipliers](https://docs.github.com/en/copilot/concepts/billing/copilot-requests). Factor model choice into your cost governance. -For detailed guidance on budget configuration, cost center allocation, user-level budgets, and cost attribution — see [Managing AI credits with FinOps principles]({{< relref "managing-ai-credits.md" >}}). +For detailed guidance on budget configuration, cost center allocation, user-level budgets, and cost attribution — see [Managing AI credits with FinOps principles](./managing-ai-credits). {{< callout type="info" >}} Cost governance is part of AI governance. Predictable costs keep adoption sustainable. Revisit budgets quarterly as you scale usage or adopt new features. @@ -410,10 +411,10 @@ Review quality depends heavily on custom instructions. Without instructions, rev ### Related articles in this framework -- [GitHub Enterprise Policies & Best Practices]({{< relref "governance-policies-best-practices" >}}) — general platform security hardening checklist (rulesets, CODEOWNERS, commit signing, audit log streaming) -- [Rulesets Best Practices]({{< relref "rulesets-best-practices.md" >}}) — guidance on push vs. branch rulesets, file-path scoping, and CODEOWNERS integration -- [Application Security Checklist]({{< relref "/library/application-security/checklist" >}}) — foundational code security practices (CI checks, pull review, secret scanning) that agent governance builds on -- [Managing AI credits with FinOps principles]({{< relref "managing-ai-credits.md" >}}) — layered budget configuration, user-level budgets, cost attribution, and usage governance +- [GitHub Enterprise Policies & Best Practices](./governance-policies-best-practices) — general platform security hardening checklist (rulesets, CODEOWNERS, commit signing, audit log streaming) +- [Rulesets Best Practices](./managing-repositories-at-scale/rulesets-best-practices) — guidance on push vs. branch rulesets, file-path scoping, and CODEOWNERS integration +- [Application Security Checklist](../../application-security/checklist) — foundational code security practices (CI checks, pull review, secret scanning) that agent governance builds on +- [Managing AI credits with FinOps principles](./managing-ai-credits) — layered budget configuration, user-level budgets, cost attribution, and usage governance ### External resources diff --git a/content/library/governance/recommendations/index.yml b/content/library/governance/recommendations/index.yml new file mode 100644 index 0000000..57eac37 --- /dev/null +++ b/content/library/governance/recommendations/index.yml @@ -0,0 +1,3 @@ +title: Recommendations +slug: recommendations +weight: 5 diff --git a/content/library/governance/recommendations/managing-ai-credits.md b/content/library/governance/recommendations/managing-ai-credits.md index 61c7eee..408c44e 100644 --- a/content/library/governance/recommendations/managing-ai-credits.md +++ b/content/library/governance/recommendations/managing-ai-credits.md @@ -11,7 +11,7 @@ params: [ { name: 'Kitty Chiu', handle: 'kittychiu' }, ] - +weight: 2 # Classifications of the framework to drive key concepts, design principles, and architectural best practices pillars: - governance diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/_index.md b/content/library/governance/recommendations/managing-repositories-at-scale/_index.md index 1c4aff0..ca7a312 100644 --- a/content/library/governance/recommendations/managing-repositories-at-scale/_index.md +++ b/content/library/governance/recommendations/managing-repositories-at-scale/_index.md @@ -2,18 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish -title: 'Managing Repositories at Scale' +title: Overview +linkTitle: Managing Repositories at Scale +weight: 6 --- - -As organizations grow their software development capabilities, managing hundreds or thousands of repositories becomes a significant governance challenge. -Teams need consistent policies, clear ownership models, and automated enforcement mechanisms to maintain security, compliance, and operational efficiency across their entire codebase portfolio. -Without proper governance frameworks, organizations face issues like inconsistent security policies, unclear repository ownership, compliance gaps, and difficulty tracking critical system dependencies. - -Enterprise-scale repository management requires thoughtful approaches to policy enforcement, metadata management, and automated governance. -Modern platforms like GitHub provide powerful tools for implementing scalable governance through repository rulesets and custom properties. -These capabilities enable organizations to apply consistent policies automatically, track repository characteristics for compliance and operational purposes, and maintain visibility across their entire development ecosystem. - -In the following guides, we explore proven strategies for implementing repository governance at scale: - -- [Repository rulesets best practices]({{< relref "rulesets-best-practices.md" >}}) -- [Custom properties best practices]({{< relref "custom-properties-best-practices.md" >}}) diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/custom-properties-best-practices.md b/content/library/governance/recommendations/managing-repositories-at-scale/custom-properties-best-practices.md index 1d73b47..00dc6e9 100644 --- a/content/library/governance/recommendations/managing-repositories-at-scale/custom-properties-best-practices.md +++ b/content/library/governance/recommendations/managing-repositories-at-scale/custom-properties-best-practices.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Custom Properties Best Practices' +weight: 2 publishDate: 2025-09-02 params: authors: [ @@ -174,7 +175,7 @@ business-criticality: "Medium" Connect custom properties to automated policy enforcement through repository rulesets. While rulesets define the "what" of your governance policies, custom properties enable the "when" and "where" - allowing you to apply different governance rules based on repository characteristics rather than manually managing which repositories get which rules. {{< callout type="information" >}} -Read more on working with rulesets in [repository rulesets best practices]({{< relref "rulesets-best-practices.md" >}}). +Read more on working with rulesets in [repository rulesets best practices](./rulesets-best-practices). {{< /callout >}} This integration solves common governance challenges: @@ -305,13 +306,13 @@ Avoid creating too many properties initially. Start with essential properties an {{< /callout >}} ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/index.yml b/content/library/governance/recommendations/managing-repositories-at-scale/index.yml new file mode 100644 index 0000000..23be82d --- /dev/null +++ b/content/library/governance/recommendations/managing-repositories-at-scale/index.yml @@ -0,0 +1,3 @@ +slug: managing-repositories-at-scale +weight: 6 +title: Managing Repositories at Scale diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/overview.md b/content/library/governance/recommendations/managing-repositories-at-scale/overview.md new file mode 100644 index 0000000..b8551d5 --- /dev/null +++ b/content/library/governance/recommendations/managing-repositories-at-scale/overview.md @@ -0,0 +1,22 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +draft: false # Set to false when ready to publish +title: Overview +linkTitle: Managing Repositories at Scale +weight: 1 +--- + + +As organizations grow their software development capabilities, managing hundreds or thousands of repositories becomes a significant governance challenge. +Teams need consistent policies, clear ownership models, and automated enforcement mechanisms to maintain security, compliance, and operational efficiency across their entire codebase portfolio. +Without proper governance frameworks, organizations face issues like inconsistent security policies, unclear repository ownership, compliance gaps, and difficulty tracking critical system dependencies. + +Enterprise-scale repository management requires thoughtful approaches to policy enforcement, metadata management, and automated governance. +Modern platforms like GitHub provide powerful tools for implementing scalable governance through repository rulesets and custom properties. +These capabilities enable organizations to apply consistent policies automatically, track repository characteristics for compliance and operational purposes, and maintain visibility across their entire development ecosystem. + +In the following guides, we explore proven strategies for implementing repository governance at scale: + +- [Repository rulesets best practices](./rulesets-best-practices) +- [Custom properties best practices](./custom-properties-best-practices) diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/rulesets-best-practices.md b/content/library/governance/recommendations/managing-repositories-at-scale/rulesets-best-practices.md index 2c9d307..99a88d5 100644 --- a/content/library/governance/recommendations/managing-repositories-at-scale/rulesets-best-practices.md +++ b/content/library/governance/recommendations/managing-repositories-at-scale/rulesets-best-practices.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Rulesets Best Practices' +weight: 3 publishDate: 2024-10-08 params: authors: @@ -150,7 +151,7 @@ Enterprises need consistent, enforceable guardrails for how code enters, evolves ### 1. Custom properties strategy {{< callout type="information" >}} -Read more on working with custom properties in [custom properties best practices]({{< relref "custom-properties-best-practices.md" >}}). +Read more on working with custom properties in [custom properties best practices](./custom-properties-best-practices). {{< /callout >}} Define a schema that makes sense for your organization. For example: @@ -254,13 +255,13 @@ Avoid enabling too many restrictive rules simultaneously; stage them and monitor ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/governance/recommendations/managing-repositories-at-scale/schema.json b/content/library/governance/recommendations/managing-repositories-at-scale/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/governance/recommendations/managing-repositories-at-scale/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/governance/recommendations/overview.md b/content/library/governance/recommendations/overview.md new file mode 100644 index 0000000..8364593 --- /dev/null +++ b/content/library/governance/recommendations/overview.md @@ -0,0 +1,13 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the 📜 **Governance** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. + +Articles in this section include: + +{{< child-pages >}} diff --git a/content/library/governance/recommendations/schema.json b/content/library/governance/recommendations/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/governance/recommendations/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/governance/schema.json b/content/library/governance/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/governance/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/index.yml b/content/library/index.yml new file mode 100644 index 0000000..ac9e9ba --- /dev/null +++ b/content/library/index.yml @@ -0,0 +1,2 @@ +title: Content Library +slug: library diff --git a/content/library/overview/_index.md b/content/library/overview/_index.md index 123fd89..fe9bb70 100644 --- a/content/library/overview/_index.md +++ b/content/library/overview/_index.md @@ -5,110 +5,3 @@ title: Overview weight: 1 next: library/overview/layers --- - -This Content Library serves as a key resource as part of the GitHub Well-Architected program. -It provides a comprehensive guide for organizations to understand, implement, and optimize their use of GitHub in a way that enhances their software development lifecycle (SDLC). -It is designed to help teams create secure, high-performing, resilient, and efficient infrastructure for their applications. Through a combination of best practices, detailed strategies, and insights, the framework aims to foster a culture of excellence in software development and collaboration. - -{{< cards >}} - {{< card link="layers" title="Layers of GitHub Well-Architected" icon="sparkles" >}} - {{< card link="about-the-assessment" title="About the Assessment" icon="sparkles" >}} - {{< card link="getting-started-checklist" title="Getting Started Checklist" icon="sparkles" >}} - {{< card link="/library/scenarios/anti-patterns" title="Anti-patterns" icon="sparkles" >}} - {{< card link="release-notes" title="Release Notes" icon="sparkles" >}} -{{< /cards >}} - -Overall, the GitHub Well-Architected program enhances the quality of software development and collaboration by helping it to: - -- Enhance team collaboration and project management, making workflows more efficient and productive. -- Integrate security practices throughout the software development lifecycle, ensuring code and data are protected. -- Foster innovation by encouraging experimentation, learning from failures, and quick iteration. -- Optimize performance of both development practices and the applications being built, ensuring they are scalable, resilient, and efficient. -- Govern access, compliance, and architecture within GitHub projects, ensuring a secure and compliant development environment. -- Leverage GitHub Copilot to boost developer productivity through AI-powered code suggestions, reducing the time spent on boilerplate code and focusing more on creative problem-solving. -- Improve the Developer Experience by providing tools and practices that make the development process more enjoyable and efficient, leading to higher quality software and more satisfied teams. - -It is founded on the five pillars of GitHub architectural excellence, which are mapped to those goals: **Productivity**, **Collaboration**, **Application Security**, **Governance**, and **Architecture**. - -## Disclaimer - -Each pillar provides recommended practices, risk considerations, and tradeoffs. The design decisions must be balanced across all pillars, given the business requirements. The technical and actionable guidance is broad enough for all developer workloads and articles often apply to specific scenarios. This guidance is centered on the GitHub Platform and its contributors include GitHub and its Partners. - -## Audience - -This framework is intended for: - -- **Developers and Operations Teams:** To streamline development workflows and operational practices. -- **Security Professionals:** To ensure that security is integrated into the development process from the start. -- **Architects and Technical Leaders:** To design and implement efficient, scalable GitHub strategies that align with organizational goals. -- **Project Managers and Decision Makers:** To understand the impact of GitHub practices on project outcomes and team productivity. - -## Objectives - -The primary objectives of the GitHub Well-Architected program are to: - -- **Partner inclusion in development:** Create technical cohesiveness and a GitHub/Partner communication channel -- **Closing feedback loop from the field:** Articulate decision making trade-offs based on lessons learned with added insights -- **Improve skills, abilities, and confidence:** Reference architectures around developer workloads and GitHub Platform implementation -- **Engagement leads:** Drive customer success with personal engagement from GitHub and Partners - -## The purpose of this Content Library - -It is a living, flexible guide based on a static content library designed to help organizations effectively adopt and deploy GitHub as part of the GitHub Well-Architected program. -It provides a structured approach to understanding, implementing, and optimizing the use of GitHub within your organization. - -Implementation and configuration of the GitHub platform and all tools in the SDLC should be supplemented with design thinking. -Implementation and configuration is covered by our GitHub public documentation and other existing resources, while this Content Library covers the design thinking around the decisions that need to be made beyond simply turning on products and features. -That design thinking depth can only be achieved with this program and engagements with experts, including GitHub Services Offerings and Partner engagements. - -GitHub Well-Architected is a framework is built around five key pillars: - -{{< cards >}} - {{< card link="/library/productivity" title="Productivity" icon="book-open" >}} - {{< card link="/library/collaboration" title="Collaboration" icon="book-open" >}} - {{< card link="/library/application-security" title="Application Security" icon="book-open" >}} - {{< card link="/library/governance" title="Governance" icon="book-open" >}} - {{< card link="/library/architecture" title="Architecture" icon="book-open" >}} -{{< /cards >}} - -## What are Pillars and Design Principles? - -In summary, **design principles** provide the "how" for each **pillar's** "what". -They work together to provide a comprehensive guide for adopting and deploying GitHub effectively. -The relationship between the design principles and the framework pillars is that each pillar is guided by a set of related design principles. -These principles provide the specific strategies and best practices for achieving the goals of each pillar. - -- **Pillars** are the key areas of focus or the main components that the framework aims to address. - - Each pillar is defined by a specific business outcome that is achieved by following the prescriptions of the pillar. - - To achieve these outcomes, each pillar focuses on a set of principles that guide the deployment of GitHub. - - These principles represent the broad categories of best practices and design principles. -- **Design principles** are the fundamental concepts that guide the development of the framework. - - They are the core ideas that should be considered when deploying the GitHub platform. - - There can be many design principles that include concepts supporting the framework pillars. - -Each pillar represents a critical aspect of GitHub usage and is guided by their set of design principles. -These principles provide the strategies and best practices for achieving the goals of each pillar. -For example, the **Productivity** pillar might be guided by design principles such as "Automate repetitive tasks" and "Integrate CI/CD pipelines". -These principles provide concrete strategies for achieving increased productivity with GitHub. - -## A flexible guide - -This Content Library is not a one-size-fits-all solution, nor does it replace GitHub's official documentation, but rather it serves as a flexible guide that can be adapted to meet the unique needs and circumstances of each organization. -It is designed to be iterative, allowing organizations to continually refine and improve their GitHub usage over time. - -The pillars of the framework, coupled with each of their design principles, are intended to help you delve responsibly deep into the technical design of the GitHub Platform, and to help you continuously evaluate your readiness for production. - -Not only is the framework designed to help you understand key concepts, design principles, and architectural best practices for building on GitHub, it provides a consistent approach for customers and partners to evaluate and implement designs that scale with your needs over time. To accomplish this, the principles help you understand the trade-offs in decision making and guide you toward best practices. - -Finally, we have Services, Support, and Partners ready to assist you at every step in your journey - -*** - -## Related Links - -- [GitHub Docs](https://docs.github.com/) -- [GitHub Skills](https://skills.github.com/) -- [GitHub Security Features](https://github.com/features/security) -- [GitHub Enterprise](https://github.com/enterprise) - -This framework is a living document, designed to evolve with advancements in technology, changes in best practices, and the feedback from the community. It serves as a flexible guide, supplementing GitHub's official documentation, and can be adapted to meet the unique needs of each organization. diff --git a/content/library/overview/about-the-assessment.md b/content/library/overview/about-the-assessment.md index 6be90e6..fb34e28 100644 --- a/content/library/overview/about-the-assessment.md +++ b/content/library/overview/about-the-assessment.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: About the Assessment -weight: 2 +weight: 3 prev: library/overview/layers next: library/overview/getting-started-checklist --- diff --git a/content/library/overview/getting-started-checklist.md b/content/library/overview/getting-started-checklist.md index 90c461f..e10acfc 100644 --- a/content/library/overview/getting-started-checklist.md +++ b/content/library/overview/getting-started-checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Getting Started Checklist -weight: 3 +weight: 4 prev: library/overview/about-the-assessment next: library/overview/release-notes --- @@ -23,9 +23,9 @@ This checklist serves as a high-level guide for conducting a GitHub Well-Archite Once you are familiar with the Getting Started checklist above, it is time to drill down on the checklists for each pillar: {{< cards >}} -{{< card link="/library/productivity/checklist" title="⚙️ Productivity Checklist" >}} -{{< card link="/library/collaboration/checklist" title="👥 Collaboration Checklist" >}} -{{< card link="/library/application-security/checklist" title="🔒 Application Security Checklist" >}} -{{< card link="/library/governance/checklist" title="📜 Governance Checklist" >}} -{{< card link="/library/architecture/checklist" title="📐 Architecture Checklist" >}} +{{< card link="../productivity/checklist" title="Productivity Checklist" >}} +{{< card link="../collaboration/checklist" title="Collaboration Checklist" >}} +{{< card link="../application-security/checklist" title="Application Security Checklist" >}} +{{< card link="../governance/checklist" title="Governance Checklist" >}} +{{< card link="../architecture/checklist" title="Architecture Checklist" >}} {{< /cards >}} diff --git a/content/library/overview/index.yml b/content/library/overview/index.yml new file mode 100644 index 0000000..21ee74e --- /dev/null +++ b/content/library/overview/index.yml @@ -0,0 +1,4 @@ +title: Overview +weight: 1 +slug: overview +icon: BookIcon diff --git a/content/library/overview/layers.md b/content/library/overview/layers.md index 6e45d21..c54d9e4 100644 --- a/content/library/overview/layers.md +++ b/content/library/overview/layers.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Layers of GitHub Well-Architected -weight: 1 +weight: 2 prev: library/overview next: library/overview/about-the-assessment --- diff --git a/content/library/overview/overview.md b/content/library/overview/overview.md new file mode 100644 index 0000000..c440929 --- /dev/null +++ b/content/library/overview/overview.md @@ -0,0 +1,115 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +next: library/overview/layers +--- + + +This Content Library serves as a key resource as part of the GitHub Well-Architected program. +It provides a comprehensive guide for organizations to understand, implement, and optimize their use of GitHub in a way that enhances their software development lifecycle (SDLC). +It is designed to help teams create secure, high-performing, resilient, and efficient infrastructure for their applications. Through a combination of best practices, detailed strategies, and insights, the framework aims to foster a culture of excellence in software development and collaboration. + +{{< cards >}} + {{< card link="./layers" title="Layers of GitHub Well-Architected" icon="sparkles" >}} + {{< card link="./about-the-assessment" title="About the Assessment" icon="sparkles" >}} + {{< card link="./getting-started-checklist" title="Getting Started Checklist" icon="sparkles" >}} + {{< card link="../scenarios/anti-patterns" title="Anti-patterns" icon="sparkles" >}} + {{< card link="./release-notes" title="Release Notes" icon="sparkles" >}} +{{< /cards >}} + +Overall, the GitHub Well-Architected program enhances the quality of software development and collaboration by helping it to: + +- Enhance team collaboration and project management, making workflows more efficient and productive. +- Integrate security practices throughout the software development lifecycle, ensuring code and data are protected. +- Foster innovation by encouraging experimentation, learning from failures, and quick iteration. +- Optimize performance of both development practices and the applications being built, ensuring they are scalable, resilient, and efficient. +- Govern access, compliance, and architecture within GitHub projects, ensuring a secure and compliant development environment. +- Leverage GitHub Copilot to boost developer productivity through AI-powered code suggestions, reducing the time spent on boilerplate code and focusing more on creative problem-solving. +- Improve the Developer Experience by providing tools and practices that make the development process more enjoyable and efficient, leading to higher quality software and more satisfied teams. + +It is founded on the five pillars of GitHub architectural excellence, which are mapped to those goals: **Productivity**, **Collaboration**, **Application Security**, **Governance**, and **Architecture**. + +## Disclaimer + +Each pillar provides recommended practices, risk considerations, and tradeoffs. The design decisions must be balanced across all pillars, given the business requirements. The technical and actionable guidance is broad enough for all developer workloads and articles often apply to specific scenarios. This guidance is centered on the GitHub Platform and its contributors include GitHub and its Partners. + +## Audience + +This framework is intended for: + +- **Developers and Operations Teams:** To streamline development workflows and operational practices. +- **Security Professionals:** To ensure that security is integrated into the development process from the start. +- **Architects and Technical Leaders:** To design and implement efficient, scalable GitHub strategies that align with organizational goals. +- **Project Managers and Decision Makers:** To understand the impact of GitHub practices on project outcomes and team productivity. + +## Objectives + +The primary objectives of the GitHub Well-Architected program are to: + +- **Partner inclusion in development:** Create technical cohesiveness and a GitHub/Partner communication channel +- **Closing feedback loop from the field:** Articulate decision making trade-offs based on lessons learned with added insights +- **Improve skills, abilities, and confidence:** Reference architectures around developer workloads and GitHub Platform implementation +- **Engagement leads:** Drive customer success with personal engagement from GitHub and Partners + +## The purpose of this Content Library + +It is a living, flexible guide based on a static content library designed to help organizations effectively adopt and deploy GitHub as part of the GitHub Well-Architected program. +It provides a structured approach to understanding, implementing, and optimizing the use of GitHub within your organization. + +Implementation and configuration of the GitHub platform and all tools in the SDLC should be supplemented with design thinking. +Implementation and configuration is covered by our GitHub public documentation and other existing resources, while this Content Library covers the design thinking around the decisions that need to be made beyond simply turning on products and features. +That design thinking depth can only be achieved with this program and engagements with experts, including GitHub Services Offerings and Partner engagements. + +GitHub Well-Architected is a framework is built around five key pillars: + +{{< cards >}} + {{< card link="../productivity" title="Productivity" icon="book-open" >}} + {{< card link="../collaboration" title="Collaboration" icon="book-open" >}} + {{< card link="../application-security" title="Application Security" icon="book-open" >}} + {{< card link="../governance" title="Governance" icon="book-open" >}} + {{< card link="../architecture" title="Architecture" icon="book-open" >}} +{{< /cards >}} + +## What are Pillars and Design Principles? + +In summary, **design principles** provide the "how" for each **pillar's** "what". +They work together to provide a comprehensive guide for adopting and deploying GitHub effectively. +The relationship between the design principles and the framework pillars is that each pillar is guided by a set of related design principles. +These principles provide the specific strategies and best practices for achieving the goals of each pillar. + +- **Pillars** are the key areas of focus or the main components that the framework aims to address. + - Each pillar is defined by a specific business outcome that is achieved by following the prescriptions of the pillar. + - To achieve these outcomes, each pillar focuses on a set of principles that guide the deployment of GitHub. + - These principles represent the broad categories of best practices and design principles. +- **Design principles** are the fundamental concepts that guide the development of the framework. + - They are the core ideas that should be considered when deploying the GitHub platform. + - There can be many design principles that include concepts supporting the framework pillars. + +Each pillar represents a critical aspect of GitHub usage and is guided by their set of design principles. +These principles provide the strategies and best practices for achieving the goals of each pillar. +For example, the **Productivity** pillar might be guided by design principles such as "Automate repetitive tasks" and "Integrate CI/CD pipelines". +These principles provide concrete strategies for achieving increased productivity with GitHub. + +## A flexible guide + +This Content Library is not a one-size-fits-all solution, nor does it replace GitHub's official documentation, but rather it serves as a flexible guide that can be adapted to meet the unique needs and circumstances of each organization. +It is designed to be iterative, allowing organizations to continually refine and improve their GitHub usage over time. + +The pillars of the framework, coupled with each of their design principles, are intended to help you delve responsibly deep into the technical design of the GitHub Platform, and to help you continuously evaluate your readiness for production. + +Not only is the framework designed to help you understand key concepts, design principles, and architectural best practices for building on GitHub, it provides a consistent approach for customers and partners to evaluate and implement designs that scale with your needs over time. To accomplish this, the principles help you understand the trade-offs in decision making and guide you toward best practices. + +Finally, we have Services, Support, and Partners ready to assist you at every step in your journey + +*** + +## Related Links + +- [GitHub Docs](https://docs.github.com/) +- [GitHub Skills](https://skills.github.com/) +- [GitHub Security Features](https://github.com/features/security) +- [GitHub Enterprise](https://github.com/enterprise) + +This framework is a living document, designed to evolve with advancements in technology, changes in best practices, and the feedback from the community. It serves as a flexible guide, supplementing GitHub's official documentation, and can be adapted to meet the unique needs of each organization. diff --git a/content/library/overview/release-notes/2025-q1.md b/content/library/overview/release-notes/2025-q1.md index 9d2ec58..15ce908 100644 --- a/content/library/overview/release-notes/2025-q1.md +++ b/content/library/overview/release-notes/2025-q1.md @@ -2,8 +2,8 @@ ## 2025 Q1 -- **New Content: [GitHub Actions Scalability](/library/collaboration/recommendations/scaling-actions-reusability/)** - Published guidance for scaling GitHub Actions reusability in enterprise environments, including best practices for workflow optimization, action management, and enterprise-wide deployment -- **New Content: [Repository Migration Essentials](/library/scenarios/migrations/repository-checklist/)** - Introduced a generalized repository migration checklist covering pre-planning, testing, execution, and post-migration, designed to serve as a single source of truth across migration approaches +- **New Content: [GitHub Actions Scalability](../collaboration/recommendations/scaling-actions-reusability)** - Published guidance for scaling GitHub Actions reusability in enterprise environments, including best practices for workflow optimization, action management, and enterprise-wide deployment +- **New Content: [Repository Migration Essentials](../scenarios/migrations/repository-checklist)** - Introduced a generalized repository migration checklist covering pre-planning, testing, execution, and post-migration, designed to serve as a single source of truth across migration approaches - **Design Principle Updates** - Expanded real-world examples across pillars, including clearer guidance on pull request best practices, early vulnerability scanning, and multi-region deployment considerations - **Checklists 2.0** - Overhauled the assessment checklists to align with recent GitHub product updates and introduced tiers to help teams prioritize actions based on maturity - **Fixes & Refinements** - Improved clarity and usability with refinements to pillar content, navigation, homepage layout, and the hosting template for simpler ongoing maintenance diff --git a/content/library/overview/release-notes/2025-q2.md b/content/library/overview/release-notes/2025-q2.md index e14386e..f034999 100644 --- a/content/library/overview/release-notes/2025-q2.md +++ b/content/library/overview/release-notes/2025-q2.md @@ -2,6 +2,6 @@ ## 2025 Q2 -- **New Content: [Azure DevOps Migration Guide](/library/scenarios/migrations/azure-devops-migration-guide/)** - Published migration scenarios and playbooks for transitioning from Azure DevOps to GitHub, including phased approaches, feature comparisons, and practical guidance for translating Azure DevOps settings to GitHub equivalents -- **New Content: [Engineering System Success Framework](/library/productivity/recommendations/engineering-system-metrics/)** - Published the Engineering System Success Framework to help organizations evaluate Copilot business value, including design principles, checklists, metrics, implementation phases, anti-patterns, and intervention strategies +- **New Content: [Azure DevOps Migration Guide](../scenarios/migrations/azure-devops-migration-guide)** - Published migration scenarios and playbooks for transitioning from Azure DevOps to GitHub, including phased approaches, feature comparisons, and practical guidance for translating Azure DevOps settings to GitHub equivalents +- **New Content: [Engineering System Success Framework](../productivity/recommendations/engineering-system-metrics)** - Published the Engineering System Success Framework to help organizations evaluate Copilot business value, including design principles, checklists, metrics, implementation phases, anti-patterns, and intervention strategies - **Site Improvements** - Introduced a new Copilot Chat Widget that provides interactive assistance for users diff --git a/content/library/overview/release-notes/2025-q3.md b/content/library/overview/release-notes/2025-q3.md index 9664ce6..34452aa 100644 --- a/content/library/overview/release-notes/2025-q3.md +++ b/content/library/overview/release-notes/2025-q3.md @@ -2,8 +2,8 @@ ## 2025 Q3 -- **Update: [Repository Management Enhancement](/library/governance/recommendations/managing-repositories-at-scale/)** - Updated the "Managing repositories at scale" article with opinionated guidance on adopting rulesets and custom properties to meet business objectives, including actionable strategies for governance at scale -- **Update: [GitHub Actions Policy Updates](/library/application-security/recommendations/actions-security/)** - Updated the GitHub Actions recommendations with new policy capabilities and more prescriptive governance and security guidance for managing workflows at scale +- **Update: [Repository Management Enhancement](../governance/recommendations/managing-repositories-at-scale)** - Updated the "Managing repositories at scale" article with opinionated guidance on adopting rulesets and custom properties to meet business objectives, including actionable strategies for governance at scale +- **Update: [GitHub Actions Policy Updates](../application-security/recommendations/actions-security)** - Updated the GitHub Actions recommendations with new policy capabilities and more prescriptive governance and security guidance for managing workflows at scale - **New Content: GitHub PRU Enterprise Admin Playbook** - Published an enterprise playbook for managing GitHub Copilot Premium Request Units (PRUs), including budget configuration, KPI targets, monitoring, and cost control strategies. UPDATED: Deprecated on May 2026. -- **New Content: [Security Alert Management](/library/application-security/recommendations/prioritizing-alerts/)** - Published a scenario for prioritizing security alert remediation using GitHub's built-in metadata and organizational context, including practical guidance on implementing GitHub's security campaigns and vulnerability triage workflows -- **New Content: [Champion Program](/library/collaboration/recommendations/champion-program/)** - Published a recommendation for champion programs that empower engaged employees to guide peers through AI-driven change. +- **New Content: [Security Alert Management](../application-security/recommendations/prioritizing-alerts)** - Published a scenario for prioritizing security alert remediation using GitHub's built-in metadata and organizational context, including practical guidance on implementing GitHub's security campaigns and vulnerability triage workflows +- **New Content: [Champion Program](../collaboration/recommendations/champion-program)** - Published a recommendation for champion programs that empower engaged employees to guide peers through AI-driven change. diff --git a/content/library/overview/release-notes/2025-q4.md b/content/library/overview/release-notes/2025-q4.md index e84eee2..86fb3ac 100644 --- a/content/library/overview/release-notes/2025-q4.md +++ b/content/library/overview/release-notes/2025-q4.md @@ -2,6 +2,6 @@ ## 2025 Q4 -- **New Content: [Actions Runner Controller (ARC) best practices](/library/architecture/recommendations/deploying-actions-runner-controller/)** - Published an opinionated guidance for operating ARC on Kubernetes, including recommendations for runner images, configuration, observability, and security trade-offs -- **New Content: [Securing developer workspace](/library/application-security/recommendations/securing-developer-workspace/)** - Published an design guidance for hardening developer workspaces, including identity and authorization, workspace isolation, and signed commit practices -- **Update: [Securing GitHub Actions workflows](/library/application-security/recommendations/actions-security/)** - Added opinionated guidance for OIDC, repository rulesets, and safer workflow patterns, with specific recommendations for public repository security +- **New Content: [Actions Runner Controller (ARC) best practices](../architecture/recommendations/deploying-actions-runner-controller)** - Published an opinionated guidance for operating ARC on Kubernetes, including recommendations for runner images, configuration, observability, and security trade-offs +- **New Content: [Securing developer workspace](../application-security/recommendations/securing-developer-workspace)** - Published an design guidance for hardening developer workspaces, including identity and authorization, workspace isolation, and signed commit practices +- **Update: [Securing GitHub Actions workflows](../application-security/recommendations/actions-security)** - Added opinionated guidance for OIDC, repository rulesets, and safer workflow patterns, with specific recommendations for public repository security diff --git a/content/library/overview/release-notes/2026-q1.md b/content/library/overview/release-notes/2026-q1.md index ca866c2..8e3a70d 100644 --- a/content/library/overview/release-notes/2026-q1.md +++ b/content/library/overview/release-notes/2026-q1.md @@ -2,10 +2,10 @@ ## 2026 Q1 -- **New Content: [Managing dependency threats](/library/application-security/recommendations/managing-dependency-threats/)** - Published a comprehensive guide for defending against supply chain attacks and managing dependency risks, covering layered defenses from lockfiles and dependency review to attestation verification and package confusion mitigation -- **New Content: [Expanding Enterprise Custom Agents context](/library/architecture/recommendations/expanding-enterprise-custom-agents-context/)** - Published architecture guidance for extending GitHub Copilot custom agents with enterprise knowledge, including strategies for context enrichment, secure integration patterns, and scaling agent capabilities across the organization -- **New Content: [Implementing polyrepo engineering](/library/architecture/recommendations/implementing-polyrepo-engineering/)** - Published a design guide for coordinating engineering across multiple repositories, including manifest-driven integration, change set management, reusable workflow versioning, and release governance patterns -- **Update: [NIST SSDF implementation](/library/scenarios/nist-ssdf-implementation/)** - Expanded the NIST Secure Software Development Framework scenario with updated guidance on security configurations, repository rulesets, and practical implementation steps across all SSDF practice areas -- **Update: [Securing GitHub Actions workflows](/library/application-security/recommendations/actions-security/)** - Enhanced the Actions security recommendation with detailed OIDC claims guidance, immutable subject identifiers, repository ruleset examples, and refined best practices for secure workflow patterns -- **Update: [Application Security design principles](/library/application-security/design-principles/)** - Added a security-by-design approach and developer workspace security considerations to the Application Security pillar's design principles -- **Update: [Anti-patterns](/library/scenarios/anti-patterns/)** - Added guidance on avoiding PII detection with secret scanning custom patterns, highlighting why repurposing secret scanning for personally identifiable information creates compliance risk and alert fatigue +- **New Content: [Managing dependency threats](../application-security/recommendations/managing-dependency-threats)** - Published a comprehensive guide for defending against supply chain attacks and managing dependency risks, covering layered defenses from lockfiles and dependency review to attestation verification and package confusion mitigation +- **New Content: [Expanding Enterprise Custom Agents context](../architecture/recommendations/expanding-enterprise-custom-agents-context)** - Published architecture guidance for extending GitHub Copilot custom agents with enterprise knowledge, including strategies for context enrichment, secure integration patterns, and scaling agent capabilities across the organization +- **New Content: [Implementing polyrepo engineering](../architecture/recommendations/implementing-polyrepo-engineering)** - Published a design guide for coordinating engineering across multiple repositories, including manifest-driven integration, change set management, reusable workflow versioning, and release governance patterns +- **Update: [NIST SSDF implementation](../scenarios/nist-ssdf-implementation)** - Expanded the NIST Secure Software Development Framework scenario with updated guidance on security configurations, repository rulesets, and practical implementation steps across all SSDF practice areas +- **Update: [Securing GitHub Actions workflows](../application-security/recommendations/actions-security)** - Enhanced the Actions security recommendation with detailed OIDC claims guidance, immutable subject identifiers, repository ruleset examples, and refined best practices for secure workflow patterns +- **Update: [Application Security design principles](../application-security/design-principles)** - Added a security-by-design approach and developer workspace security considerations to the Application Security pillar's design principles +- **Update: [Anti-patterns](../scenarios/anti-patterns)** - Added guidance on avoiding PII detection with secret scanning custom patterns, highlighting why repurposing secret scanning for personally identifiable information creates compliance risk and alert fatigue diff --git a/content/library/overview/release-notes/index.md b/content/library/overview/release-notes/index.md index 5e7864e..07c1226 100644 --- a/content/library/overview/release-notes/index.md +++ b/content/library/overview/release-notes/index.md @@ -2,15 +2,21 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Release notes -weight: 4 +weight: 5 prev: library/overview/getting-started-checklist next: library/scenarios --- Find general updates here on new content, feature enhancements, and improvements that help teams architect and optimize deployments of the tools that support their development communities. -{{% quarterly-updates %}} - +2026-q2.md +2026-q1.md +2025-q4.md +2025-q3.md +2025-q2.md +2025-q1.md +2024-q4.md + ## Future Plans & Roadmap - **Partner & Ecosystem Growth**: Ongoing partner showcases, workshops, and contributions will introduce new specialized assessment offerings diff --git a/content/library/overview/release-notes/schema.json b/content/library/overview/release-notes/schema.json new file mode 100644 index 0000000..e57e2e4 --- /dev/null +++ b/content/library/overview/release-notes/schema.json @@ -0,0 +1,36 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "additionalProperties": true +} diff --git a/content/library/overview/schema.json b/content/library/overview/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/overview/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/productivity/_index.md b/content/library/productivity/_index.md index 0109b16..e48b03c 100644 --- a/content/library/productivity/_index.md +++ b/content/library/productivity/_index.md @@ -1,16 +1,6 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: ⚙️ Productivity +title: Overview weight: 3 -slug: productivity --- - -The **Productivity** pillar focuses on how to increase the speed and efficiency of development workflows. It could include principles such as automation, continuous integration/continuous deployment (CI/CD), and the use of GitHub features like Actions and Packages. - -{{< cards >}} - {{< card link="quick-links" title="Quick Links" icon="sparkles" >}} - {{< card link="design-principles" title="Design Principles" icon="book-open" >}} - {{< card link="checklist" title="Assessment Checklist" icon="book-open" >}} - {{< card link="recommendations" title="Recommendations" icon="book-open" >}} -{{< /cards >}} diff --git a/content/library/productivity/checklist.md b/content/library/productivity/checklist.md index 8ab82f7..be0dd02 100644 --- a/content/library/productivity/checklist.md +++ b/content/library/productivity/checklist.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Productivity -weight: 3 +weight: 4 prev: library/productivity/design-principles next: library/productivity/recommendations --- @@ -125,7 +125,7 @@ This assessment checklist focuses on evaluating and enhancing the **Productivity - Map engineering efforts to organizational priorities. - **Map and Prioritize Findings** - - Categorize barriers by the [four engineering system success zones](../recommendations/engineering-system-metrics). + - Categorize barriers by the [four engineering system success zones](./recommendations/engineering-system-metrics). - Map barriers' interconnections between zones and capability areas. - Prioritize barriers based on impact and organizational alignment. - Select metrics to track progress. @@ -136,7 +136,7 @@ This assessment checklist focuses on evaluating and enhancing the **Productivity - Pilot and evaluate solutions before full-scale implementation. - **Establish Balanced Metrics** - - Define leading and lagging indicators for all [four engineering system success zones](../recommendations/engineering-system-metrics). + - Define leading and lagging indicators for all [four engineering system success zones](./recommendations/engineering-system-metrics). - Track metrics across all zones in a balanced way. - Review metrics periodically to identify emerging trends. diff --git a/content/library/productivity/design-principles.md b/content/library/productivity/design-principles.md index af141d6..419933b 100644 --- a/content/library/productivity/design-principles.md +++ b/content/library/productivity/design-principles.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Design Principles -weight: 2 +weight: 3 prev: library/productivity/quick-links next: library/productivity/checklist --- diff --git a/content/library/productivity/index.yml b/content/library/productivity/index.yml new file mode 100644 index 0000000..2e581cc --- /dev/null +++ b/content/library/productivity/index.yml @@ -0,0 +1,5 @@ +title: Productivity +description: Proven strategies and tools to streamline workflows, automate processes, and accelerate team velocity. +weight: 3 +slug: productivity +icon: ZapIcon diff --git a/content/library/productivity/overview.md b/content/library/productivity/overview.md new file mode 100644 index 0000000..9ebb9ba --- /dev/null +++ b/content/library/productivity/overview.md @@ -0,0 +1,16 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +The **Productivity** pillar focuses on how to increase the speed and efficiency of development workflows. It could include principles such as automation, continuous integration/continuous deployment (CI/CD), and the use of GitHub features like Actions and Packages. + +{{< cards >}} + {{< card link="./quick-links" title="Quick Links" icon="sparkles" >}} + {{< card link="./design-principles" title="Design Principles" icon="book-open" >}} + {{< card link="./checklist" title="Assessment Checklist" icon="book-open" >}} + {{< card link="./recommendations/overview" title="Recommendations" icon="book-open" >}} +{{< /cards >}} diff --git a/content/library/productivity/quick-links.md b/content/library/productivity/quick-links.md index 16e512c..7b883ca 100644 --- a/content/library/productivity/quick-links.md +++ b/content/library/productivity/quick-links.md @@ -2,8 +2,8 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Quick Links -weight: 1 -prev: library/productivity +weight: 2 +prev: library/productivity/introduction next: library/productivity/design-principles --- diff --git a/content/library/productivity/recommendations/_index.md b/content/library/productivity/recommendations/_index.md index a715949..fae5954 100644 --- a/content/library/productivity/recommendations/_index.md +++ b/content/library/productivity/recommendations/_index.md @@ -1,13 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Recommendations +title: Overview +linkTitle: Recommendations weight: 5 -prev: library/productivity --- - -This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the ⚙️ **Productivity** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. - -Articles in this section include: - -{{< child-pages >}} diff --git a/content/library/productivity/recommendations/adopting-copilot-at-scale/index.md b/content/library/productivity/recommendations/adopting-copilot-at-scale.md similarity index 97% rename from content/library/productivity/recommendations/adopting-copilot-at-scale/index.md rename to content/library/productivity/recommendations/adopting-copilot-at-scale.md index 5ad42b2..bcb397f 100644 --- a/content/library/productivity/recommendations/adopting-copilot-at-scale/index.md +++ b/content/library/productivity/recommendations/adopting-copilot-at-scale.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Adopting GitHub Copilot at Scale' +weight: 3 publishDate: 2024-07-22 params: authors: [ @@ -166,7 +167,7 @@ Be sure to include other helpful resources for your GitHub Copilot community, su At its core, GitHub Copilot saves users time while coding. In order for GitHub Copilot to drive downstream impacts, the time saved needs to be spent towards a business objective (e.g. improving velocity, improving quality, learning & development, etc.). -See the article [Measuring Impact for GenAI Adoption](../../../scenarios/measuring-genai-impact) for a detailed, tiered approach to measuring Copilot's impact. +See the article [Measuring Impact for GenAI Adoption](../../scenarios/measuring-genai-impact) for a detailed, tiered approach to measuring Copilot's impact. ### Continuously gather feedback and improve your GitHub Copilot program @@ -204,13 +205,13 @@ While automation can help manage costs associated with stale GitHub Copilot lice To avoid this, consider implementing a process that notifies users before their license is revoked, giving them time to renew it. ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/productivity/recommendations/engineering-system-metrics.md b/content/library/productivity/recommendations/engineering-system-metrics.md index 38d7f17..56e6c54 100644 --- a/content/library/productivity/recommendations/engineering-system-metrics.md +++ b/content/library/productivity/recommendations/engineering-system-metrics.md @@ -3,6 +3,7 @@ # SPDX-License-Identifier: MIT draft: false # Set to false when ready to publish title: 'Engineering System Metrics' +weight: 2 publishDate: 2025-04-24 params: # Add and remove authors as needed. Please reserve authorship for significant contributions, not edits and feedback. @@ -66,14 +67,9 @@ github: ## Recommendation overview -How well your DevSecOps system performs goes beyond merely measuring the outputs of individual developers -(e.g. lines of code) and systems (e.g. number of workflow runs). You need to seek clarity on your system's -leading and lagging indicators, so that your working focus is on the leading indicators that provide -early signals and enable steering of the downstream impacts. +How well your DevSecOps system performs goes beyond merely measuring the outputs of individual developers (e.g. lines of code) and systems (e.g. number of workflow runs). You need to seek clarity on your system's leading and lagging indicators, so that your working focus is on the leading indicators that provide early signals and enable steering of the downstream impacts. -[Engineering System Success](../../design-principles/#design-for-engineering-system-success) goes beyond -engineering excellence - it focuses on optimization. Success is to work altogether with a foundation -of quality, velocity, and developer happiness, to drive improvements in desired business outcomes. +[Engineering System Success](../design-principles#design-for-engineering-system-success) goes beyond engineering excellence - it focuses on optimization. Success is to work altogether with a foundation of quality, velocity, and developer happiness, to drive improvements in desired business outcomes. ## Key design strategies and checklist @@ -86,9 +82,7 @@ of quality, velocity, and developer happiness, to drive improvements in desired ## Assumptions and preconditions -This recommendation recognises the leading DevEx and DevOps metrics frameworks like [SPACE](https://queue.acm.org/detail.cfm?id=3454124), -[DevEx](https://queue.acm.org/detail.cfm?id=3595878), [DX Core 4](https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4/), -and [DORA](https://dora.dev/). +This recommendation recognises the leading DevEx and DevOps metrics frameworks like [SPACE](https://queue.acm.org/detail.cfm?id=3454124), [DevEx](https://queue.acm.org/detail.cfm?id=3595878), [DX Core 4](https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4/), and [DORA](https://dora.dev/). ## Four zones and twelve metrics @@ -119,49 +113,33 @@ Each organization's context can differ and may prefer different downstream metri ### Data integration -The calculation of the twelve metrics should align with your specific workflows, tech stack, and tools. It is -important to understand your teams' workflows to determine which data to use from GitHub or other data -sources in your engineering system. Data integration from systems like ITSM tools or incident management -platforms may be required for metrics such as lead time or recovery time. Work with business owners to -define key metrics like "production failure" and "in production" to ensure consistency. +The calculation of the twelve metrics should align with your specific workflows, tech stack, and tools. It is important to understand your teams' workflows to determine which data to use from GitHub or other data sources in your engineering system. Data integration from systems like ITSM tools or incident management platforms may be required for metrics such as lead time or recovery time. Work with business owners to define key metrics like "production failure" and "in production" to ensure consistency. ### Qualitative and quantitative data -Metrics like tooling satisfaction or change failure rate can may be complimented with developer surveys, -offering valuable insights without adding complexity. Surveys are particularly useful for organizations -still developing DevEx or DevOps metrics. Leaders should balance the effort and benefits of telemetry-based -measurement versus qualitative feedback. +Metrics like tooling satisfaction or change failure rate can may be complimented with developer surveys, offering valuable insights without adding complexity. Surveys are particularly useful for organizations still developing DevEx or DevOps metrics. Leaders should balance the effort and benefits of telemetry-based measurement versus qualitative feedback. ### Companion metrics for insight -You may employ companion metrics to provide context to these primary metrics, offering insights to the -performance. For example, pairing lead time with change failure rate ensures shorter lead times reflect real -improvements rather than rushed deployments. Striking the right balance is key — too many metrics can dilute -focus, while too few risk misinterpretation. Individual teams should tailor companion metrics to their -workflows, ensuring a holistic view of the engineering system is captured. +You may employ companion metrics to provide context to these primary metrics, offering insights to the performance. For example, pairing lead time with change failure rate ensures shorter lead times reflect real improvements rather than rushed deployments. Striking the right balance is key — too many metrics can dilute focus, while too few risk misinterpretation. Individual teams should tailor companion metrics to their workflows, ensuring a holistic view of the engineering system is captured. ### Metrics are interdependent -These four zones are a form of companion metric-thinking by highlighting their interdependence. Improvements -in one zone should complement others, avoiding trade-offs that undermine overall success. This balanced -approach fosters sustainable engineering system performance aligned with business goals. +These four zones are a form of companion metric-thinking by highlighting their interdependence. Improvements in one zone should complement others, avoiding trade-offs that undermine overall success. This balanced approach fosters sustainable engineering system performance aligned with business goals. ### Balance cost and benefits of measurement -Strike a pragmatic balance between measurement effort and benefits by implementing critical metrics first, -leveraging existing data sources, automating collection pipelines, and regularly evaluating each metric's -relevancy. Remain cautious about potential suboptimization or gaming behaviors for incentive rather than -actual engineering system success. +Strike a pragmatic balance between measurement effort and benefits by implementing critical metrics first, leveraging existing data sources, automating collection pipelines, and regularly evaluating each metric's relevancy. Remain cautious about potential suboptimization or gaming behaviors for incentive rather than actual engineering system success. ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## Related links - + {{% related-links-github-docs %}} diff --git a/content/library/productivity/recommendations/index.yml b/content/library/productivity/recommendations/index.yml new file mode 100644 index 0000000..57eac37 --- /dev/null +++ b/content/library/productivity/recommendations/index.yml @@ -0,0 +1,3 @@ +title: Recommendations +slug: recommendations +weight: 5 diff --git a/content/library/productivity/recommendations/overview.md b/content/library/productivity/recommendations/overview.md new file mode 100644 index 0000000..7b0cab7 --- /dev/null +++ b/content/library/productivity/recommendations/overview.md @@ -0,0 +1,13 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +This section describes specific recommendations that offer expert opinions and actionable prescriptions in the context of the ⚙️ **Productivity** space. Each article discusses various trade-offs and considerations to help you make informed decisions tailored to your unique context. + +Articles in this section include: + +{{< child-pages >}} diff --git a/content/library/productivity/recommendations/schema.json b/content/library/productivity/recommendations/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/productivity/recommendations/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/productivity/schema.json b/content/library/productivity/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/productivity/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/scenarios/_index.md b/content/library/scenarios/_index.md index 9986839..353d6e9 100644 --- a/content/library/scenarios/_index.md +++ b/content/library/scenarios/_index.md @@ -1,34 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Scenarios -weight: 2 -slug: scenarios +title: Overview +linkTitle: Scenarios +weight: 1 --- - -Scenarios are cross-cutting topics that influence multiple GitHub Well-Architected pillars and extend beyond individual design principles. They encompass challenges and considerations that frequently arise when implementing the framework in real-world scenarios, such as large-scale repository strategies, migration planning, and mitigation of common anti-patterns. - -This section will naturally evolve as we continue to gather feedback and refine the framework. If you have suggestions for additional topics or would like to contribute to this section, please reach out to GitHub and/or your Partner contacts. - -## About scenarios - -- **Holistic Impact:** These areas often span multiple pillars, requiring a blend of best practices around security, workflow automation, compliance, and more -- **Practical Application:** The guidance here translates high-level principles into tangible, scenario-driven insights that address specific engineering or organizational concerns -- **Future-Proofing:** By surfacing these design areas early, you can proactively plan for scale, avoid common pitfalls, and better align your GitHub usage with evolving business needs - -## What you will find - -- **Anti-Patterns:** Identifying and avoiding common pitfalls that lead to technical debt or misaligned workflows -- **Topic-Specific Deep Dives:** Detailed explorations of monorepos, advanced automation strategies, organizational governance at scale, and more that zoom in to specific content within each pillar - -## How to Use This Section - -There are a few methods to using this section effectively: - -- **Browse by Topic:** Pick an area relevant to your current challenge—such as planning a migration or integrating monorepos—and learn key considerations and recommended paths for success -- **Link Back to Pillars & Principles:** Each scenario includes references to the underlying pillars and design principles that inform these cross-cutting best practices -- **Leverage Scenario Overviews:** Whenever possible, we include real-world examples or user stories to illustrate how teams navigate these technical decisions in practice - -## Articles in this section - -{{< child-pages >}} diff --git a/content/library/scenarios/anti-patterns.md b/content/library/scenarios/anti-patterns.md index dda6ac4..7c2b62f 100644 --- a/content/library/scenarios/anti-patterns.md +++ b/content/library/scenarios/anti-patterns.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Anti-patterns -weight: 1 +weight: 2 --- diff --git a/content/library/scenarios/index.yml b/content/library/scenarios/index.yml new file mode 100644 index 0000000..5269292 --- /dev/null +++ b/content/library/scenarios/index.yml @@ -0,0 +1,4 @@ +title: Scenarios +weight: 2 +slug: scenarios +icon: WorkflowIcon diff --git a/content/library/scenarios/measuring-genai-impact.md b/content/library/scenarios/measuring-genai-impact.md index 90d3361..5b63078 100644 --- a/content/library/scenarios/measuring-genai-impact.md +++ b/content/library/scenarios/measuring-genai-impact.md @@ -2,7 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Measuring Impact for GenAI Adoption -weight: 3 +weight: 4 publishDate: 2025-04-24 params: authors: [{ name: 'Kitty Chiu', handle: 'kittychiu' }] @@ -39,11 +39,7 @@ Organizations should establish a comprehensive measurement strategy that capture Effective implementation requires that users receive appropriate access to GenAI tools governed by enterprise guardrails. Track metrics such as license activation rate and onboarding completion. -For Copilot, -[GitHub Enterprise settings](https://docs.github.com/en/enterprise-cloud@latest/copilot/managing-copilot/managing-copilot-for-your-enterprise/managing-policies-and-features-for-copilot-in-your-enterprise) -helps Copilot stay compliant with organizational policies, and the -[User Management REST API](https://docs.github.com/en/rest/copilot/copilot-user-management?apiVersion=2022-11-28) -provides quantitative tracking of license activations. +For Copilot, [GitHub Enterprise settings](https://docs.github.com/en/enterprise-cloud@latest/copilot/managing-copilot/managing-copilot-for-your-enterprise/managing-policies-and-features-for-copilot-in-your-enterprise) helps Copilot stay compliant with organizational policies, and the [User Management REST API](https://docs.github.com/en/rest/copilot/copilot-user-management?apiVersion=2022-11-28) provides quantitative tracking of license activations. **Implementation Control Checklist:** @@ -79,7 +75,7 @@ Segment adoption metrics by organization and teams to identify areas requiring a As users integrate GenAI features into their workflows, measure tangible business outcomes with a balanced framework. This validates the organization-specific success criteria of the GenAI tooling investment. -GitHub has a point-of-view detailed in the [four engineering system success zones](../../productivity/recommendations/engineering-system-metrics). +GitHub has a point-of-view detailed in the [four engineering system success zones](../productivity/recommendations/engineering-system-metrics). **Measurement Approach:** Track where teams are positioned on the [J-curve of change](https://www.david-viney.me/post/the-j-curve-of-change), focusing on identifying the inflection point where productivity gains materialize. @@ -97,13 +93,13 @@ Common business challenges where Copilot may assist: ## Seeking further assistance - + {{% seeking-further-assistance-details %}} ## References & next steps - + {{% related-links-github-docs %}} diff --git a/content/library/scenarios/migrations/_index.md b/content/library/scenarios/migrations/_index.md index a620fda..fecb3c8 100644 --- a/content/library/scenarios/migrations/_index.md +++ b/content/library/scenarios/migrations/_index.md @@ -1,30 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Migrations -weight: 2 +title: Overview +linkTitle: Migrations +weight: 3 --- - -Migrations (or an in-place) involves more than just moving data from one location to another. Successful migrations align with multiple Well-Architected pillars -to ensure they support efficient development workflows, maintain compliance and security standards, and deliver tangible value throughout your organization. - -## Why a complete migration plan matters - -- **Strategic Alignment:** Migrations often present an opportunity to reevaluate workflows, branching strategies, and organizational structures. Incorporating GitHub Well-Architected guidance ensures you modernize processes and optimize team collaboration. -- **Risk Mitigation:** Without a well-designed plan, teams risk data loss, extended downtime, or security gaps. By leveraging recommendations under each Well-Architected pillar and through additional GitHub and Partner resources, you minimize disruptions and enhance your environment's integrity. -- **Long-Term Scalability:** A properly executed migration sets the foundation for future growth whether you’re consolidating, switching platforms, or adopting new automation capabilities. - -## Foundational considerations - -- **Planning & Discovery:** Identify existing workflows and repositories to scope the migration effort, and gather requirements from relevant stakeholdersbefore selecting tools or paths -- **Security & Governance:** Properly define auditing goals and ensure that access controls, branch protection rules, and compliance checks are set up properly -- **Change Management:** Provide training and communicate frequently with teams about the timeline, anticipated downtime, and new workflows -- **Testing & Validation:** Perform dry runs or pilot migrations to validate that code, configuration, and metadata (issues, pull requests, etc.) transfer correctly and document any bugs or edge cases - -## References & next steps - -- [Checklist for Repository Migrations](repository-checklist) -- Sample Scripts & Automation -- Case Studies & Best Practices - -By following the guiding principles of GitHub Well-Architected and carefully planning each phase, your organization can migrate with confidence, enhance alignment with best practices, and position itself for ongoing innovation and growth. diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/01-project-planning.md b/content/library/scenarios/migrations/azure-devops-migration-guide/01-project-planning.md index 24dfc3d..9fd8e0f 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/01-project-planning.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/01-project-planning.md @@ -259,5 +259,5 @@ Help your administrators and developers feel confident in the new environment an ## Next steps -1. Proceed to [Environment assessment]({{% ref path="02-source-environment-assessment.md" %}}) +1. Proceed to [Environment assessment](./assess) 2. Consider engaging [GitHub Expert Services](https://github.com/services#services-catalog) for additional support diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/02-source-environment-assessment.md b/content/library/scenarios/migrations/azure-devops-migration-guide/02-source-environment-assessment.md index 9b96472..02a196e 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/02-source-environment-assessment.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/02-source-environment-assessment.md @@ -71,7 +71,7 @@ Identify which Azure DevOps services you want to retain to ensure your teams rem ### Integration dependencies -Please refer to the training strategy in [project planning]({{% ref path="01-project-planning.md" %}}) for assistance in training on any additional integration dependencies. +Please refer to the training strategy in [project planning](./plan) for assistance in training on any additional integration dependencies. Understanding service relationships is key to maintaining workflows: @@ -305,7 +305,7 @@ Understanding performance factors helps optimize the migration process: After completing your environment assessment: 1. Review the [GitHub Well-Architected Framework](https://wellarchitected.github.com/library/governance/checklist/) for governance planning -2. Proceed to [Target Environment Setup]({{% ref path="03-target-environment.md" %}}) to prepare your GitHub Enterprise Cloud environment +2. Proceed to [Target Environment Setup](./setup) to prepare your GitHub Enterprise Cloud environment {{< callout type="info" >}} Use the inventory report data to create a migration timeline that minimizes disruption to active development work. diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/03-target-environment.md b/content/library/scenarios/migrations/azure-devops-migration-guide/03-target-environment.md index e7a437c..e77c191 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/03-target-environment.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/03-target-environment.md @@ -118,8 +118,8 @@ GitHub Enterprise Cloud with Data Residency requires Managed Users. ### Pre-migration integration setup -- [ ] Review your [assessment findings]({{% ref path="02-source-environment-assessment.md" %}}) for Azure DevOps service dependencies -- [ ] Plan integration configuration based on your [project charter]({{% ref path="01-project-planning.md" %}}) decisions +- [ ] Review your [assessment findings](./assess) for Azure DevOps service dependencies +- [ ] Plan integration configuration based on your [project charter](./plan) decisions - [ ] Test authentication methods between Azure DevOps and GitHub Enterprise Cloud - [ ] Validate service connections and permissions before migration begins @@ -148,7 +148,7 @@ If planning to keep Azure Pipelines temporarily or permanently: ## Organization structure {{< callout type="info" >}} -**Reference your assessment**: Before setting up your organization structure, review your findings from the [repository documentation]({{% ref path="02-source-environment-assessment.md#repository-documentation" %}}) and [access patterns]({{% ref path="02-source-environment-assessment.md#access-patterns" %}}) sections in your assessment. +**Reference your assessment**: Before setting up your organization structure, review your findings from the [repository documentation](./assess#repository-documentation) and [access patterns](./assess#access-patterns) sections in your assessment. This will help you understand how to properly structure teams and permissions based on your current Azure DevOps setup and repository organization. {{< /callout >}} @@ -315,4 +315,4 @@ Without enabling GitHub Actions, functionality like [GitHub Copilot Coding Agent After completing your target environment setup: 1. Review the [GitHub Well-Architected Framework Security Pillar](https://wellarchitected.github.com/pillars/security/) -2. Proceed to [Migration Testing]({{% ref path="04-migration-testing.md" %}}) +2. Proceed to [Migration Testing](./test) diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/04-migration-testing.md b/content/library/scenarios/migrations/azure-devops-migration-guide/04-migration-testing.md index 31a64d3..ee83e40 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/04-migration-testing.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/04-migration-testing.md @@ -399,4 +399,4 @@ After completing migration testing: 1. Update your migration runbook with lessons learned 2. Schedule your production migration -3. Proceed to [Repository migration]({{% ref path="05-repository-migration.md" %}}) +3. Proceed to [Repository migration](./migrate) diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/05-repository-migration.md b/content/library/scenarios/migrations/azure-devops-migration-guide/05-repository-migration.md index b7e360e..14928f2 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/05-repository-migration.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/05-repository-migration.md @@ -341,4 +341,4 @@ After completing the repository migration: 1. Verify all repositories are accessible and functioning 2. Ensure mannequins have been properly reclaimed 3. Confirm critical integrations are working -4. Proceed to [Post-migration activities]({{% ref path="06-post-migration.md" %}}) +4. Proceed to [Post-migration activities](./post-migration) diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/_index.md b/content/library/scenarios/migrations/azure-devops-migration-guide/_index.md index 477a301..256485f 100644 --- a/content/library/scenarios/migrations/azure-devops-migration-guide/_index.md +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/_index.md @@ -1,244 +1,7 @@ --- # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT -title: Azure DevOps to GitHub Enterprise Migration Guide +title: Overview +linkTitle: Azure DevOps to GitHub Enterprise Migration Guide +weight: 2 --- - -This guide is your step-by-step reference for migrating from Azure DevOps to GitHub Enterprise Cloud. Each section provides practical steps, clear recommendations, and links to helpful resources—so you can move forward with confidence. - -{{< callout type="info" >}} -Each page in this guide includes focused learning resources to support every phase of your migration journey. -{{< /callout >}} - -## Why a Complete Migration Plan Matters - -- **Strategic alignment:** Migrations are an opportunity to review workflows, branching strategies, and team structures. -- **Risk mitigation:** A well-structured plan helps prevent data loss, downtime, and security issues. -- **Long-term scalability:** A successful migration prepares your organization for future growth and innovation. - -## Learning resources - -Start with these foundational resources about GitHub and migration: - -- **GitHub documentation** - - [Introduction to GitHub Enterprise Cloud](https://docs.github.com/enterprise-cloud@latest/get-started/learning-about-github) – Platform overview - - [Migration fundamentals](https://docs.github.com/enterprise-cloud@latest/migrations/overview/planning-your-migration-to-github) – Core concepts -- **Microsoft Learn** - - [GitHub Enterprise fundamentals](https://learn.microsoft.com/en-us/training/paths/github-administration-products/) – Platform essentials - - [Azure DevOps integration](https://learn.microsoft.com/en-us/azure/devops/cross-service/github-integration) – Integration options - -## Features and interoperability - -When planning a migration from Azure DevOps to GitHub, it's important to understand the differences in features and capabilities, as well as the integration options available to maintain existing Azure DevOps services if needed. - -### Key Feature Comparison - -#### Repositories and Code Management - -- **Azure DevOps:** Supports Git and legacy TFVC repositories, with built-in code review tools. -- **GitHub:** Focuses on Git repositories, with advanced code review workflows, pull requests, and governance capabilities. GitHub's branching and merging strategies are optimized for collaborative development. -- **Integration options:** Complete repository migration with history and metadata using GitHub Enterprise Importer. - -#### Work Item Tracking - -- **Azure DevOps:** Azure Boards provides comprehensive work item tracking, sprint planning, and reporting features. It is highly configurable and integrates with other Azure DevOps services. -- **GitHub:** GitHub Issues and Projects offer an integrated approach to work item tracking, with templates, labels, sub-issues, issue types, and milestones. -- **Integration options:** Ability to maintain Azure Boards integration with GitHub repositories for teams that prefer Azure Boards. - -#### CI/CD - -- **Azure DevOps:** Azure Pipelines offers robust CI/CD capabilities, supporting multi-platform builds and deployments. -- **GitHub:** GitHub Actions provides a flexible and customizable automation platform for CI/CD. -- **Integration options:** Ability to continue using Azure Pipelines with GitHub repositories while transitioning. - -#### Collaboration and Community - -- **Azure DevOps:** Primarily used within organizations for private projects. While it supports public projects, the community aspect is less emphasized. -- **GitHub:** Known for its strong community and collaborative focus. GitHub hosts millions of open-source projects and has this community at its core. Features like discussions, pull requests, and issue tracking foster collaboration among developers worldwide. -- **Integration options:** Not applicable. - -## Migration Journey Map - -Your migration journey includes these steps: - -1. [Project Planning]({{% ref path="01-project-planning.md" %}}) – _Establish your migration strategy and timeline_ -2. [Source Environment Assessment]({{% ref path="02-source-environment-assessment.md" %}}) – _Analyze your current Azure DevOps setup_ -3. [Target Environment Setup]({{% ref path="03-target-environment.md" %}}) – _Prepare GitHub Enterprise Cloud_ -4. [Migration Testing]({{% ref path="04-migration-testing.md" %}}) – _Test and validate your migration process_ -5. [Repository Migration]({{% ref path="05-repository-migration.md" %}}) – _Move your code and history_ -6. [Post-Migration Activities]({{% ref path="06-post-migration.md" %}}) – _Review, optimize, and support ongoing improvements_ - -{{< callout type="info" >}} -Start with the Project Planning guide to establish a strong foundation for your migration journey. -{{< /callout >}} - -## Getting Started - -Before you begin, review these essential resources: - -| Resource | Purpose | -|----------|----------| -| [GitHub Enterprise Cloud documentation](https://docs.github.com/enterprise-cloud@latest) | Platform documentation | -| [GitHub Enterprise Importer](https://docs.github.com/migrations/using-github-enterprise-importer) | Migration tool guide | -| [Azure DevOps Integration](https://learn.microsoft.com/en-us/azure/devops/cross-service/github-integration) | Integration options | -| [Well-Architected Framework](https://wellarchitected.github.com/) | Best practices | - -## Seeking further assistance - - -{{% seeking-further-assistance-details %}} - -## Migration Checklist - -This checklist provides an overview of the necessary steps for migrating from Azure DevOps to GitHub Enterprise Cloud. Detailed information is provided in each section of the guide. - -### Migration Tools - -Compare tools at [Migration tools comparison on GitHub Docs](https://docs.github.com/enterprise-cloud@latest/migrations/overview/migration-paths-to-github) - -### GitHub Enterprise Importer (GEI) - -GEI is recommended for most migrations. - -#### Key Benefits - -| Feature | Description | -|---------|-------------| -| History | _Maintains commit history and authorship_ | -| PRs | _Migrates pull requests with review history_ | -| Work Items | _Preserves links and converts to issues_ | -| Automation | _Supports interactive and scripted migrations_ | -| Reliability | _Provides error handling and retry mechanisms_ | - -> Review [GEI limitations on migrated data.](https://docs.github.com/migrations/using-github-enterprise-importer/migrating-from-azure-devops-to-github-enterprise-cloud/about-migrations-from-azure-devops-to-github-enterprise-cloud#limitations-on-migrated-data) - -#### Git-based Migration - -Consider this approach when: - -- You only need to migrate source code -- Metadata migration is not required - -### Azure DevOps Integration Options - -After migrating repositories to GitHub, you can maintain integration with Azure DevOps services: - -#### Azure Boards Integration - -- **Work Item Linking**: Connect GitHub repositories to Azure Boards to: - - Link commits and pull requests to work items - - Update work item status from GitHub commits - - View GitHub development activity in Azure Boards - - [Configure the Azure Boards app for GitHub](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app) - -#### Azure Pipelines Integration - -- **Build and Deploy from GitHub**: Keep using Azure Pipelines with GitHub repositories: - - Use Azure Pipelines for CI/CD while migrating gradually - - Trigger builds from GitHub events - - Deploy to Azure services - - [Connect Azure Pipelines to GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github) - -### Project Planning - -Find additional guidance in the [Project Planning guide]({{% ref path="01-project-planning.md" %}}). - -Planning is crucial for a successful migration as it provides a structured framework to identify and address potential challenges, ensuring a smooth and efficient transition with minimal disruption to operations. - -- Define the project scope, objectives, and success criteria. -- Document individuals who need to be involved or informed at different stages. -- Identify project stakeholders and decision-makers. -- Establish a project timeline with key milestones. -- Assess potential risks and develop mitigation strategies. -- Create and maintain a migration plan runbook. -- Create a comprehensive communication plan. -- Plan migration pace (e.g., all at once or phased). -- Document migration schedule for each repository. -- Identify and document the training needs for both developers and administrators. - -### Assessment of Current Environment - -Find additional guidance in the [Source Environment Assessment guide]({{% ref path="02-source-environment-assessment.md" %}}). - -Understanding the current environment is fundamental for a successful migration. A thorough assessment provides insights into the existing usage, dependencies, and potential challenges, enabling informed decision-making and minimizing disruptions during the transition. - -- Document the current organizational and team structure. -- Document inventory structure to applications and services. - - Use the `gh ado2gh inventory-report` command to generate reports about your Azure DevOps environment, including organizations, projects, repositories, and pipelines. -- Document dependencies for repositories. -- [Assess and document existing repository data like sizes, commit history, and Git LFS usage.](https://docs.github.com/migrations/overview/planning-your-migration-to-github#building-a-basic-inventory-of-the-repositories-you-want-to-migrate) -- Document branch policies to recreate in the target environment. -- Document the current permissions and access patterns of repositories. -- Document all integrations and external tools in use. -- Document current usage patterns and workflows for transition planning. -- [Design plans for policy and governance of the target environment](https://wellarchitected.github.com/library/governance/checklist/). - -### Target Environment Design and Configuration - -Find additional guidance in the [Target Environment Setup guide]({{% ref path="03-target-environment.md" %}}). - -Making sure that the target GitHub Enterprise Cloud environment is set up for success is critical for a successful migration process. Learn more about GitHub Enterprise Administration and Governance on [GitHub Resources](https://resources.github.com/learn/pathways/administration-governance/essentials/administration-governance-github-enterprise-cloud/) and [GitHub Well Architected](https://wellarchitected.github.com/). - -- Administrators should plan for learning about GitHub Enterprise Cloud and its features. - - [Microsoft Learn](https://learn.microsoft.com/en-us/training/paths/github-administration-products/) has options available for self-paced learning. -- Map source environment repository structures to [target organizations/repositories](https://docs.github.com/migrations/overview/planning-your-migration-to-github#designing-your-organization-structure-for-the-migration-destination). -- Plan the structure of the target environment. -- Plan for handling large files and repositories. -- Plan for handling release tags and release artifacts. -- Set up identity access in the target environment. -- Configure enterprise, organization, and team structure. -- Configure governance and policy settings. -- Conduct security assessments on the target environment. - -### Migration Testing and Preparation - -Find additional guidance in the [Migration Testing guide]({{% ref path="04-migration-testing.md" %}}). - -Thorough testing and preparation are essential for successful migrations, as they help identify and mitigate potential issues, ensuring a smooth transition and minimizing disruptions. - -- Define testing criteria and success metrics. -- Identify migration types for each repository. -- Choose migration tools ([GitHub Enterprise Importer](https://docs.github.com/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products) is recommended). -- Use `gh ado2gh inventory-report` data to prioritize and batch repositories for migration: - - Identify inactive repositories that can be archived or migrated later - - Group repositories by size, activity level, or complexity for efficient migration planning - - Identify repositories with potential migration challenges (large files, extensive history) -- Correct any issues on existing repository data (such as large files, commit history, metadata sizing, and Git LFS usage) based on migration method. -- [Perform dry-run migrations to identify issues.](https://docs.github.com/migrations/overview/planning-your-migration-to-github#performing-a-dry-run-migration-for-every-repository) -- Identify integration and external tools compatibility issues. -- Run pilot migrations, document and address issues. -- Configure integration and external tools with pilot migrations. -- Communicate with pilot users and gather feedback. -- Establish a process for handling migration failures. -- Validate governance and policy settings for any changes needed. -- Document readiness of the destination environment. -- Document steps to revert in case of failure. - -### Repository Migration - -Find additional guidance in the [Repository Migration guide]({{% ref path="05-repository-migration.md" %}}). - -- Document issues encountered and resolutions. -- Freeze changes in the source environment. -- Create a dedicated migration support channel for issue resolution -- Execute the migration plan runbook. -- Track migration status and fix errors. -- [Link identity attribution](https://docs.github.com/enterprise-cloud@latest/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer) (when using GitHub Enterprise Importer). - -### Post-Migration Activities - -Find additional guidance in the [Post-Migration Activities guide]({{% ref path="06-post-migration.md" %}}). - -Post-migration steps are crucial for a successful transition. They involve verifying data integrity, validating functionality, and addressing any issues. Thorough testing minimizes disruptions and ensures the new environment meets requirements. Additionally, it establishes best practices for ongoing maintenance and long-term success. - -- Confirm repository visibility, permissions, and access controls. -- Validate migrated data. -- Convert pipelines to GitHub Actions workflows. -- Ensure CI/CD and other integrations work. -- Validate governance and policy settings for any changes needed. -- Validate compliance and auditing requirements. -- Update configurations for integrations and tools. -- Gather developer feedback and improvement suggestions. -- Monitor performance and usage. -- Conduct a post-mortem for lessons learned. -- Plan for deprecation of the source environment. diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/index.yml b/content/library/scenarios/migrations/azure-devops-migration-guide/index.yml new file mode 100644 index 0000000..d4e416f --- /dev/null +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/index.yml @@ -0,0 +1,3 @@ +title: Azure DevOps to GitHub Enterprise Migration Guide +weight: 2 +slug: azure-devops-migration-guide diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/overview.md b/content/library/scenarios/migrations/azure-devops-migration-guide/overview.md new file mode 100644 index 0000000..dcc6470 --- /dev/null +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/overview.md @@ -0,0 +1,246 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +This guide is your step-by-step reference for migrating from Azure DevOps to GitHub Enterprise Cloud. Each section provides practical steps, clear recommendations, and links to helpful resources—so you can move forward with confidence. + +{{< callout type="info" >}} +Each page in this guide includes focused learning resources to support every phase of your migration journey. +{{< /callout >}} + +## Why a Complete Migration Plan Matters + +- **Strategic alignment:** Migrations are an opportunity to review workflows, branching strategies, and team structures. +- **Risk mitigation:** A well-structured plan helps prevent data loss, downtime, and security issues. +- **Long-term scalability:** A successful migration prepares your organization for future growth and innovation. + +## Learning resources + +Start with these foundational resources about GitHub and migration: + +- **GitHub documentation** + - [Introduction to GitHub Enterprise Cloud](https://docs.github.com/enterprise-cloud@latest/get-started/learning-about-github) – Platform overview + - [Migration fundamentals](https://docs.github.com/enterprise-cloud@latest/migrations/overview/planning-your-migration-to-github) – Core concepts +- **Microsoft Learn** + - [GitHub Enterprise fundamentals](https://learn.microsoft.com/en-us/training/paths/github-administration-products/) – Platform essentials + - [Azure DevOps integration](https://learn.microsoft.com/en-us/azure/devops/cross-service/github-integration) – Integration options + +## Features and interoperability + +When planning a migration from Azure DevOps to GitHub, it's important to understand the differences in features and capabilities, as well as the integration options available to maintain existing Azure DevOps services if needed. + +### Key Feature Comparison + +#### Repositories and Code Management + +- **Azure DevOps:** Supports Git and legacy TFVC repositories, with built-in code review tools. +- **GitHub:** Focuses on Git repositories, with advanced code review workflows, pull requests, and governance capabilities. GitHub's branching and merging strategies are optimized for collaborative development. +- **Integration options:** Complete repository migration with history and metadata using GitHub Enterprise Importer. + +#### Work Item Tracking + +- **Azure DevOps:** Azure Boards provides comprehensive work item tracking, sprint planning, and reporting features. It is highly configurable and integrates with other Azure DevOps services. +- **GitHub:** GitHub Issues and Projects offer an integrated approach to work item tracking, with templates, labels, sub-issues, issue types, and milestones. +- **Integration options:** Ability to maintain Azure Boards integration with GitHub repositories for teams that prefer Azure Boards. + +#### CI/CD + +- **Azure DevOps:** Azure Pipelines offers robust CI/CD capabilities, supporting multi-platform builds and deployments. +- **GitHub:** GitHub Actions provides a flexible and customizable automation platform for CI/CD. +- **Integration options:** Ability to continue using Azure Pipelines with GitHub repositories while transitioning. + +#### Collaboration and Community + +- **Azure DevOps:** Primarily used within organizations for private projects. While it supports public projects, the community aspect is less emphasized. +- **GitHub:** Known for its strong community and collaborative focus. GitHub hosts millions of open-source projects and has this community at its core. Features like discussions, pull requests, and issue tracking foster collaboration among developers worldwide. +- **Integration options:** Not applicable. + +## Migration Journey Map + +Your migration journey includes these steps: + +1. [Project Planning](./plan) – _Establish your migration strategy and timeline_ +2. [Source Environment Assessment](./assess) – _Analyze your current Azure DevOps setup_ +3. [Target Environment Setup](./setup) – _Prepare GitHub Enterprise Cloud_ +4. [Migration Testing](./test) – _Test and validate your migration process_ +5. [Repository Migration](./migrate) – _Move your code and history_ +6. [Post-Migration Activities](./post-migration) – _Review, optimize, and support ongoing improvements_ + +{{< callout type="info" >}} +Start with the Project Planning guide to establish a strong foundation for your migration journey. +{{< /callout >}} + +## Getting Started + +Before you begin, review these essential resources: + +| Resource | Purpose | +|----------|----------| +| [GitHub Enterprise Cloud documentation](https://docs.github.com/enterprise-cloud@latest) | Platform documentation | +| [GitHub Enterprise Importer](https://docs.github.com/migrations/using-github-enterprise-importer) | Migration tool guide | +| [Azure DevOps Integration](https://learn.microsoft.com/en-us/azure/devops/cross-service/github-integration) | Integration options | +| [Well-Architected Framework](https://wellarchitected.github.com/) | Best practices | + +## Seeking further assistance + + +{{% seeking-further-assistance-details %}} + +## Migration Checklist + +This checklist provides an overview of the necessary steps for migrating from Azure DevOps to GitHub Enterprise Cloud. Detailed information is provided in each section of the guide. + +### Migration Tools + +Compare tools at [Migration tools comparison on GitHub Docs](https://docs.github.com/enterprise-cloud@latest/migrations/overview/migration-paths-to-github) + +### GitHub Enterprise Importer (GEI) + +GEI is recommended for most migrations. + +#### Key Benefits + +| Feature | Description | +|---------|-------------| +| History | _Maintains commit history and authorship_ | +| PRs | _Migrates pull requests with review history_ | +| Work Items | _Preserves links and converts to issues_ | +| Automation | _Supports interactive and scripted migrations_ | +| Reliability | _Provides error handling and retry mechanisms_ | + +> Review [GEI limitations on migrated data.](https://docs.github.com/migrations/using-github-enterprise-importer/migrating-from-azure-devops-to-github-enterprise-cloud/about-migrations-from-azure-devops-to-github-enterprise-cloud#limitations-on-migrated-data) + +#### Git-based Migration + +Consider this approach when: + +- You only need to migrate source code +- Metadata migration is not required + +### Azure DevOps Integration Options + +After migrating repositories to GitHub, you can maintain integration with Azure DevOps services: + +#### Azure Boards Integration + +- **Work Item Linking**: Connect GitHub repositories to Azure Boards to: + - Link commits and pull requests to work items + - Update work item status from GitHub commits + - View GitHub development activity in Azure Boards + - [Configure the Azure Boards app for GitHub](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app) + +#### Azure Pipelines Integration + +- **Build and Deploy from GitHub**: Keep using Azure Pipelines with GitHub repositories: + - Use Azure Pipelines for CI/CD while migrating gradually + - Trigger builds from GitHub events + - Deploy to Azure services + - [Connect Azure Pipelines to GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github) + +### Project Planning + +Find additional guidance in the [Project Planning guide](./plan). + +Planning is crucial for a successful migration as it provides a structured framework to identify and address potential challenges, ensuring a smooth and efficient transition with minimal disruption to operations. + +- Define the project scope, objectives, and success criteria. +- Document individuals who need to be involved or informed at different stages. +- Identify project stakeholders and decision-makers. +- Establish a project timeline with key milestones. +- Assess potential risks and develop mitigation strategies. +- Create and maintain a migration plan runbook. +- Create a comprehensive communication plan. +- Plan migration pace (e.g., all at once or phased). +- Document migration schedule for each repository. +- Identify and document the training needs for both developers and administrators. + +### Assessment of Current Environment + +Find additional guidance in the [Source Environment Assessment guide](./assess). + +Understanding the current environment is fundamental for a successful migration. A thorough assessment provides insights into the existing usage, dependencies, and potential challenges, enabling informed decision-making and minimizing disruptions during the transition. + +- Document the current organizational and team structure. +- Document inventory structure to applications and services. + - Use the `gh ado2gh inventory-report` command to generate reports about your Azure DevOps environment, including organizations, projects, repositories, and pipelines. +- Document dependencies for repositories. +- [Assess and document existing repository data like sizes, commit history, and Git LFS usage.](https://docs.github.com/migrations/overview/planning-your-migration-to-github#building-a-basic-inventory-of-the-repositories-you-want-to-migrate) +- Document branch policies to recreate in the target environment. +- Document the current permissions and access patterns of repositories. +- Document all integrations and external tools in use. +- Document current usage patterns and workflows for transition planning. +- [Design plans for policy and governance of the target environment](https://wellarchitected.github.com/library/governance/checklist/). + +### Target Environment Design and Configuration + +Find additional guidance in the [Target Environment Setup guide](./setup). + +Making sure that the target GitHub Enterprise Cloud environment is set up for success is critical for a successful migration process. Learn more about GitHub Enterprise Administration and Governance on [GitHub Resources](https://resources.github.com/learn/pathways/administration-governance/essentials/administration-governance-github-enterprise-cloud/) and [GitHub Well Architected](https://wellarchitected.github.com/). + +- Administrators should plan for learning about GitHub Enterprise Cloud and its features. + - [Microsoft Learn](https://learn.microsoft.com/en-us/training/paths/github-administration-products/) has options available for self-paced learning. +- Map source environment repository structures to [target organizations/repositories](https://docs.github.com/migrations/overview/planning-your-migration-to-github#designing-your-organization-structure-for-the-migration-destination). +- Plan the structure of the target environment. +- Plan for handling large files and repositories. +- Plan for handling release tags and release artifacts. +- Set up identity access in the target environment. +- Configure enterprise, organization, and team structure. +- Configure governance and policy settings. +- Conduct security assessments on the target environment. + +### Migration Testing and Preparation + +Find additional guidance in the [Migration Testing guide](./test). + +Thorough testing and preparation are essential for successful migrations, as they help identify and mitigate potential issues, ensuring a smooth transition and minimizing disruptions. + +- Define testing criteria and success metrics. +- Identify migration types for each repository. +- Choose migration tools ([GitHub Enterprise Importer](https://docs.github.com/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products) is recommended). +- Use `gh ado2gh inventory-report` data to prioritize and batch repositories for migration: + - Identify inactive repositories that can be archived or migrated later + - Group repositories by size, activity level, or complexity for efficient migration planning + - Identify repositories with potential migration challenges (large files, extensive history) +- Correct any issues on existing repository data (such as large files, commit history, metadata sizing, and Git LFS usage) based on migration method. +- [Perform dry-run migrations to identify issues.](https://docs.github.com/migrations/overview/planning-your-migration-to-github#performing-a-dry-run-migration-for-every-repository) +- Identify integration and external tools compatibility issues. +- Run pilot migrations, document and address issues. +- Configure integration and external tools with pilot migrations. +- Communicate with pilot users and gather feedback. +- Establish a process for handling migration failures. +- Validate governance and policy settings for any changes needed. +- Document readiness of the destination environment. +- Document steps to revert in case of failure. + +### Repository Migration + +Find additional guidance in the [Repository Migration guide](./migrate). + +- Document issues encountered and resolutions. +- Freeze changes in the source environment. +- Create a dedicated migration support channel for issue resolution +- Execute the migration plan runbook. +- Track migration status and fix errors. +- [Link identity attribution](https://docs.github.com/enterprise-cloud@latest/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/reclaiming-mannequins-for-github-enterprise-importer) (when using GitHub Enterprise Importer). + +### Post-Migration Activities + +Find additional guidance in the [Post-Migration Activities guide](./post-migration). + +Post-migration steps are crucial for a successful transition. They involve verifying data integrity, validating functionality, and addressing any issues. Thorough testing minimizes disruptions and ensures the new environment meets requirements. Additionally, it establishes best practices for ongoing maintenance and long-term success. + +- Confirm repository visibility, permissions, and access controls. +- Validate migrated data. +- Convert pipelines to GitHub Actions workflows. +- Ensure CI/CD and other integrations work. +- Validate governance and policy settings for any changes needed. +- Validate compliance and auditing requirements. +- Update configurations for integrations and tools. +- Gather developer feedback and improvement suggestions. +- Monitor performance and usage. +- Conduct a post-mortem for lessons learned. +- Plan for deprecation of the source environment. diff --git a/content/library/scenarios/migrations/azure-devops-migration-guide/schema.json b/content/library/scenarios/migrations/azure-devops-migration-guide/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/scenarios/migrations/azure-devops-migration-guide/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/scenarios/migrations/index.yml b/content/library/scenarios/migrations/index.yml new file mode 100644 index 0000000..805fef1 --- /dev/null +++ b/content/library/scenarios/migrations/index.yml @@ -0,0 +1,3 @@ +title: Migrations +weight: 3 +slug: migrations diff --git a/content/library/scenarios/migrations/overview.md b/content/library/scenarios/migrations/overview.md new file mode 100644 index 0000000..299ffbb --- /dev/null +++ b/content/library/scenarios/migrations/overview.md @@ -0,0 +1,31 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +Migrations (or an in-place) involves more than just moving data from one location to another. Successful migrations align with multiple Well-Architected pillars +to ensure they support efficient development workflows, maintain compliance and security standards, and deliver tangible value throughout your organization. + +## Why a complete migration plan matters + +- **Strategic Alignment:** Migrations often present an opportunity to reevaluate workflows, branching strategies, and organizational structures. Incorporating GitHub Well-Architected guidance ensures you modernize processes and optimize team collaboration. +- **Risk Mitigation:** Without a well-designed plan, teams risk data loss, extended downtime, or security gaps. By leveraging recommendations under each Well-Architected pillar and through additional GitHub and Partner resources, you minimize disruptions and enhance your environment's integrity. +- **Long-Term Scalability:** A properly executed migration sets the foundation for future growth whether you’re consolidating, switching platforms, or adopting new automation capabilities. + +## Foundational considerations + +- **Planning & Discovery:** Identify existing workflows and repositories to scope the migration effort, and gather requirements from relevant stakeholdersbefore selecting tools or paths +- **Security & Governance:** Properly define auditing goals and ensure that access controls, branch protection rules, and compliance checks are set up properly +- **Change Management:** Provide training and communicate frequently with teams about the timeline, anticipated downtime, and new workflows +- **Testing & Validation:** Perform dry runs or pilot migrations to validate that code, configuration, and metadata (issues, pull requests, etc.) transfer correctly and document any bugs or edge cases + +## References & next steps + +- [Checklist for Repository Migrations](./repository-checklist) +- Sample Scripts & Automation +- Case Studies & Best Practices + +By following the guiding principles of GitHub Well-Architected and carefully planning each phase, your organization can migrate with confidence, enhance alignment with best practices, and position itself for ongoing innovation and growth. diff --git a/content/library/scenarios/migrations/repository-checklist.md b/content/library/scenarios/migrations/repository-checklist.md index 3227ebe..36b396b 100644 --- a/content/library/scenarios/migrations/repository-checklist.md +++ b/content/library/scenarios/migrations/repository-checklist.md @@ -2,6 +2,7 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Checklist for Repository Migrations +weight: 3 description: A checklist to help you plan and execute a successful repository migration to GitHub. aliases: - "planning-guides/repository-checklist/" @@ -13,7 +14,7 @@ aliases: This checklist is intended to facilitate a successful migration to GitHub by providing an overview of the necessary steps involved, with a focus on migrating repositories. This checklist is a guide on **what** needs to be done for a migration as an approach for planning. ## Seeking further assistance - + {{% seeking-further-assistance-details %}} diff --git a/content/library/scenarios/migrations/schema.json b/content/library/scenarios/migrations/schema.json new file mode 100644 index 0000000..fe13942 --- /dev/null +++ b/content/library/scenarios/migrations/schema.json @@ -0,0 +1,37 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": ["title", "weight"], + "additionalProperties": true +} diff --git a/content/library/scenarios/monorepos.md b/content/library/scenarios/monorepos.md index 9d0a210..114e77e 100644 --- a/content/library/scenarios/monorepos.md +++ b/content/library/scenarios/monorepos.md @@ -2,13 +2,10 @@ # SPDX-FileCopyrightText: GitHub and The Project Authors # SPDX-License-Identifier: MIT title: Monorepos -weight: 3 +weight: 5 --- -The common definition of a monorepo is that it combines multiple projects or components into a single shared repository. -However, it can often depend on the context. -The monorepo approach can simplify code sharing and dependency management, but it also introduces new considerations around scalability, security, and developer workflows. -By aligning monorepo decisions with GitHub Well-Architected recommendations, teams can realize significant collaboration benefits while maintaining a robust, well-governed environment. +The common definition of a monorepo is that it combines multiple projects or components into a single shared repository. However, it can often depend on the context. The monorepo approach can simplify code sharing and dependency management, but it also introduces new considerations around scalability, security, and developer workflows. By aligning monorepo decisions with GitHub Well-Architected recommendations, teams can realize significant collaboration benefits while maintaining a robust, well-governed environment. ## Monorepo fundamentals @@ -18,23 +15,17 @@ By aligning monorepo decisions with GitHub Well-Architected recommendations, tea ## Key considerations -When planning for a monorepo, begin by mapping out how code and teams will be structured. -Aligning repository organization with logical projects, team boundaries, and release cadences prevents confusion and ensures efficient collaboration. -Build and testing processes can become resource-intensive as your monorepo grows, so carefully crafted continuous -integration and delivery workflows (i.e. matrix builds, labeled pull requests, subdirectory-based triggers, etc) help maintain quick feedback cycles and avoid bottlenecks. +When planning for a monorepo, begin by mapping out how code and teams will be structured. Aligning repository organization with logical projects, team boundaries, and release cadences prevents confusion and ensures efficient collaboration. Build and testing processes can become resource-intensive as your monorepo grows, so carefully crafted continuous integration and delivery workflows (i.e. matrix builds, labeled pull requests, subdirectory-based triggers, etc) help maintain quick feedback cycles and avoid bottlenecks. Governance becomes increasingly important in a large unified codebase. Permissions should be assigned with precision, ensuring that only appropriate teams or individuals can modify high-impact areas or workflows. Similarly, well-defined branch protection and review policies can keep code quality high while avoiding disruptions across multiple projects. -Consolidating everything into one repository also necessitates a robust approach to dependency and version management. -While centrally shared libraries reduce duplication, any incompatible changes or upgrades can propagate widely, so adopting clear -versioning strategies or isolating packages under dedicated folders can provide a safety net. It is possible to also inadvertently -increase aspects like clone time if the repository grows too large, so a plan on this scenario is key. +Consolidating everything into one repository also necessitates a robust approach to dependency and version management. While centrally shared libraries reduce duplication, any incompatible changes or upgrades can propagate widely, so adopting clear versioning strategies or isolating packages under dedicated folders can provide a safety net. It is possible to also inadvertently increase aspects like clone time if the repository grows too large, so a plan on this scenario is key. ## References & next steps -- [Scaling Git Repositories](/library/architecture/recommendations/scaling-git-repositories) - - [Exploring repository architecture strategy](/library/architecture/recommendations/scaling-git-repositories/repository-architecture-strategy) - - [Managing large Git Repositories](/library/architecture/recommendations/scaling-git-repositories/large-git-repositories) - - [When to use Git LFS](/library/architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs) +- [Scaling Git Repositories](../architecture/recommendations/scaling-git-repositories/overview) + - [Exploring repository architecture strategy](../architecture/recommendations/scaling-git-repositories/repository-architecture-strategy) + - [Managing large Git Repositories](../architecture/recommendations/scaling-git-repositories/large-git-repositories) + - [When to use Git LFS](../architecture/recommendations/scaling-git-repositories/when-to-use-git-lfs) - [Monorepo Book](https://monorepo-book.github.io) diff --git a/content/library/scenarios/nist-ssdf-implementation.md b/content/library/scenarios/nist-ssdf-implementation.md index 6cf9aab..19ca6a8 100644 --- a/content/library/scenarios/nist-ssdf-implementation.md +++ b/content/library/scenarios/nist-ssdf-implementation.md @@ -1,6 +1,7 @@ --- draft: false title: "Implementing the NIST SSDF with GitHub" +weight: 6 publishDate: 2026-01-20 params: authors: [ diff --git a/content/library/scenarios/overview.md b/content/library/scenarios/overview.md new file mode 100644 index 0000000..f3c98fd --- /dev/null +++ b/content/library/scenarios/overview.md @@ -0,0 +1,34 @@ +--- +# SPDX-FileCopyrightText: GitHub and The Project Authors +# SPDX-License-Identifier: MIT +title: Overview +weight: 1 +--- + + +Scenarios are cross-cutting topics that influence multiple GitHub Well-Architected pillars and extend beyond individual design principles. They encompass challenges and considerations that frequently arise when implementing the framework in real-world scenarios, such as large-scale repository strategies, migration planning, and mitigation of common anti-patterns. + +This section will naturally evolve as we continue to gather feedback and refine the framework. If you have suggestions for additional topics or would like to contribute to this section, please reach out to GitHub and/or your Partner contacts. + +## About scenarios + +- **Holistic Impact:** These areas often span multiple pillars, requiring a blend of best practices around security, workflow automation, compliance, and more +- **Practical Application:** The guidance here translates high-level principles into tangible, scenario-driven insights that address specific engineering or organizational concerns +- **Future-Proofing:** By surfacing these design areas early, you can proactively plan for scale, avoid common pitfalls, and better align your GitHub usage with evolving business needs + +## What you will find + +- **Anti-Patterns:** Identifying and avoiding common pitfalls that lead to technical debt or misaligned workflows +- **Topic-Specific Deep Dives:** Detailed explorations of monorepos, advanced automation strategies, organizational governance at scale, and more that zoom in to specific content within each pillar + +## How to Use This Section + +There are a few methods to using this section effectively: + +- **Browse by Topic:** Pick an area relevant to your current challenge—such as planning a migration or integrating monorepos—and learn key considerations and recommended paths for success +- **Link Back to Pillars & Principles:** Each scenario includes references to the underlying pillars and design principles that inform these cross-cutting best practices +- **Leverage Scenario Overviews:** Whenever possible, we include real-world examples or user stories to illustrate how teams navigate these technical decisions in practice + +## Articles in this section + +{{< child-pages >}} diff --git a/content/library/scenarios/schema.json b/content/library/scenarios/schema.json new file mode 100644 index 0000000..c7efdce --- /dev/null +++ b/content/library/scenarios/schema.json @@ -0,0 +1,40 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + }, + "weight": { + "type": "number", + "description": "The weight of the item, used for sorting and prioritization" + }, + "icon": { + "type": "string", + "description": "The octicon associated with the item, used for visual representation" + }, + "params": { + "type": "object", + "description": "Flexible parameters that don't affect presentation (or only affect specific items)" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + }, + "publishDate": { + "type": "string", + "format": "date", + "description": "The date the item was published, used for sorting and display" + } + }, + "required": [ + "title", + "weight" + ], + "additionalProperties": true +} diff --git a/content/library/schema.json b/content/library/schema.json new file mode 100644 index 0000000..4ede514 --- /dev/null +++ b/content/library/schema.json @@ -0,0 +1,15 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "slug": { + "type": "string", + "description": "A kebab-case identifier" + } + }, + "additionalProperties": false +} diff --git a/content/schema.json b/content/schema.json new file mode 100644 index 0000000..a7a7e9a --- /dev/null +++ b/content/schema.json @@ -0,0 +1,16 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { + "type": "string", + "description": "The display name of the item" + }, + "description": { + "type": "string", + "description": "A brief description of the item" + } + }, + "required": ["title", "description"], + "additionalProperties": true +} diff --git a/docs/README.md b/docs/README.md index e9b33ab..9f2f458 100644 --- a/docs/README.md +++ b/docs/README.md @@ -11,7 +11,7 @@ Welcome to the GitHub Well-Architected Framework documentation. This directory c ## Quick Links -- [GitHub Well-Architected Framework Website](https://wellarchitected.github.com) +- [GitHub Well-Architected Framework Website](https://learn.github.com/well-architected) - [GitHub Well-Architected Repository (open source, external)](https://github.com/github/github-well-architected) - [Content Library Backlog](https://github.com/orgs/github/projects/23239/views/3) - [Contributing guide](../.github/CONTRIBUTING.md) diff --git a/docs/contributing-learn.md b/docs/contributing-learn.md new file mode 100644 index 0000000..76910c8 --- /dev/null +++ b/docs/contributing-learn.md @@ -0,0 +1,158 @@ +# Publishing Well-Architected Content to GitHub Learn + +This guide describes the requirements for publishing Well-Architected Framework content to GitHub Learn. + +To publish successfully, contributors must follow the required frontmatter, metadata, and structural guidelines outlined below. + +## Table of Contents + +- [Quick Checklist](#quick-checklist) +- [Frontmatter for all content pages](#frontmatter-for-all-content-pages) +- [Metadata for multi-page sections](#metadata-for-multi-page-sections) +- [Pull request review checklist](#pull-request-review-checklist) + +--- + +## Quick Checklist + +All content lives under `content/library/`. Before opening a PR for content review, confirm: + +- [ ] The file is in the **correct pillar** or section folder. +- [ ] **Frontmatter** satisfies the nearest `schema.json` (see [Frontmatter for all content pages](#frontmatter-for-all-content-pages)). +- [ ] If the content is part of a multi-page section, the section must include an `index.yml` and `_index.md` (see [Metadata for multi-page sections](#metadata-for-multi-page-sections)). +- [ ] Links between pages use **relative paths** (for example `./overview` or `../application-security/overview`). +- [ ] Images and downloadable assets are stored in the relevant `assets/` folder. +- [ ] File names use **kebab-case**. + +--- + +## Frontmatter for all content pages + +Every content page begins with YAML frontmatter fenced by `---`. The nearest `schema.json` in the folder determines which fields are required and their expected types. + +### Frontmatter property reference + +| Property | Type | Required | Notes | +| --- | --- | --- | --- | +| `title` | `string` | Yes in most page schemas | The library root and `overview/release-notes` schemas do not mark it as required. | +| `description` | `string` | Yes at the product root only | Optional in library page schemas. | +| `publishDate` | `string` | No | Set to the date the article is first merged to `main`. Do not change on future revisions. | +| `weight` | `number` | Yes in most page schemas | Controls page ordering within a section. | +| `draft` | `boolean` | No | Keep `false` for normal publication. Set `true` only to intentionally hide a page. | +| `prev` | `string` | No | Path to previous page, for example `library/architecture/design-principles`. | +| `next` | `string` | No | Path to next page, for example `library/architecture/checklist`. | +| `slug` | `string` | No | Optional path segment override. | +| `params.authors` | `array` | No | Array of `{ name, handle }` objects crediting significant contributors. | +| `pillars` | `array` | No | Taxonomy values that make the article discoverable. See [Taxonomies](taxonomies.md). | + +> **Info:** Extra property keys are accepted, as current schemas set `additionalProperties: true`. CI validation only checks properties declared in the nearest `schema.json`. + +### Example frontmatter for a content page + +```yaml +--- +title: 'Scaling Git repositories' +publishDate: 2025-03-10 +draft: false +weight: 4 +prev: library/architecture/recommendations/implementing-polyrepo-engineering +next: library/architecture/recommendations/deploying-actions-runner-controller + +params: + authors: + - name: 'Mona' + handle: 'mona' + - name: 'Hubot' + handle: 'hubot' + +pillars: + - architecture + - productivity +--- +``` + +--- + +## Metadata for multi-page sections + +A multi-page section is a folder under `content/library/` that groups related pages (for example, a pillar, a recommendations collection, or a multi-part guide). + +### Minimum required metadata files + +Each section folder must include, at minimum: + +| File | Purpose | +| --- | --- | +| `index.yml` | Declares section title, weight (ordering), and optional slug for navigation. | +| `_index.md` | Section landing page rendered by Hugo. Frontmatter must match the folder schema. | +| `schema.json` | Defines and validates frontmatter requirements for all pages in this folder. | + +### `index.yml` + +Defines navigation metadata for the section. Most folders require `title` and `weight`: + +```yaml +title: Recommendations +weight: 5 +slug: recommendations +``` + +### `_index.md` + +The section landing page. Its frontmatter follows the same schema rules as other pages in the folder. Typically includes a `title`, `weight`, and optional `draft` field. + +### `schema.json` + +Each folder can contain a `schema.json` that declares which frontmatter fields are required and their types. This schema is used for CI validation of all pages in the folder and its subfolders. If a page does not meet the requirements of the nearest `schema.json`, it will fail CI checks. + +Example `schema.json`: + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "type": "object", + "properties": { + "title": { "type": "string" }, + "weight": { "type": "number" }, + "draft": { "type": "boolean" } + }, + "required": ["title", "weight"], + "additionalProperties": true +} +``` + +### Example folder structure of a section + +```text +content/library/architecture/recommendations/monorepo/ +├── _index.md # Section landing page +├── index.yml # Section navigation metadata +├── schema.json # Frontmatter validation for this folder +├── overview.md # Introductory page +├── implementing-monorepo.md +├── indexing-monorepo.md +└── assets/ + └── diagram.png +``` + +### To add a new multi-page section + +1. Create the folder under the appropriate pillar in `content/library/`. +2. Add an `index.yml` file with `title` and `weight`. +3. Add a `schema.json` file defining required frontmatter. +4. Add an `_index.md` landing page. +5. Add content pages (for example, `overview.md`). +6. Link the new section from parent pages where appropriate. + +--- + +## Pull request review checklist + +Before opening a PR, confirm: + +- [ ] Page is in the correct Well-Architected section. +- [ ] Frontmatter satisfies the nearest `schema.json`. +- [ ] `index.yml` is present with correct `weight` ordering. +- [ ] Links and shortcodes render correctly after local build (`./tools/server`). +- [ ] Run `./tools/lint` with no errors. +- [ ] No unrelated files were modified. diff --git a/layouts/partials/home.html b/layouts/partials/home.html index 113faa3..0c0b9d1 100644 --- a/layouts/partials/home.html +++ b/layouts/partials/home.html @@ -19,9 +19,9 @@
- + GitHub - +
GitHub Well-Architected @@ -107,7 +107,7 @@

Deploy GitHub with confidence<
- +
Application Security
@@ -330,4 +330,4 @@

{{ .Title }} + {{ if .Page.Pages }} + {{ range .Page.Pages }} +
  • {{ .LinkTitle }}
  • + {{ end }} + {{ else }} + {{ range .Page.Parent.Pages }} + {{ if ne .RelPermalink $.Page.RelPermalink }} +
  • {{ .LinkTitle }}
  • + {{ end }} + {{ end }} {{ end }} - \ No newline at end of file + diff --git a/package.json b/package.json index 2b53a48..55a4853 100644 --- a/package.json +++ b/package.json @@ -12,8 +12,10 @@ "build": "webpack --mode production", "build:dev": "webpack --mode development", "watch": "webpack --mode development --watch", - "dev": "concurrently \"npm run watch\" \"hugo server --disableFastRender --noHTTPCache --watch --navigateToChanged\"", - "dev:ignore-cache": "concurrently \"npm run watch\" \"hugo server --ignoreCache\"" + "preprocess:content": "node src/markdown-includer/includeMarkdown.js ./content ./content-processed && node src/resolve-hugo-links/adjust-hugo-links.js ./content-processed", + "watch:markdown": "node watch-markdown.js", + "dev": "concurrently \"npm run watch\" \"npm run watch:markdown\" \"hugo server --disableFastRender --noHTTPCache --watch --navigateToChanged\"", + "dev:ignore-cache": "concurrently \"npm run watch\" \"npm run watch:markdown\" \"hugo server --ignoreCache\"" }, "repository": { "type": "git", diff --git a/src/markdown-includer/includeMarkdown.js b/src/markdown-includer/includeMarkdown.js new file mode 100644 index 0000000..93dd8ed --- /dev/null +++ b/src/markdown-includer/includeMarkdown.js @@ -0,0 +1,213 @@ +import { promises as fs } from 'fs'; +import { fileURLToPath } from 'url'; +import path from 'path'; + +/** + * Check whether the output file already exists. + */ +export async function mainMarkdownExists(mainMarkdown) { + try { + await fs.access(mainMarkdown); + return true; + } catch (err) { + if (err && err.code === 'ENOENT') { + return false; + } + throw err; + } +} + +/** + * Merge a single Markdown file into the template at outputPath. + * The template must contain relative/or/absolute/path.md. + * If sourceDir is provided, reads from source based on relative path and writes to output. + */ +export async function includeMarkdownFiles(outputPath, sourceBaseDir = null, outputBaseDir = null) { + const marker = ''; + const endMarker = ''; + + // Determine read path and output path + let readPath = outputPath; + if (sourceBaseDir && outputBaseDir) { + // Compute relative path within output directory + const relPath = path.relative(outputBaseDir, outputPath); + readPath = path.resolve(sourceBaseDir, relPath); + } + + // Only add markdown when the marker is present. If there's no + // existing file or the marker is missing, leave the file unchanged. + const exists = await mainMarkdownExists(readPath); + if (!exists) { + console.log(`File ${readPath} does not exist`); + return false; + } + + let existing = await fs.readFile(readPath, 'utf8'); + if (!existing.includes(marker)) { + console.log(`No ${marker} marker found in ${readPath}`); + return false; + } + + console.log(`Found ${marker} marker in ${readPath}`); + let current = existing; + let didMerge = false; + let searchFrom = 0; + + while (true) { + const startIndex = current.indexOf(marker, searchFrom); + if (startIndex === -1) { + break; + } + + const endIndex = current.indexOf(endMarker, startIndex + marker.length); + if (endIndex === -1) { + console.log(`No closing ${endMarker} marker found in ${readPath}`); + break; + } + + const inner = current.slice(startIndex + marker.length, endIndex).trim(); + console.log(`Inner value between ${marker} and ${endMarker} in ${readPath}: ${inner}`); + + const includePath = path.resolve(path.dirname(readPath), inner); + const includedContent = await getIncludedMarkdownContent(includePath, sourceBaseDir, outputBaseDir, readPath); + const before = current.slice(0, startIndex); + const after = current.slice(endIndex + endMarker.length); + current = `${before}${includedContent}${after}`; + didMerge = true; + searchFrom = before.length + includedContent.length; + } + + if (!didMerge) { + return false; + } + + await fs.mkdir(path.dirname(outputPath), { recursive: true }); + await fs.writeFile(outputPath, current, 'utf8'); + return true; +} + +async function getIncludedMarkdownContent(targetPath, sourceBaseDir = null, outputBaseDir = null, contextReadPath = null) { + // Adjust targetPath if we're reading from source base + let readPath = targetPath; + if (sourceBaseDir && outputBaseDir && contextReadPath) { + // The targetPath is computed from readPath (source), so we can use it as-is + readPath = targetPath; + } + + const stats = await fs.stat(readPath); + + if (stats.isFile()) { + return fs.readFile(readPath, 'utf8'); + } + + if (!stats.isDirectory()) { + return ''; + } + + const markdownFiles = (await getMarkdownFiles(readPath)).sort((left, right) => left.localeCompare(right)); + const contents = await Promise.all(markdownFiles.map((markdownFile) => fs.readFile(markdownFile, 'utf8'))); + return contents.join('\n\n'); +} + +async function getMarkdownFiles(targetPath) { + const stats = await fs.stat(targetPath); + + if (stats.isFile()) { + return path.extname(targetPath).toLowerCase() === '.md' ? [targetPath] : []; + } + + if (!stats.isDirectory()) { + return []; + } + + const entries = await fs.readdir(targetPath, { withFileTypes: true }); + const markdownFiles = []; + + for (const entry of entries) { + const fullPath = path.join(targetPath, entry.name); + + if (entry.isDirectory()) { + markdownFiles.push(...await getMarkdownFiles(fullPath)); + continue; + } + + if (entry.isFile() && path.extname(entry.name).toLowerCase() === '.md') { + markdownFiles.push(fullPath); + } + } + + return markdownFiles; +} + +export async function includeMarkdownInDirectory(sourcePath, outputPath = null) { + const sourceDir = outputPath ? sourcePath : null; + const workDir = outputPath || sourcePath; + + // Resolve to absolute paths for proper path resolution + const sourceAbsolute = path.resolve(sourceDir || workDir); + const outputAbsolute = path.resolve(workDir); + + // If outputPath is specified, copy the directory structure first + if (outputPath) { + console.log(`Copying ${sourcePath} to ${outputPath}...`); + await copyDirectory(sourcePath, outputPath); + } + + const markdownFiles = await getMarkdownFiles(workDir); + let mergedCount = 0; + + for (const markdownFile of markdownFiles) { + const didMerge = await includeMarkdownFiles(markdownFile, sourceAbsolute, outputAbsolute); + if (didMerge) { + console.log(`Merged content into ${markdownFile}`); + mergedCount += 1; + } + } + + return mergedCount; +} + +async function copyDirectory(source, dest) { + await fs.mkdir(dest, { recursive: true }); + const entries = await fs.readdir(source, { withFileTypes: true }); + + for (const entry of entries) { + const sourcePath = path.join(source, entry.name); + const destPath = path.join(dest, entry.name); + + if (entry.isDirectory()) { + await copyDirectory(sourcePath, destPath); + } else { + await fs.copyFile(sourcePath, destPath); + } + } +} + +async function main(argv) { + const args = argv.slice(2); + + if (args.length < 1) { + console.error('Usage: node includeMarkdown.js [output-path]'); + console.error(' If output-path is provided, source is copied and processed there'); + console.error(' If output-path is omitted, source is processed in-place'); + process.exit(1); + } + + // Resolve paths from current working directory before we change it + const sourcePathArg = path.resolve(args[0]); + const outputPathArg = args[1] ? path.resolve(args[1]) : null; + + try { + const mergedCount = await includeMarkdownInDirectory(sourcePathArg, outputPathArg); + console.log(`Processed ${mergedCount} markdown file(s)`); + } catch (err) { + console.error('Error merging markdown files:', err); + process.exit(1); + } +} + +const isMain = process.argv[1] === fileURLToPath(import.meta.url); + +if (isMain) { + main(process.argv); +} diff --git a/src/markdown-includer/includeMarkdown.test.js b/src/markdown-includer/includeMarkdown.test.js new file mode 100644 index 0000000..8e3d0a2 --- /dev/null +++ b/src/markdown-includer/includeMarkdown.test.js @@ -0,0 +1,179 @@ +import test from 'node:test'; +import assert from 'node:assert/strict'; +import { promises as fs } from 'fs'; +import os from 'os'; +import path from 'path'; + +import { includeMarkdownFiles, includeMarkdownInDirectory } from './includeMarkdown.js'; + +async function createTempDir() { + const prefix = path.join(os.tmpdir(), 'markdown-includer-'); + return fs.mkdtemp(prefix); +} + +async function writeFile(dir, name, content) { + const filePath = path.join(dir, name); + await fs.writeFile(filePath, content, 'utf8'); + return filePath; +} + +async function readFile(filePath) { + return fs.readFile(filePath, 'utf8'); +} + +test('mergeMarkdownFiles replaces include tag with referenced file content', async () => { + const dir = await createTempDir(); + + await writeFile(dir, 'a.md', '# Title A'); + const output = path.join(dir, 'out.md'); + + // Template with inner value pointing at the included file (relative path) + await writeFile(dir, 'out.md', 'a.md'); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, true); + + const result = await readFile(output); + assert.equal(result, '# Title A'); +}); + + +test('mergeMarkdownFiles does nothing when marker is missing', async () => { + const dir = await createTempDir(); + const output = path.join(dir, 'out.md'); + + await writeFile(dir, 'out.md', 'No markers here'); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, false); + + const result = await readFile(output); + assert.equal(result, 'No markers here'); +}); + + +test('mergeMarkdownFiles does nothing when closing tag is missing', async () => { + const dir = await createTempDir(); + const output = path.join(dir, 'out.md'); + + await writeFile(dir, 'out.md', 'a.md'); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, false); + + const result = await readFile(output); + assert.equal(result, 'a.md'); +}); + + +test('mergeMarkdownFiles replaces multiple include tags in order', async () => { + const dir = await createTempDir(); + + await writeFile(dir, 'one.md', '# One'); + await writeFile(dir, 'two.md', '# Two'); + + const output = path.join(dir, 'out.md'); + await writeFile( + dir, + 'out.md', + 'Header\n\none.md\n\nMiddle\n\ntwo.md\n\nFooter' + ); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, true); + + const result = await readFile(output); + assert.equal( + result, + 'Header\n\n# One\n\nMiddle\n\n# Two\n\nFooter' + ); +}); + + +test('includeMarkdownInDirectory recursively processes markdown files in nested folders', async () => { + const dir = await createTempDir(); + const nestedDir = path.join(dir, 'nested', 'deeper'); + await fs.mkdir(nestedDir, { recursive: true }); + + await writeFile(dir, 'shared.md', '# Shared'); + const rootOutput = await writeFile(dir, 'root.md', 'Top\nshared.md'); + const nestedOutput = await writeFile( + nestedDir, + 'nested.md', + 'Inner\n../../shared.md' + ); + const ignoredFile = await writeFile( + nestedDir, + 'notes.txt', + '../../shared.md' + ); + + const mergedCount = await includeMarkdownInDirectory(dir); + assert.equal(mergedCount, 2); + + assert.equal(await readFile(rootOutput), 'Top\n# Shared'); + assert.equal(await readFile(nestedOutput), 'Inner\n# Shared'); + assert.equal(await readFile(ignoredFile), '../../shared.md'); +}); + + +test('mergeMarkdownFiles supports absolute include paths', async () => { + const dir = await createTempDir(); + const includedFile = await writeFile(dir, 'absolute.md', '# Absolute Content'); + const output = await writeFile( + dir, + 'absolute-out.md', + `Before\n${includedFile}\nAfter` + ); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, true); + assert.equal(await readFile(output), 'Before\n# Absolute Content\nAfter'); +}); + + +test('mergeMarkdownFiles expands a directory include into markdown file contents', async () => { + const dir = await createTempDir(); + const docsDir = path.join(dir, 'docs'); + await fs.mkdir(path.join(docsDir, 'nested'), { recursive: true }); + + await writeFile(docsDir, 'b.md', '# B'); + await writeFile(docsDir, 'a.md', '# A'); + await writeFile(docsDir, 'ignore.txt', 'ignored'); + await writeFile(path.join(docsDir, 'nested'), 'c.md', '# C'); + + const output = await writeFile( + dir, + 'folder-out.md', + 'Before\ndocs\nAfter' + ); + + const didMerge = await includeMarkdownFiles(output); + assert.equal(didMerge, true); + assert.equal(await readFile(output), 'Before\n# A\n\n# B\n\n# C\nAfter'); +}); + + +test('includeMarkdownInDirectory processes a single markdown file path', async () => { + const dir = await createTempDir(); + await writeFile(dir, 'single-source.md', '# Single Source'); + const output = await writeFile( + dir, + 'single-target.md', + 'Start\nsingle-source.md' + ); + + const mergedCount = await includeMarkdownInDirectory(output); + assert.equal(mergedCount, 1); + assert.equal(await readFile(output), 'Start\n# Single Source'); +}); + + +test('includeMarkdownInDirectory ignores a non-markdown file path', async () => { + const dir = await createTempDir(); + const textFile = await writeFile(dir, 'plain.txt', 'ignored.md'); + + const mergedCount = await includeMarkdownInDirectory(textFile); + assert.equal(mergedCount, 0); + assert.equal(await readFile(textFile), 'ignored.md'); +}); diff --git a/src/markdown-includer/package.json b/src/markdown-includer/package.json new file mode 100644 index 0000000..911c560 --- /dev/null +++ b/src/markdown-includer/package.json @@ -0,0 +1,14 @@ +{ + "name": "markdown-includer", + "version": "0.0.1", + "private": true, + "type": "module", + "bin": { + "markdown-includer": "includeMarkdown.js" + }, + "scripts": { + "merge": "node includeMarkdown.js", + "markdown-includer": "node includeMarkdown.js", + "test": "node --test" + } +} diff --git a/src/markdown-includer/readme.md b/src/markdown-includer/readme.md new file mode 100644 index 0000000..77e3ce1 --- /dev/null +++ b/src/markdown-includer/readme.md @@ -0,0 +1,47 @@ +# Markdown Includer + +This utility replaces `...` tags in markdown files with the contents of the referenced markdown files. You can point the include tag at either a single markdown file or a folder. When the tag points at a folder, the tool reads all `.md` files under that folder recursively, sorts them by path, and inserts their contents separated by blank lines. + +## Run the script + +From this directory, pass a file or a folder path: + +```sh +node includeMarkdown.js ./tests +``` + +Or with the npm script: + +```sh +npm run merge -- ./tests +``` + +## Run the tests + +```sh +npm test +``` + +## Packaging + +This tool is packaged as a small Node.js CLI module. + +- The package configuration lives in [src/markdown-includer/package.json](../../../src/markdown-includer/package.json) +- It uses ESM via the `"type": "module"` setting +- The CLI command is exposed through the `bin` entry as `markdown-includer` +- The npm scripts provide shortcuts for running the merge command and the test suite + +## Example include tag + +```md +mdwithtext1.md +mdwithtext2.md +``` + +You can also include a folder: + +```md +testing3/mdmultiple +``` + +That folder include expands all markdown files in the folder tree in path-sorted order. diff --git a/src/resolve-hugo-links/adjust-hugo-links.js b/src/resolve-hugo-links/adjust-hugo-links.js new file mode 100644 index 0000000..347312b --- /dev/null +++ b/src/resolve-hugo-links/adjust-hugo-links.js @@ -0,0 +1,186 @@ +#!/usr/bin/env node + +/** + * adjust-hugo-links.js + * + * Transforms relative links in Markdown files so they resolve correctly + * when Hugo serves pages with trailing-slash URLs. + * + * Problem: + * Production serves pages WITHOUT trailing slashes (e.g. /library/overview/release-notes). + * Hugo serves pages WITH trailing slashes (e.g. /library/overview/release-notes/). + * Browsers resolve relative links from the "base directory" of the URL. + * A trailing slash means the last segment IS the directory, shifting resolution one level deeper. + * This causes every relative link to land one level too shallow on production + * (or one level too deep on Hugo, depending on perspective). + * + * Solution: + * Source Markdown (content/) has links authored for production depth. + * This script adds one "../" to every relative link in content-processed/ + * so Hugo resolves them to the correct target. + * + * Usage: + * node script/adjust-hugo-links.js + */ + +import { promises as fs } from 'fs'; +import path from 'path'; +import { fileURLToPath } from 'url'; + +const __filename = fileURLToPath(import.meta.url); + +/** + * Add one level of ../ to a relative URL. + * Returns the URL unchanged if it's absolute, external, or anchor-only. + */ +function adjustRelativeUrl(url) { + if ( + !url || + url.startsWith('/') || + url.startsWith('#') || + /^[a-z][a-z0-9+.-]*:/i.test(url) + ) { + return url; + } + + // Separate path from fragment + const hashIndex = url.indexOf('#'); + const pathPart = hashIndex >= 0 ? url.slice(0, hashIndex) : url; + const fragment = hashIndex >= 0 ? url.slice(hashIndex) : ''; + + if (!pathPart) return url; // anchor-only + + // ./foo → ../foo + if (pathPart.startsWith('./')) { + return '../' + pathPart.slice(2) + fragment; + } + + // ../foo → ../../foo (and deeper) + // bare relative → ../bare + return '../' + pathPart + fragment; +} + +/** + * Process a single line of Markdown, adjusting relative links. + * Handles both standard Markdown links and Hugo shortcode link= attributes. + */ +function adjustLinksInLine(line) { + // Skip lines that are entirely inline code or HTML comments + if (line.trimStart().startsWith('