1
0
mirror of synced 2025-12-19 18:10:59 -05:00

Copilot outcome guides to support the ESSP (#55892)

Co-authored-by: Sarah Schneider <sarahs@users.noreply.github.com>
Co-authored-by: jclement136 <jclement136@github.com>
Co-authored-by: John Clement <70238417+jclement136@users.noreply.github.com>
This commit is contained in:
Isaac Brown
2025-06-30 09:25:47 +01:00
committed by GitHub
parent a991b53082
commit 78d60bae55
21 changed files with 507 additions and 19 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 237 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 149 KiB

View File

@@ -0,0 +1,26 @@
---
title: Achieving your company's engineering goals with GitHub Copilot
shortTitle: Achieve company goals
intro: 'Plan your rollout based on GitHub''s recommended approach for driving and measuring improvements.'
versions:
feature: copilot
allowTitleToDifferFromFilename: true
---
When your company rolls out a new tool such as {% data variables.product.prodname_copilot %}, you will want to measure the impact of the tool on your engineering systems and assess the tool's contribution to your company's goals.
{% data variables.product.company_short %}'s [Engineering System Success Playbook](https://resources.github.com/engineering-system-success-playbook/) (ESSP) provides strategies and metrics for driving meaningful and measurable improvements. The playbook recommends a three-step process for solving engineering challenges:
1. Identify the current barriers to success.
1. Evaluate what needs to be done to achieve your goals.
1. Implement your changes, monitor results, and adjust.
## Define your goals
Based on the recommendations of the ESSP, the following guides show how {% data variables.product.prodname_copilot %} can help you achieve your company's goals in specific areas. They explain how {% data variables.product.prodname_copilot_short %} can help, provide advice and resources for an effective rollout, and recommend metrics for assessing {% data variables.product.prodname_copilot_short %}'s impact.
We recommend defining your goals and planning your rollout accordingly. You should communicate your goals to staff and organize training to enable everyone to contribute.
* [AUTOTITLE](/copilot/tutorials/rolling-out-github-copilot-at-scale/driving-downstream-impact/increase-test-coverage)
* [AUTOTITLE](/copilot/tutorials/rolling-out-github-copilot-at-scale/driving-downstream-impact/accelerate-pull-requests)
* [AUTOTITLE](/copilot/tutorials/rolling-out-github-copilot-at-scale/driving-downstream-impact/reduce-security-debt)

View File

@@ -1,6 +1,6 @@
---
title: Choosing your enterprise's plan for GitHub Copilot
shortTitle: Choose your plan
shortTitle: Choose enterprise plan
intro: 'Choose between {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}.'
versions:
feature: copilot
@@ -10,6 +10,7 @@ permissions: Enterprise owners and billing managers
redirect_from:
- /copilot/rolling-out-github-copilot-at-scale/choosing-your-enterprises-plan-for-github-copilot
- /copilot/rolling-out-github-copilot-at-scale/planning-your-rollout/choosing-your-enterprises-plan-for-github-copilot
- /copilot/tutorials/rolling-out-github-copilot-at-scale/planning-your-rollout/choosing-your-enterprises-plan-for-github-copilot
---
When you adopt {% data variables.product.prodname_copilot %} in a company, you will sign up to a {% data variables.product.prodname_copilot_short %} plan designed for businesses. These plans allow you to:
@@ -40,6 +41,12 @@ When you subscribe your enterprise account to {% data variables.copilot.copilot_
* Evaluate the benefits of {% data variables.copilot.copilot_enterprise_short %} for a smaller group of users before rolling it out further.
* Enable {% data variables.copilot.copilot_enterprise_short %} in the organizations where it will have the most impact, such as organizations with complex documentation or specialized engineering requirements.
## What are our goals for {% data variables.product.prodname_copilot_short %}?
To drive and measure downstream impact of {% data variables.product.prodname_copilot_short %}, {% data variables.product.company_short %} recommends leading your rollout with specific engineering goals in mind. Your requirements for {% data variables.product.prodname_copilot_short %} features will depend on your overall goal for the rollout.
For examples of how {% data variables.product.prodname_copilot_short %} can help with common problems in engineering teams, see [AUTOTITLE](/copilot/get-started/achieve-engineering-goals).
## Do we have projects with complex requirements?
For complex projects like monorepos or legacy codebases, developers in your company may need to spend a long time finding and reading documentation before they can contribute.
@@ -71,6 +78,7 @@ To summarize:
* Choose {% data variables.copilot.copilot_enterprise_short %} if your company has projects with complex requirements or large amounts of documentation. Knowledge bases give {% data variables.product.prodname_copilot_short %} enhanced context, which can save developers time and allow them to focus on tasks they enjoy.
* If you think your developers will benefit from premium models and {% data variables.product.prodname_copilot_short %} code reviews, it may be cost effective to choose {% data variables.copilot.copilot_enterprise_short %} rather than pay for premium requests over your allowance.
* If you're not sure about a full rollout, choose {% data variables.copilot.copilot_enterprise_short %} at the enterprise level and enable it for individual organizations where it will have the most impact.
* Make your decision based on your downstream goals for the {% data variables.product.prodname_copilot_short %} rollout.
## Further reading

View File

@@ -12,6 +12,8 @@ children:
- /plans-for-github-copilot
- /github-copilot-features
- /best-practices-for-using-github-copilot
- /choosing-your-enterprises-plan-for-github-copilot
- /achieve-engineering-goals
redirect_from:
- /copilot/about-github-copilot
---

View File

@@ -1,6 +1,6 @@
---
title: Assigning GitHub Copilot licenses in your enterprise
shortTitle: Assigning licenses
shortTitle: Assign licenses
intro: Learn recommended practices for assigning licenses and managing costs.
versions:
feature: copilot

View File

@@ -0,0 +1,163 @@
---
title: Accelerating pull requests in your company with GitHub Copilot
shortTitle: Accelerate pull requests
intro: 'Understand features, enable developers, and measure Copilot''s impact.'
versions:
feature: copilot
product: '{% data variables.copilot.copilot_for_business %} or {% data variables.copilot.copilot_enterprise %}'
allowTitleToDifferFromFilename: true
---
{% data reusables.copilot.essp-intro %}
## 1. Identify barriers to success
{% data reusables.copilot.identify-barriers-intro %}
Teams often experience delays in merging pull requests due to lengthy review cycles. These delays often stem from:
* Complex code changes that are difficult to understand
* Inconsistent code formatting that makes reviews challenging
* A general lack of context provided with the changes
* Social factors that contribute to slow or hard-to-address reviews
Reviewers can also easily miss small errors that may lead to production issues.
This leads to bottlenecks in the development process and slows down the overall delivery and quality of features.
## 2. Evaluate your options
{% data reusables.copilot.evaluate-options-intro %}
<a href="https://github.com/github-copilot/purchase?ref_cta=Copilot+Enterprise+trial&ref_cta=Copilot+Business+trial&ref_loc=accelerate-pull-requests" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Sign up for {% data variables.product.prodname_copilot_short %}</span> {% octicon "link-external" height:16 aria-label="link-external" %}</a>
### How {% data variables.product.prodname_copilot_short %} can help
{% data variables.product.prodname_copilot %} offers a suite of features designed to accelerate the pull request review process, enhance code quality, and improve collaboration, ultimately leading to faster merge times.
By leveraging {% data variables.product.prodname_copilot_short %}'s capabilities, teams can streamline their workflows, reduce friction, and ensure consistent, high-quality code.
#### Generates complete and helpful PR summaries
{% data variables.product.prodname_copilot_short %} can automatically generate clear and concise PR summaries, saving developers time and ensuring that the purpose and changes of the PR are easily understood by reviewers. This reduces the likelihood of misunderstandings and speeds up the review process.
#### Assists reviewers during their review process
{% data variables.product.prodname_copilot %} can be used as a powerful PR review companion.
* {% data variables.product.prodname_copilot_short %} can help explain complex code changes so that reviewers more quickly understand what the PR is contributing.
* {% data variables.product.prodname_copilot_short %} can provide repository-wide, context-aware suggestions and potential code improvements directly within the pull request review interface on {% data variables.product.github %}, helping reviewers catch potential issues and offer constructive feedback more efficiently.
* {% data variables.product.prodname_copilot_short %} can help reviewers draft and write clear, consistent, and effective review comments.
#### Reviews based on organization guidelines
* {% data variables.product.prodname_copilot_short %} can review code changes in your IDE before opening a pull request, or be assigned as reviewer to a pull request.
* With rulesets, you can set up {% data variables.product.prodname_copilot_short %} to systematically review pull requests based on custom criteria.
* With coding guidelines for reviews ({% data variables.copilot.copilot_enterprise_short %} only), {% data variables.product.prodname_copilot_short %} can enforce organizational coding standards and best practices, automatically flagging potential violations and suggesting fixes.
These features ensure consistency across the codebase and help you catch errors early in the development process, reducing the need for manual code reviews and saving time for developers and reviewers.
#### Suggests code fixes
Based on a pull request review comment, {% data variables.product.prodname_copilot_short %} can help pull request authors quickly implement the required code changes to resolve the review.
### Cultural considerations
{% data reusables.copilot.cultural-factors-intro %}
* Teams might **wait too long to release**, deploying large batches of code at once. This could be caused by a fear of destabilization with frequent releases, a lack of CI/CD pipeline maturity, or strict compliance requirements.
* Developers might **spend too long perfecting code** or adding unnecessary features. This could be caused by a culture of perfectionism or a lack of effective prioritization.
* Developers might **build overly complex solutions** for simple problems. This could be caused by a desire to future-proof unnecessarily, or pressure to add value through complexity.
## 3. Implement changes
{% data reusables.copilot.implement-changes-intro %}
* [Create helpful pull request summaries](#create-helpful-pull-request-summaries)
* [Use {% data variables.product.prodname_copilot_short %} as a review assistant](#use-copilot-as-a-review-assistant)
* [Add {% data variables.product.prodname_copilot_short %} as a reviewer](#add-copilot-as-a-reviewer)
* [Get help implementing review comments](#get-help-implementing-review-comments)
* [Best practices for developers](#best-practices-for-developers)
* [Resources](#resources)
### Create helpful pull request summaries
1. When creating a pull request, click the {% data variables.product.prodname_copilot_short %} icon in the "Add a description" field, then click **Summary**.
1. {% data variables.product.prodname_copilot_short %} will scan through the pull request and provide an overview of the changes made in prose, as well as a bulleted list of changes with the files that they impact.
1. Check you're happy with {% data variables.product.prodname_copilot_short %}'s description.
1. When reviewers come to your pull request, they'll have all the context they need to leave a review.
### Use {% data variables.product.prodname_copilot_short %} as a review assistant
When jumping into a pull request as a reviewer, you can use {% data variables.product.prodname_copilot_short %} to speed up your review.
1. Use {% data variables.product.prodname_copilot_short %} to **understand the changes in the pull request**.
* Ask {% data variables.product.prodname_copilot_short %} to summarize the changes made to a file, particularly helpful for longer diffs. You can pick a specific file from the diff by clicking {% octicon "kebab-horizontal" aria-label="Show options" %} on the top-right corner of the file.
![Screenshot of a pull request "files changed" tab. The "Ask {% data variables.product.prodname_copilot_short %} about this diff" option is highlighted in red.](/assets/images/help/copilot/ask-to-explain.png)
* For changes in specific lines, highlight the lines you want to better understand and ask {% data variables.product.prodname_copilot_short %} to explain the changes to you. You can highlight a set of lines by clicking on the uppermost line number first, holding your SHIFT key, and then clicking on the lowermost line of the diff.
![Screenshot of a pull request "files changed" tab. A selection of lines is highlighted and an "Explain" option is displayed in a dropdown.](/assets/images/help/copilot/highlight-lines.png)
1. **Collaborate on your PR review** with {% data variables.product.prodname_copilot_short %}. Don't forget to attach the specific file diffs to the conversation before prompting {% data variables.product.prodname_copilot_short %}.
* You can ask {% data variables.product.prodname_copilot_short %} for its own opinion on the PR changes by asking: `Provide your judgement as a PR Reviewer, both for functional and non-functional aspects that these changes bring`. Note how this prompt asks {% data variables.product.prodname_copilot_short %} to consider both functional and non-functional aspects of the code.
* For your own PR review comments, ask {% data variables.product.prodname_copilot_short %} for a second opinion: `As my peer reviewer on this pull request, give me your feedback on my own review: YOUR-REVIEW-COMMENT. Do you think it's pertinent? Am I missing something?`
1. Collaborate with {% data variables.product.prodname_copilot_short %} to **draft and refine your review comments**.
* After planning the review with {% data variables.product.prodname_copilot_short %}, you can ask to list the comments that you should provide: `Make a list of review comments to add to the PR and tell me exactly in which file diff and lines each comment should be added`.
* You can also ask {% data variables.product.prodname_copilot_short %} to create a first draft of a review comment you have in mind or refine a comment before you post it: `Help me draft review comments as discussed` or `Refine this review comment to make it clear, concise, and actionable`.
### Add {% data variables.product.prodname_copilot_short %} as a reviewer
To reduce review times and merge pull requests faster, use {% data variables.product.prodname_copilot_short %} code reviews systematically: first in the IDE before opening the pull request, then on the PR in {% data variables.product.github %}.
Using {% data variables.product.prodname_copilot_short %} code review does not replace the need for human code review. However, following the steps above can help humans complete their reviews faster.
* **Developers** should request a review of all their changes using {% data variables.product.prodname_copilot_short %} code review before opening a pull request.
* **Administrators** should set up repository or organization rulesets to automatically add {% data variables.product.prodname_copilot_short %} as a reviewer on any pull request targeting protected branches.
* **Team leads** should capture their team's standard style and rules and set them as coding guidelines for the organization so that {% data variables.product.prodname_copilot_short %} can leverage them in reviews.
* Ensure your coding guidelines capture a minimum set of styling recommendations that make code more readable, which will help during the pull request review process.
* To reduce the amount of PR review comments due to styling issues, set the same recommendations in {% data variables.product.prodname_copilot_short %} instructions at the repository and organization level. This way, the code generated by {% data variables.product.prodname_copilot_short %} will conform to these guidelines.
### Get help implementing review comments
Pull request authors can speed up resolution of PR review comments by quickly implementing fixes with {% data variables.product.prodname_copilot_short %}'s assistance.
* For any review comments left by {% data variables.product.prodname_copilot_short %} itself, either commit the proposed fix directly, or edit it in Copilot Workspace before committing.
* For any review comments left by peers, navigate to the file diff related to the PR review comment and attach the diff to a {% data variables.copilot.copilot_chat_short %} conversation. Then, copy paste the review comment with a prompt like this: `Suggest a fix for this review comment:`
* If you are using VS Code, ask {% data variables.product.prodname_copilot %} in agent mode to implement the required changes from the review comment.
### Best practices for developers
Developers **should**:
* Request {% data variables.product.prodname_copilot_short %}'s review in your IDE before pushing to catch and resolve issues early.
* Use {% data variables.product.prodname_copilot_short %} to plan and refine your own PR review comments to help PR authors understand and resolve issues.
* Attach relevant diff context, including specific lines of code, to your conversations with {% data variables.product.prodname_copilot_short %}.
Developers **should not**:
* Apply {% data variables.product.prodname_copilot_short %}'s suggestions without testing.
* Rely solely on {% data variables.product.prodname_copilot_short %} for reviews.
* Neglect code readability.
### Resources
* [AUTOTITLE](/copilot/using-github-copilot/using-github-copilot-for-pull-requests/creating-a-pull-request-summary-with-github-copilot)
* [AUTOTITLE](/copilot/using-github-copilot/code-review/using-copilot-code-review?tool=vscode#reviewing-changes)
* [AUTOTITLE](/copilot/using-github-copilot/code-review/configuring-coding-guidelines)
* [AUTOTITLE](/copilot/using-github-copilot/code-review/configuring-automatic-code-review-by-copilot)
* [AUTOTITLE](/copilot/customizing-copilot/adding-organization-custom-instructions-for-github-copilot)
## Metrics to watch
{% data reusables.copilot.measure-changes-intro %}
* **Developer satisfaction**: Use developer surveys to measure satisfaction with engineering tooling.
* **Pull requests merged per developer**: You can use GitHub's `pull request` webhook, ensuring `action` is `closed` and the `merged` property inside `pull request` object is `true`.
* **Pull requests lead time**: Measure the average length of time between PR creation and merge.

View File

@@ -0,0 +1,140 @@
---
title: Increasing test coverage in your company with GitHub Copilot
shortTitle: Increase test coverage
intro: 'Understand features, enable developers, and measure Copilot''s impact.'
versions:
feature: copilot
product: '{% data variables.copilot.copilot_for_business %} or {% data variables.copilot.copilot_enterprise %}'
allowTitleToDifferFromFilename: true
---
{% data reusables.copilot.essp-intro %}
## 1. Identify barriers to success
{% data reusables.copilot.identify-barriers-intro %}
Many software teams face persistent challenges in maintaining high-quality code due to low unit test coverage. In fast-paced development environments, writing tests is often seen as time-consuming or non-essential, especially when teams are under pressure to deliver features quickly.
As a result, critical bugs can be discovered late in the development lifecycle, often in staging or production environments.
This leads to a chain of negative outcomes:
* **Higher bug rates** and customer-reported issues
* **Increased cost** of fixing bugs after deployment
* **Reduced developer confidence** in the stability of their code
* **Slower release cycles** due to reactive debugging and patching
In legacy systems, test coverage can be even harder to address because of complex dependencies or poorly documented code. Developers may lack familiarity with older codebases or with testing frameworks in general, further compounding the problem.
Improving test coverage is a recognized best practice, but it requires time and expertise that many teams struggle to allocate.
## 2. Evaluate your options
{% data reusables.copilot.evaluate-options-intro %}
<a href="https://github.com/github-copilot/purchase?ref_cta=Copilot+Enterprise+trial&ref_cta=Copilot+Business+trial&ref_loc=increase-test-coverage" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Sign up for {% data variables.product.prodname_copilot_short %}</span> {% octicon "link-external" height:16 aria-label="link-external" %}</a>
### How {% data variables.product.prodname_copilot_short %} can help
{% data variables.product.prodname_copilot %} can significantly accelerate and simplify the process of writing unit tests. By understanding the surrounding code and context, {% data variables.product.prodname_copilot_short %} can suggest test functions that match the structure and logic of the code being tested.
{% data variables.product.prodname_copilot_short %}'s capabilities are useful across multiple scenarios:
* As developers write new functions, {% data variables.product.prodname_copilot_short %} can automatically suggest corresponding test cases inline.
* When refactoring legacy code, {% data variables.product.prodname_copilot_short %} can help generate test scaffolding to prevent regressions.
* For untested modules, developers can prompt {% data variables.product.prodname_copilot_short %} to generate meaningful test cases, even when test coverage is missing or inconsistent.
By making unit testing easier, faster, and less manual, {% data variables.product.prodname_copilot_short %} reduces the friction that can lead to gaps in test coverage, and helps teams adopt a quality-first mindset.
#### Use cases
* **Inline test generation**: Developers can ask {% data variables.product.prodname_copilot_short %} to generate tests for a specific function or module without switching context.
* **Better edge case coverage**: By prompting {% data variables.product.prodname_copilot_short %} for edge scenarios (such as null inputs, empty lists, or invalid states), developers can quickly cover more branches of logic.
* **Accelerated onboarding**: New team members can use {% data variables.product.prodname_copilot_short %} to understand how a function is expected to behave by looking at the generated test cases.
* **Assistance with CI/CD**: {% data variables.product.prodname_copilot_short %} can suggest how to integrate tests into your build pipeline, ensuring that coverage improvements directly support quality gates.
### Cultural considerations
{% data reusables.copilot.cultural-factors-intro %}
* Teams might **rely on manual testing** or insufficient automated testing. This could be caused by resource constraints for automation or a lack of experience with modern test tools.
* Teams might **wait too long to release**, deploying large batches of code at once, which makes bugs and regressions harder to detect. This could be caused by a lack of CI/CD pipeline maturity, strict compliance requirements, or long review cycles between PR and deployment.
## 3. Implement changes
{% data reusables.copilot.implement-changes-intro %}
* [Generate tests inline](#generate-tests-inline)
* [Cover edge cases](#cover-edge-cases)
* [Understand new code](#understand-new-code)
* [Get assistance with CI/CD](#get-assistance-with-cicd)
* [Best practices for developers](#best-practices-for-developers)
* [Resources for developers](#resources-for-developers)
* [Recommended features](#recommended-features)
### Generate tests inline
1. In VS Code, select the function you want to test and prompt {% data variables.product.prodname_copilot_short %}: `Generate a unit test for this code.`
1. {% data variables.product.prodname_copilot_short %} generates a test inline or in a separate test file, depending on the language and structure.
1. Review, refine, and accept the suggestion.
### Cover edge cases
1. After writing a test, ask {% data variables.product.prodname_copilot_short %}: `What are some edge cases I should test for this function?`
Or: `Write test cases for when the input is null or empty.`
1. {% data variables.product.prodname_copilot_short %} suggests additional test cases to cover boundary conditions.
1. Review the tests and incorporate them into your test suite.
### Understand new code
1. Select a legacy function and ask {% data variables.product.prodname_copilot_short %}: `Explain what this function does and generate a test to validate it.`
1. {% data variables.product.prodname_copilot_short %} explains the function's purpose and suggests corresponding test cases.
1. Look at the test cases to understand the expected behavior and quickly build context.
### Get assistance with CI/CD
1. Review your test cases and commit them to the codebase.
1. Ask {% data variables.product.prodname_copilot_short %}: `Where should I place this test if I want it to run in CI?`
1. Based on the structure of the codebase, {% data variables.product.prodname_copilot_short %} will suggest where to place test files and how to update pipeline configurations.
### Best practices for developers
Developers **should**:
* Use descriptive comments or prompts when chatting with {% data variables.product.prodname_copilot_short %}. For example: `Generate unit tests for a function that calculates discounts based on user type and purchase amount.`
* Use {% data variables.product.prodname_copilot_short %} to explore logic coverage. For example: `What branches or conditions does this function have that should be tested?`
* Explore different prompt techniques and compare results from different AI models.
Developers **should not**:
* Accept generated tests without reviewing logic. Make sure the tests reflect actual requirements and handle realistic inputs and outputs.
* Skip asserting edge behavior. If you only test "happy paths," you risk missing regressions.
* Rely on {% data variables.product.prodname_copilot_short %} to guess undocumented business rules. Always provide context through prompts or comments.
* Treat {% data variables.product.prodname_copilot_short %} as a substitute for human code reviews. {% data variables.product.prodname_copilot_short %} accelerates the process, but you still need to apply engineering judgment.
### Resources for developers
* [AUTOTITLE](/copilot/using-github-copilot/guides-on-using-github-copilot/writing-tests-with-github-copilot)
* [How to generate unit tests with {% data variables.product.prodname_copilot %}: Tips and examples](https://github.blog/ai-and-ml/github-copilot/how-to-generate-unit-tests-with-github-copilot-tips-and-examples/)
* [{% data variables.product.prodname_copilot %} is EVERYWHERE in Visual Studio](https://learn.microsoft.com/en-us/shows/github-copilot-for-visual-studio/github-copilot-is-everywhere-in-visual-studio-miniseries) (video content with a section on testing)
* [AUTOTITLE](/copilot/using-github-copilot/copilot-chat/prompt-engineering-for-copilot-chat)
* [AUTOTITLE](/copilot/using-github-copilot/ai-models/changing-the-ai-model-for-copilot-chat)
### Recommended features
* [{% data variables.copilot.copilot_chat_dotcom_short %}](/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-github)
* [{% data variables.product.prodname_copilot_short %} code completion](/copilot/using-github-copilot/getting-code-suggestions-in-your-ide-with-github-copilot)
* [{% data variables.copilot.copilot_chat_short %} in the IDE](/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-your-ide)
* [{% data variables.copilot.copilot_coding_agent %}](/copilot/using-github-copilot/coding-agent/about-assigning-tasks-to-copilot)
## Metrics to watch
{% data reusables.copilot.measure-changes-intro %}
* **Test coverage**: Track increases in line and branch coverage after {% data variables.product.prodname_copilot_short %} adoption. If possible, look at test coverage reports from your CI pipelines.
* **Bug rate after deployment**: Fewer bugs should be reported in production environments.
* **Developer confidence**: Use surveys or retrospectives to assess how confident developers feel shipping new code.
* **Time to write tests**: Measure reduction in time spent creating unit tests.

View File

@@ -0,0 +1,14 @@
---
title: Driving the downstream impact of GitHub Copilot
shortTitle: Drive downstream impact
intro: Plan your rollout to achieve engineering goals and measure success.
versions:
feature: copilot
topics:
- Copilot
children:
- /increase-test-coverage
- /accelerate-pull-requests
- /reduce-security-debt
---

View File

@@ -0,0 +1,130 @@
---
title: Reducing security debt in your company with GitHub Copilot
shortTitle: Reduce security debt
intro: 'Understand features, enable developers, and measure {% data variables.product.prodname_copilot_short %}''s impact.'
versions:
feature: copilot
product: '{% data variables.copilot.copilot_for_business %} or {% data variables.copilot.copilot_enterprise %}'
allowTitleToDifferFromFilename: true
---
{% data reusables.copilot.essp-intro %}
## 1. Identify barriers to success
{% data reusables.copilot.identify-barriers-intro %}
As development teams works to deliver new features and keep their applications running smoothly, their focus is often on speed and functionality. However, over time, small issues can accumulate, such as:
* Known security weaknesses that haven't been fixed
* Reliance on older software components with potential flaws
* Delays in addressing problems when they are discovered
For many organizations, this accumulation of unresolved security issues and outdated components creates a significant backlog—a **security debt**.
This debt carries real risks. The longer it goes unaddressed, the larger it can grow and the more costly it becomes to resolve. A large security debt can leave systems vulnerable to attacks, expose sensitive data, and ultimately erode customer trust and impact the bottom line.
The challenge is to balance the need for rapid development with the crucial responsibility of maintaining a secure and stable software environment.
## 2. Evaluate your options
{% data reusables.copilot.evaluate-options-intro %}
<a href="https://github.com/github-copilot/purchase?ref_cta=Copilot+Enterprise+trial&ref_cta=Copilot+Business+trial&ref_loc=reduce-security-debt" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Sign up for {% data variables.product.prodname_copilot_short %}</span> {% octicon "link-external" height:16 aria-label="link-external" %}</a>
### How {% data variables.product.prodname_copilot_short %} can help
{% data variables.product.prodname_copilot %} can help mitigate security debt by integrating security considerations directly into the development lifecycle. Its capabilities can make it easier for developers to proactively identify and address potential vulnerabilities and keep their projects up-to-date.
{% data variables.product.prodname_copilot_short %} can help reduce security vulnerabilities throughout the software development lifecycle.
#### During development
{% data variables.product.prodname_copilot_short %} proactively reviews code as it's written, leveraging its understanding of common security flaws and patterns to flag areas that might be susceptible to exploitation. This real-time analysis can surface hidden vulnerabilities that might otherwise be missed during standard development or initial security reviews.
When issues are identified, {% data variables.product.prodname_copilot_short %} can instantly suggest actionable code changes to remediate vulnerabilities, empowering developers to address weaknesses early in the development cycle and prevent security debt from accumulating.
#### Ongoing maintenance
{% data variables.product.prodname_copilot_short %} integrates with {% data variables.product.github %}'a code scanning capabilities to keep your existing codebase secure. When code scanning identifies a potential security alert, {% data variables.copilot.copilot_autofix_short %} can intelligently analyze the vulnerability and provide targeted, context-specific recommendations to resolve it.
These concrete fix suggestions streamline remediation, reducing the time developers spend researching vulnerabilities and figuring out how to address them. As a result, security alerts are resolved more efficiently and are less likely to linger or contribute to ongoing security debt.
### Cultural considerations
{% data reusables.copilot.cultural-factors-intro %}
* Teams might **ignore or defer security debt**, allowing inefficient and vulnerable systems to persist. This could be caused by a deadline-driven focus on features, or a lack of education about the long-term impact of security debt.
* Teams might **build overly complex solutions** for simple problems, which makes code harder to maintain and security issues harder to detect. This could be caused by a desire to future-proof
unnecessarily or pressure to add value through complexity.
## 3. Implement changes
{% data reusables.copilot.implement-changes-intro %}
* [Analyze your code for security vulnerabilities](#analyze-your-code-for-security-vulnerabilities)
* [Use {% data variables.copilot.copilot_autofix_short %} for {% data variables.product.prodname_code_scanning %} alerts](#use-copilot-autofix-for-code-scanning-alerts)
* [Best practices for developers](#best-practices-for-developers)
* [Resources for developers](#resources-for-developers)
### Analyze your code for security vulnerabilities
Depending on the size of your codebase, {% data variables.product.prodname_copilot_short %} may not be able to analyze the entire project while developers are writing code, due to context restraints. However, developers can adopt a practice of asking {% data variables.product.prodname_copilot_short %} to analyze specific files for insecure code practices.
1. Open the files to analyze in {% data variables.product.prodname_vscode %}.
1. In {% data variables.copilot.copilot_chat_short %}, ask: `Analyze this code for potential security vulnerabilities and suggest fixes`
You can also use the `#file` chat variable to specifically include a file's content in the prompt, or use prompt files and custom instructions to guide {% data variables.product.prodname_copilot_short %}'s responses.
1. {% data variables.copilot.copilot_chat_short %} will analyze the code, identify the security vulnerabilities, and suggest the appropriate fixes.
1. Review the suggested changes and apply them as appropriate.
Other examples of prompts include:
* `Are there any security vulnerabilities in my code? If so, can you explain them and suggest fixes?`
* `Does this code follow secure code best practices? If not, what specific improvements can I make?`
* `What are the potential security risks in this code if it were deployed to production? How can I mitigate them?`
### Use {% data variables.copilot.copilot_autofix_short %} for {% data variables.product.prodname_code_scanning %} alerts
{% data variables.copilot.copilot_autofix_short %} is a component of {% data variables.product.prodname_GH_code_security %} that can suggest potential fixes to {% data variables.product.prodname_code_scanning %} alerts. {% data variables.copilot.copilot_autofix_short %} is available in public repositories and repositories with a license for {% data variables.product.prodname_GH_code_security %}.
When someone runs a code scan on a repository, potential issues are raised as {% data variables.product.prodname_code_scanning %} alerts in the repository. Developers can resolve the alerts by following this flow:
1. Open an alert on GitHub.
1. Click **Generate fix**, which is displayed if Copilot can resolve the alert.
1. {% data variables.copilot.copilot_autofix_short %} will generate a potential fix for this alert, showing you the code changes in the alert itself. It then gives you the option to commit this code change to a new branch or an existing branch.
1. At this point you can test the code, then open a pull request to move the changes to the main branch.
1. Once you move the changes to the main branch and {% data variables.product.prodname_code_scanning %} verifies the alert is fixed, the alert will be closed automatically.
### Best practices for developers
Developers **should**:
* **Use {% data variables.copilot.copilot_chat_short %} regularly to analyze code snippets for vulnerabilities**: Make it a habit to proactively check code for security issues before committing changes.
* **Leverage {% data variables.copilot.copilot_autofix_short %} for {% data variables.product.prodname_code_scanning %} alerts**: When alerts appear, use {% data variables.copilot.copilot_autofix_short %} as a first step to quickly address them.
* **Provide clear and specific prompts to {% data variables.copilot.copilot_chat_short %}**: The more detailed your request, the better {% data variables.product.prodname_copilot_short %} can analyze the code and suggest relevant fixes. For example, include the programming language and specific areas of concern in your prompts.
* **Combine {% data variables.product.prodname_copilot_short %} with existing security tools**: Use {% data variables.product.prodname_copilot_short %} as an additional layer of security analysis, not as a replacement for dedicated security scanners and practices.
Developers **should not**:
* **Automatically accept {% data variables.product.prodname_copilot_short %}'s security suggestions**: Always review and test the code changes suggested by {% data variables.product.prodname_copilot_short %} to ensure they are appropriate and effective.
* **Rely solely on {% data variables.product.prodname_copilot_short %} for comprehensive security audits**: {% data variables.product.prodname_copilot_short %} is a helpful tool, but it should not replace thorough security reviews and penetration testing.
* **Ignore {% data variables.product.prodname_code_scanning %} alerts**: Address all alerts promptly, even if they seem minor, to prevent the accumulation of security debt.
* **Use {% data variables.product.prodname_copilot_short %} as an excuse to avoid learning secure coding practices**: Continue to educate yourself and your team on security best practices.
* **Assume {% data variables.product.prodname_copilot_short %} will catch every vulnerability**: Security is an ongoing process, and vigilance is always necessary.
* **Use {% data variables.product.prodname_copilot_short %} to bypass security policies**: Adhere to your organization's security protocols, and use {% data variables.product.prodname_copilot_short %} as a tool to enhance them, not circumvent them.
### Resources for developers
* [{% data variables.copilot.copilot_chat_dotcom_short %}](/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-github)
* [AUTOTITLE](/copilot/copilot-chat-cookbook/security-analysis/finding-existing-vulnerabilities-in-code)
* [{% data variables.product.prodname_learning %} - Getting Started with {% data variables.product.prodname_copilot %}](https://github.com/skills/getting-started-with-github-copilot)
## Metrics to watch
{% data reusables.copilot.measure-changes-intro %}
* **Security debt ratio**: Use security overview to see if the number of alerts falls over time.
* **Time to remediate security issues**: Use security overview to see if the time to remediate security issues falls over time.
See [AUTOTITLE](/code-security/security-overview/assessing-code-security-risk).

View File

@@ -50,6 +50,8 @@ For more complex issues, you may also choose to designate an internal point of c
This section offers examples of how you can support effective use of {% data variables.product.prodname_copilot_short %}. You can use these examples as a starting point and adapt them to meet your organization's needs and goals.
To drive and measure downstream impact of {% data variables.product.prodname_copilot_short %}, {% data variables.product.company_short %} recommends leading your rollout with specific engineering goals in mind. You should communicate your goals to staff and organize training accordingly. See [AUTOTITLE](/copilot/get-started/achieve-engineering-goals).
### Creating onboarding resources
You may choose to create internal onboarding materials to help teams get started with {% data variables.product.prodname_copilot_short %}. These materials could include your organization's policies and guidelines for using {% data variables.product.prodname_copilot_short %}, {% data variables.product.github %} documentation, relevant {% data variables.product.github %} blog posts, and any other resources that you think will be helpful.

View File

@@ -1,6 +1,6 @@
---
title: Enabling developers to use GitHub Copilot
shortTitle: Enabling developers
shortTitle: Enable developers
intro: Boost productivity by encouraging developers to make the most of Copilot features.
versions:
feature: copilot

View File

@@ -7,11 +7,12 @@ versions:
topics:
- Copilot
children:
- /planning-your-rollout
- /assigning-licenses
- /enabling-developers
- /measuring-adoption
- /driving-downstream-impact
redirect_from:
- /copilot/rolling-out-github-copilot-at-scale
- /copilot/tutorials/rolling-out-github-copilot-at-scale/planning-your-rollout
---

View File

@@ -1,6 +1,6 @@
---
title: Measuring adoption and usage of GitHub Copilot
shortTitle: Measuring adoption
shortTitle: Measure adoption
intro: Assess your onboarding process by tracking how developers are using Copilot.
versions:
feature: copilot

View File

@@ -1,14 +0,0 @@
---
title: Planning a rollout of GitHub Copilot
shortTitle: Planning your rollout
intro: Choose a plan and set goals for your rollout.
versions:
feature: copilot
topics:
- Copilot
children:
- /choosing-your-enterprises-plan-for-github-copilot
redirect_from:
- /copilot/rolling-out-github-copilot-at-scale/planning-your-rollout
---

View File

@@ -0,0 +1,3 @@
Alongside your rollout of {% data variables.product.prodname_copilot %}, you should also address any social or cultural factors that could prevent you from achieving your goals.
The following examples are drawn from the "Anti-Patterns" section in the ESSP.

View File

@@ -0,0 +1,3 @@
The guide is inspired by {% data variables.product.company_short %}'s [Engineering System Success Playbook](https://resources.github.com/engineering-system-success-playbook/) (ESSP), which recommends strategies and metrics for driving improvements in engineering systems.
If you're starting a rollout of {% data variables.product.prodname_copilot_short %}, we recommend defining your goals, planning your rollout accordingly, and communicating the goals clearly to staff. See [AUTOTITLE](/copilot/get-started/achieve-engineering-goals).

View File

@@ -0,0 +1,3 @@
The next step is to evaluate and agree on solutions to address the barriers you identified in step one. In this guide, we'll focus on the impact {% data variables.product.prodname_copilot %} can have on the goal you've identified. Bear in mind that successful rollouts of a new tool also require changes to culture and processes.
You will run trials of new tools and processes with pilot groups to gather feedback and measure success. For training resources and metrics to use during trials, you can look ahead at the [3. Implement changes](#3-implement-changes) and [Metrics to watch](#metrics-to-watch) sections.

View File

@@ -0,0 +1 @@
The first step recommended by the ESSP is to develop a clear understanding of the obstacles preventing improvements in your company. By understanding your current baseline, your desired future state, and the barriers preventing you from making progress, you can ensure changes are targeted and effective.

View File

@@ -0,0 +1,3 @@
When you've identified the right approach to overcome your barriers, you will scale the solutions you identified. For a successful rollout of a new tool or process, it's important to assign ownership to each part of the rollout, communicate transparently about your goals, provide effective training, and measure your outcomes.
This section provides example scenarios, best practices, and resources for developers. We recommend using this section to **plan communications and training sessions** to help employees use {% data variables.product.prodname_copilot_short %} in a way that aligns with your goal.

View File

@@ -0,0 +1,3 @@
To assess trials of new tools and make sure your full rollouts are delivering consistent improvements, you should monitor results and make adjustments when needed. In general, we recommend considering the key zones of **quality, velocity, and developer happiness**, and how these zones come together to contribute to business outcomes.
Here are some metrics that we recommend looking at to assess {% data variables.product.prodname_copilot_short %}'s impact on this specific goal.