Enterprise Deployment Toolkit

Toolkit Preview: Four Templates, Excerpted

Read the shape and the standard before you pay for the set. Four excerpts from the editable templates, as they ship.

Who buys it
The engineering manager, platform lead or security owner who has been asked to "sort out Copilot" for a team of twenty to a few hundred and has to produce documents, not opinions.
What it is for
Getting from "we should roll this out" to a pilot decision, adopted policies, a security sign-off, instruction files, an onboarding plan and a measurement framework — each a starting document rather than a blank page.
What is in it
Version 1.0.1: 23 files across six sections — planning (4), governance (5), security (3), configuration (5), rollout (3), measurement (3). Markdown and CSV; they open anywhere and diff in Git.
Licences
Individual ($149): one person adapting the templates for their organisation. Organisation ($299): anyone in one organisation may use and adapt them, including in internal documentation. Neither permits redistribution or resale, or handing them to a third party as a consulting deliverable.
Update policy
Templates are revised when GitHub changes a product fact they depend on; the changelog says what moved so you can diff your adapted copy against ours. Updates to the version you bought are included. No release cadence is promised.
What it does not provide
Legal advice. A security review of your organisation. Configuration of your GitHub organisation. Training delivery. Customer references — there are none to show. Anyone to talk to: that is Team Rollout, from $999, which includes this Toolkit.

Readiness assessment — the blocking questions and the first scored section

01-planning/readiness-assessment.md

Part 0 — Blocking questions

If any answer here is No, stop. The score below does not matter, and a pilot started now will produce a decision you cannot defend.

#QuestionYes / No
B1Do we know which repositories contain code we are contractually or legally forbidden to send to a third-party service? 
B2Does someone own the answer to "was this code AI-assisted" for audit or customer-assurance purposes? 
B3Do we have a named owner for the Copilot configuration — org settings, policies, content exclusion — who is not "whoever set it up"? 
B4If a developer pastes a secret into a chat prompt today, do we have a process that would catch it? 

B1 is the one people skip. Content exclusion is configured per repository and it is not retroactive; deciding after the pilot which repositories should have been excluded means the exclusion was not in force while they were open.

Part 1 — Scored questions

Score each: 0 no, 1 partly, 2 yes.

Engineering practice

#QuestionScore
E1Do most repositories have a test suite that runs in CI and gates merges? 
E2Is code review required before merge on the repositories in scope? 
E3Do we have a linter and formatter enforced in CI rather than by convention? 
E4Would a reviewer today notice a plausible-looking change that is subtly wrong? 

Copilot raises the volume of code arriving at review. Every one of these questions is asking whether the thing that catches mistakes scales with that. A team without E1 and E2 is not being slowed down by typing speed.

Shown: Part 0 and one of four scored sections. Not shown: the other three sections, the scoring bands and the recommendation table.

Measurement framework — what cannot be measured, and Tier 1

06-measurement/productivity-measurement-framework.md

Start with what cannot be measured

You will be asked for a percentage. "Copilot made us 30% more productive."

That number is not obtainable from the tooling, and any process that produces it is producing an artefact. Three reasons, all of which someone in the room will eventually raise:

1. There is no control group. The same team, same quarter, without the tool, does not exist. Everything else changed too — people joined, priorities moved, one service was rewritten. 2. Acceptance rate is not value. A suggestion accepted and then rewritten in review counts as accepted. So does a suggestion that was three lines of boilerplate. 3. Self-reported time saved is unreliable in a known direction. People asked whether a tool they enjoy saved them time say yes, and the estimate correlates with enjoyment rather than with output.

Saying this up front is not hedging. It is what makes the numbers you do present credible.

What to measure instead

Tier 1 — flow

MetricWhyWatch for
Time from PR open to first reviewCopilot moves work toward review. This is where it queues.Rising: review capacity is now the constraint
Time from open to mergeEnd-to-end throughputRising while PR size rises: batching, not speed
PR sizeLarger PRs review worseGrowth of more than ~25%
Deployment frequencyThe DORA metric that actually reflects flow 

Shown: the position statement and the flow metrics. Not shown: quality and people tiers, the survey design and the reporting cadence.

Acceptable use — the one-page version

02-governance/acceptable-use-policy.md

Using GitHub Copilot at [Organisation]

Yes

  • Writing code, tests, fixtures and migrations in repositories you already have access to
  • Explaining unfamiliar code, including code you did not write
  • Drafting documentation, commit messages and pull request descriptions
  • Refactoring, renaming and mechanical transformations
  • Generating example data that is genuinely synthetic

No

  • Pasting secrets, credentials, tokens or keys into a prompt — ever, including "just to check the format"
  • Pasting customer data, personal data, or anything from [the restricted list]
  • Using it against repositories on the content exclusion list at [link]
  • Committing code you have not read and cannot explain
  • Using a tool that is not on the approved list
  • Letting an agent run against production, or with production credentials

Shown: the Yes and No lists. Not shown: the judgement calls and the link points into the full policy.

30/60/90 plan — before day 1

05-rollout/30-60-90-rollout-plan.md

Before day 1

Not part of the ninety days. If these are not done, the clock has not started.

  • ☐ Pilot decision recorded and circulated
  • ☐ Policies adopted: AI-assisted development, acceptable use
  • ☐ Security review signed off (03-security/)
  • ☐ Content exclusion list configured and verified
  • ☐ Seats provisioned through the identity provider, not by hand
  • ☐ Baseline metrics captured (06-measurement/adoption-kpis.csv)
  • ☐ Support channel created and staffed
  • ☐ Instruction files written for the [5] busiest repositories

The last item matters more than it looks. The first week's impression of the tool is formed on the repositories people work in most, and an instruction file is the difference between suggestions that fit the codebase and suggestions that need rewriting.

Shown: the pre-start checklist. Not shown: the three thirty-day blocks with owners and week-by-week activities.

Before you buy

Run the free team readiness assessment first. It uses the same blocking questions as the template above, scores you into one of four stages, and names the free lessons for each gap. If it says "early stage", the lessons are the better purchase this month; the Toolkit is for the point where the documents are the bottleneck.

Choose a GitHub Copilot Enterprise Deployment Toolkit option

Checking availability…

Sign in to continue

Sign in with an email link first, so the purchase attaches to an account you can actually get back into. No password to choose.

Payment is handled by Stripe. This site never sees your card details.

You already have this.

Go to your downloads

Not on sale yet.

Payment is not switched on, so there is nothing to click. Rather than show a button that fails, this says so. The account page has a mailing-list box that covers product updates — tick it and you will hear when this opens.

The service that handles purchases is not responding right now. Everything free on this site is unaffected.

One payment, no subscription. Full contents list on the product page.