Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

DevOps is often described as the combination of people, processes and technologies to continuously deliver great products to customers. Central to a successful DevOps pipeline is automation, both to reduce the task burden for developers and increase reliability and accuracy. But setting up an environment which supports automation can, in and of itself, feel daunting. What's the best way to approach rolling out automation?

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Don't repeat yourself - automate all the things" src="https://www.youtube.com/embed/PAwvQDFAUCA?si=v2SaqCzX2EwXtkSD" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

[Jessica Dean](https://x.com/jldeen), staff enterprise advocate, joined Christopher to walk through some best practices and features available in GitHub Actions to ensure a smooth DevOps process. She started by defining DevOps, and highlighting the importance of automation.

Software Engineer [Brittany Ellich](https://github.com/brittanyellich) called in to discuss the GitHub Actions Marketplace, which is full of tools to help accelerate development of your own workflows. She also highlights attestations, allowing you to ensure you're running the Actions you trust, and only the Actions you trust.

As we begin to scale, we need to ensure we're centralizing as much work as possible, and of course doing it securely. Jessica highlights how we can create both reusable and required workflows. The former allows us to create a workflow once and reuse it across our entire organization, while the latter empowers us to enforce rules. So you can define a workflow for running tests and linters (for example) once, then apply it to all repositories of a particular type in your organization. And we can perform operations security using OIDC (OpenID Connect), which allows us to utilize temporary tokens instead of stored personal access tokens, which are effectively passwords.

Once we've created and configured our workflows we can turn our attention to ensuring they ran successfully and generating reports. As Jessica highlights, this can be done on individual workflows, or scale out to monitoring across a repository or an entire organization. This allows you to get an overview of what's taken place, and drill down to the specifics as needed, all while improving your DevOps implementation.

To learn more and continue your journey, explore the resources below:

## Docs

- [DevOps fundamentals: Defining DevOps principles](https://resources.github.com/devops/fundamentals/)  
- [About security hardening with OpenID Connect](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect)  
- [Reusing workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows)  
- [Monitoring your workflows](https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/about-monitoring-workflows)  
- [Creating rulesets (including required workflows) for repositories in your organization](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)

## Tools

- [GitHub Actions](https://docs.github.com/en/enterprise-cloud@latest/actions)  
- [GitHub Actions marketplace](https://github.com/marketplace?type=actions)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


Drive increased productivity, reusability, and security by automating your DevOps pipelines.

beyond-the-commit

Resource Page for /beyond-the-commit/automate-all-things

Don't repeat yourself - automate all the things

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

Most famously known as "eating your own dogfood," the process of building our products using our products is key to culture at GitHub. It allows us to learn and experience what you will feel, because if it doesn't work for us, or doesn't behave the way we'd expect, then it's not ready to be shipped. Through internal hackathons, computer clubs, and internal feature requests, we focus on creating products built by and for developers.

In this episode of Beyond the Commit, [__Neha Batra__](https://github.com/nerdneha), VP of Engineering at GitHub, joins host [__Christopher Harrison__](https://github.com/geektrainer) to talk more about this developer-first approach and embracing the idea that if features don’t feel right for us, they won’t feel right for you or your developers either.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="How new GitHub features are born | Beyond the Commit" src="https://www.youtube.com/embed/UzF2AvPbeS4?si=ysPZgSfSj7j6ykdT" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

Many features have been born out of developers discovering pain points. Take [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) for example. We wanted to be able to ship faster and reduce the potential for one pull request merge breaking a later one, so we developed an internal tool to support this need. From there, we asked ourselves if others could benefit from this feature, and if so, we’d ship it. And thus merge queue was shipped.

We keep the spirit of "computer club," a group of passionate geeks, alive and well. We allow Hubbers to self-identify their interest in a feature or product, provide early access to features, and look to work their feedback into the product. [Codespaces](https://github.com/features/codespaces) came about from a computer club, and some recent Copilot features have followed the same path.

A remote-first organization since our founding, GitHub has developed a comprehensive set of communication practices to support asynchronous, scalable, and inclusive collaboration. Drawing from the open source community’s emphasis on documentation and asynchronous workflows, GitHub has formalized these strategies into a public guide called "[How we communicate](https://github.blog/engineering/engineering-principles/how-to-communicate-like-a-github-engineer-our-principles-practices-and-tools/)." Many of these practices have been adopted from [innersource](https://github.com/resources/articles/software-development/innersource).

By using tools like issues, pull requests, and discussions—not just for code, but for planning and team communication—we've built a culture that values transparency, autonomy, and adaptability. This framework was created through collaboration across over 100 engineers, establishing guiding principles such as “Be asynchronous first,” “Write things down,” and “Make work visible.” In this episode of Beyond the Commit, we share these GitHub best practices and how you could enhance the way your organization creates software.

To learn more and continue your journey, explore the resources below:

## Insights

- [How to communicate like a GitHub engineer: our principles, practices and tools](https://github.blog/engineering/engineering-principles/how-to-communicate-like-a-github-engineer-our-principles-practices-and-tools/)  
- [How to build an enterprise LLM application: Lessons from GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/how-to-build-an-enterprise-llm-application-lessons-from-github-copilot/)  
- [How GitHub uses merge queue to ship hundreds of changes every day](https://github.blog/engineering/engineering-principles/how-github-uses-merge-queue-to-ship-hundreds-of-changes-every-day/)  
- [How GitHub harnesses AI to transform customer feedback into action](https://github.blog/ai-and-ml/machine-learning/how-github-harnesses-ai-to-transform-customer-feedback-into-action/)  
- [GitHub's Engineering Fundamentals program: How we deliver on availability, security and accessibility](https://github.blog/engineering/engineering-principles/githubs-engineering-fundamentals-program-how-we-deliver-on-availability-security-and-accessibility/)  
- [An introduction to innersource](https://github.com/resources/articles/software-development/innersource)

## Docs

- [Managing a merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)  
- [What are GitHub Codespaces?](https://docs.github.com/en/codespaces/about-codespaces/what-are-codespaces)  
- [Configuring issue templates for your repository](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


From innersource, to computer club, to eating our own dogfood, this is how we build GitHub on GitHub.

Resource Page for /beyond-the-commit/building-github-on-github

Beyond the Commit: Building GitHub on GitHub

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

We all know the importance of quality code. It makes code more readable and maintainable, and just generally [improves the developer experience](https://resources.github.com/developer-productivity/) (DevEx). So, when we introduce a tool like [GitHub Copilot](https://github.com/features/copilot/copilot-business?ocid=AIDcmmb150vbv1_SEM__k_Cj0KCQjwrPHABhCIARIsAFW2XBO1Xzs4qeSwyjMImzEXmxKI0u0JoZJL8zTEawm0guFixPgH9m2spgEaAqKJEALw_wcB_k_) into the code creation process, it’s critical to ensure that it maintains our same quality standards. What does the research tell us about the impact GitHub Copilot has on code quality?

<div class="embed-responsive embed-responsive-16by9">
<iframe title="How GitHub Copilot improves code quality | Beyond the Commit" src="https://www.youtube.com/embed/R03lvlbbREY?si=hpHMCZMcfLhOX2SY" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

__[Jared Bauer](https://github.com/jaredsb)__, GitHub staff researcher, [commissioned a study](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-code-quality/) to explore this exact topic, and joined host __[Christopher Harrison](https://github.com/geektrainer)__ to share his learnings. In a nutshell: happy developers create better code, and GitHub Copilot is effective at helping developers write better code.

To test the impact of Copilot on code quality, Jared’s study involved 202 experienced Python developers who were tasked with creating APIs to pass a set of unit tests. The study ultimately demonstrated that those who used Copilot were more likely to create code that passed all the tests put forth.

But passing tests doesn't tell the full story about code quality. It's not just about the code operating correctly — it also needs to be readable and maintainable. Measuring this requires code reviews, which was the next part of the study. All valid submissions were blind reviewed, where reviewers did not know what tools were being used to create the code. THe study found that code created with the help of Copilot was more likely to pass code reviews by over 10%: a statistically significant percentage.

Additional insights were gleaned from the study, including the fact that developers with Copilot both generated, but also deleted, more code than those who didn't use Copilot. The theory behind this behavior is that Copilot allowed developers more time, and gave them confidence to refactor their code to ensure it was of the highest quality possible.

To learn more and continue your journey, explore the resources below:

## Insights

- [Developer experience: What is it and why should you care?](https://github.blog/enterprise-software/collaboration/developer-experience-what-is-it-and-why-should-you-care/)  
- [Research: Quantifying GitHub Copilot's impact on code quality](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-code-quality/)  
- [Does GitHub Copilot improve code quality? Here's what the data says](https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/)

## Techs

- [GitHub Copilot](https://github.com/features/copilot)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Are we getting code developers can be proud of?

e65d7f237a3ee8a5bcf2a7a8afb28972c071a131a86a0e75c285b10b952a7a31-1920x1080

Resource Page for /beyond-the-commit/copilot-code-quality

Quality is key: GitHub Copilot and code quality

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

We often hear the phrase "shift left" in the world of DevSecOps as the standard way of improving security in our applications. But what exactly does shift left mean? And how do we do it the right way?

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Shift left the right way - creating more secure apps" src="https://www.youtube.com/embed/eQegu9jZRx8?si=wXaMO52no3Xr9l-N" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

Software Engineer [Angela Wen](https://github.com/angelapwen) joined Christopher to share her own experience with shift left. She starts by describing exactly what's meant by the phrase, and how it can fit into the development lifecycle. She highlights a couple of key challenges we can face in getting the approach right, from the fact that software engineers aren't typically security experts, and how we need to ensure we're getting the right information at the right time.

Field Services Director [Dan Shanahan](https://github.com/leftrightleft) calls in to talk about where shift left can often fail, and provides some guidance on how to ensure success. He highlights the importance of the experience for teams, developers, and security professionals, and providing the right resources to be successful.

With this background, Angela then walks us through a couple of the core tools available to us to drive secure software development. She starts by introducing code scanning, which traditionally meets developers at the time of the pull request (PR). This is the perfect time to let the developer know there's a potential security flaw, as they're looking for feedback on the code they've created. GitHub Copilot Autofix can even provide suggested remedies right inside the pull request, allowing the developer to commit the code with just a couple of clicks. In addition, campaigns allow teams to group together existing security tech debt and automate the process of generating fixes.

Beyond vulnerabilities introduced in code are leaked tokens. These are particularly dangerous as once they're in the codebase they're leaked, and it requires rotating the key, updating services, and other tasks to mitigate the risk. As Angela highlights, with secret scanning push protection these tokens can be blocked on push, meaning they never find their way into the codebase in the first place.

We close the conversation talking about the importance of the human factor in it all. There can be some tension between security teams and developers, which isn't helpful for anyone. At the end of it all, the core principle of ensuring everyone's needs are met helps drive success for everyone.

## Docs

- [What is DevSecOps?](https://github.com/resources/articles/devops/devsecops)  
- [Responsible use of Copilot Autofix for code scanning](https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/responsible-use-autofix-code-scanning)  
- [Best practices for participating in a security campaign](https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/best-practices-for-participating-in-a-security-campaign)  
- [Finding leaked passwords with AI: How we built Copilot secret scanning](https://github.blog/engineering/platform-security/finding-leaked-passwords-with-ai-how-we-built-copilot-secret-scanning/)  
- [Why application security tools fail and how DevSecOps fixes security debt](https://resources.github.com/application-security-tools-devsecops-fixes-security-debt/)

## Tools

- [About code scanning](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning)  
- [About secret scanning](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Bring security to your developers, and developers to your security, the right way.

Resource Page for /beyond-the-commit/create-secure-apps

Shift left the right way - creating more secure apps

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

The traditional approach to measuring productivity, and in turn velocity, is the number of lines of code. It's the most straightforward way to both understand and collect from a data perspective. Unfortunately, having this as our primary focus is a flawed approach. It both incentivizes the wrong behavior and doesn't provide a full picture of what a developer does in a day.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Beyond green squares: Effectively driving productivity" src="https://www.youtube.com/embed/5i9UGeCwl5s?si=TK05djX_-e1GFDR_" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

In this episode of Beyond the Commit, __[Eirini Nathan](https://github.com/ikaliam)__, staff researcher at GitHub, sat down with host __[Christopher Harrison](https://github.com/geektrainer)__ to help us better understand developer productivity. She explains that no developer sits down for a day's work with a goal of writing a certain amount of code. Instead they work to implement features, fix bugs, and design architectures — activities that aren't reflected in the green squares that appear on a developer's profile.

There are established frameworks, such as [DORA](https://dora.dev/) and [SPACE](https://queue.acm.org/detail.cfm?id=3454124), which are designed to provide a holistic overview of productivity. However, if you're new on this journey, these might not be the best approach. A better place to start is figuring out what goals you’re trying to meet by measuring, then have conversations with developers to determine any barriers they may be facing.

During the episode, Staff Product Manager __[Bronte Van der Hoorn](https://github.com/brontevdh)__ calls in to add her perspective on the importance of goals. After all, it's impossible to determine success if there isn't a clear definition of what success looks like. Once you establish goals, you both have a direction and a topic of conversation for your developers.

Talking to your developers should take many forms, including surveys, focus groups, and one-on-one conversations. Eirini recommends taking a three-step approach: listen, act, and learn. As you talk to your developers, listen to their experience and the blockers they face. Act on that feedback, working to make changes to improve both the developer experience and their productivity. Finally learn from that journey, see what worked and didn't, then make the appropriate adjustments.

To learn more and continue your journey, explore the resources below:

## Insights

- [Developer experience: What is it and why should you care?](https://github.blog/enterprise-software/collaboration/developer-experience-what-is-it-and-why-should-you-care/)   
- [The ultimate guide to developer happiness](https://github.blog/engineering/engineering-principles/the-ultimate-guide-to-developer-happiness/)   
- [Yes, good DevEx increases productivity. Here is the data.](https://github.blog/news-insights/research/good-devex-increases-productivity/)  
- [Survey reveals AI's impact on the developer experience](https://github.blog/news-insights/research/survey-reveals-ais-impact-on-the-developer-experience/)  
- [Research: quantifying GitHub Copilot's impact on developer productivity and happiness](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Before we can determine the impact of tools on productivity, we need to ensure we're asking the right questions.

4ba0cd42388a255e04c78e5143548f22e577d68e0f15f68e6a3c76c18b927981-1920x1080

Resource Page for /beyond-the-commit/effectively-driving-productivity

Beyond green squares: Effectively driving productivity

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you") 

After deciding to enable Copilot for your development team comes the next big task—activating the licenses and managing features. For larger organizations this can feel daunting, but it doesn't need to be. As usual, a focus on the fundamentals and using the tools available will lead you to success.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Managing Copilot: Governance and GitHub Copilot | Beyond the Commit" src="https://www.youtube.com/embed/CwP81uyISuc?si=e4iiLS0IxKLPq3pP" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

Luis Pujols, senior customer success architect, joins host Christopher to discuss various strategies for managing a Copilot rollout. There are various approaches to enabling and managing licenses, from activating Copilot for an entire organization to custom solutions using the available REST APIs. He discusses the pros and cons of each to help you determine which will work best for your scenarios.

The next question typically raised is around usage. How can we measure adoption of Copilot, and in turn what strategy should we adopt if certain developers aren't utilizing Copilot. There are numerous REST APIs available for measuring usage and generating reports, allowing you to see adoption, code acceptance rates, and get breakdowns by language and other dimensions. From there you can work with your developers to determine what barriers they're facing to utilizing the tool to drive adoption and productivity increases.

Introducing Copilot to the code creation process doesn't change the DevOps process, in particular when it comes to code review. Field CTO Andrew Weiss calls in to highlight the fact that developers are still in charge. They want to read, review, and ensure the code suggested by Copilot does exactly what it should do and how it should be done.

In the end, Copilot is like any other developer tool, and can be approached as such. Rolling it out can follow normal patterns, measurements can be gathered, and the developer is always in charge of the code creation process.

## Docs 

- [Glossary: Measuring the impact of GitHub Copilot](https://resources.github.com/artificial-intelligence/how-to-measure-github-copilot-impact/) 
- [Embrace AI-powered software development](https://resources.github.com/embrace-ai-powered-software-development/)
- [Essential GitHub Copilot resources for enterprise teams](https://resources.github.com/enterprise/essential-copilot-resources/) 
- [Setting up GitHub Copilot for your enterprise](https://docs.github.com/en/enterprise-cloud@latest/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-enterprise) 

## Tools 
- [REST API endpoints for Copilot metrics](https://docs.github.com/en/rest/copilot/copilot-metrics?apiVersion=2022-11-28) 
- [REST API endpoints for Copilot user management](https://docs.github.com/en/rest/copilot/copilot-user-management?apiVersion=2022-11-28) 
- [Enabling Copilot for organizations in your enterprise](https://docs.github.com/en/enterprise-cloud@latest/copilot/managing-copilot/managing-copilot-for-your-enterprise/managing-access-to-copilot-in-your-enterprise/enabling-copilot-for-organizations-in-your-enterprise) 
- [Managing policies and features for Copilot in your enterprise](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) 

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


Make sure the right people have access to the right tools the right way.

Resource Page for /beyond-the-commit/governance-and-github-copilot

Managing Copilot: Governance and GitHub Copilot

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

Rolling out GitHub Copilot to an organization follows many of the same practices as rolling out any new developer tool, but there are some key differences. To get the most out of Copilot, developers need to incorporate it into their daily workflow, which involves changing some existing behaviors. But unlike a new tool for automation, for example, where a developer is "required" to use it whenever they need to take advantage of automation, one can continue to create code without using Copilot.

So how can we ensure they're using the tool, and in turn seeing benefits from it? As Staff Researcher Ya Gao explains, there are four keys to successfully rolling out GitHub Copilot and onboarding developers, and it all starts with setting goals.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Taking it to the streets: Rolling out GitHub Copilot" src="https://www.youtube.com/embed/lbn5ZrEmtGY?si=Rk2fjCyBdpmVVS8G" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

As Ya discusses with host Christopher Harrison, goals are important because without them, we don't have a direction and won't know if we've succeeded. From there, we can begin working through the next keys to a successful rollout: champions, reminders, and training.

Ya defines champions as the developers people look up to rather than the leadership team. After all, they're the ones who will also be using the tool, and have experiences they can then share with others. These can be principle or staff-level developers: those who are actively writing code and mentoring others. They help create the excitement which drives adoption and usage of any new product, including Copilot.

Probably the most overlooked and impactful strategy is sending reminders to install (and use) Copilot. When a developer is granted access to Copilot, they receive an email, which includes instructions on how to install the extension in their IDE. But these emails can often be overlooked and forgotten. Sending additional reminders, either via email or another tool, helps drive installation and adoption.

Finally Ya walks us through the importance of training. Rather than a single point-in-time event, training should be continuous and take multiple forms. This can include hosting a workshop where an instructor leads developers through best practices; office hours where developers can ask questions of an expert; or informal methods such as a channel on Teams or Slack. Ensuring developers have access to the information they need, when they need it, will help them get the most out of the tool.

To learn more and continue your journey, explore the resources below:

## Docs

- [Research: Quantifying GitHub Copilot's impact in the enterprise with Accenture](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/)  
- [Training and onboarding developers on GitHub Copilot](https://github.com/resources/whitepapers/training-and-onboarding-developers-on-github-copilot)  
- [The engineering leader's guide to AI](https://github.com/resources/whitepapers/engineering-leaders-guide-to-ai)  
- [Taking GitHub Copilot to the stars, not just the skies](https://github.com/resources/whitepapers/scaling-github-copilot-across-your-organization)

## Tools

- [GitHub Copilot](https://github.com/features/copilot)  
- [REST API endpoints for Copilot metrics](https://docs.github.com/en/rest/copilot/copilot-metrics?apiVersion=2022-11-28)  
- [REST API endpoints for Copilot user management](https://docs.github.com/en/rest/copilot/copilot-user-management)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


Set your organization and developers up for success when enabling GitHub Copilot.