diff --git a/CHANGELOG.md b/CHANGELOG.md index d6fe3f5688e7..c162efefd161 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,11 @@ # Docs changelog +**9 December 2025** + +We published [a guide](https://docs.github.com/en/enterprise-cloud@latest/admin/concepts/enterprise-best-practices/use-innersource) to help customers set up innersource practices in their enterprise. The guide also provides a conceptual introduction to features like internal visibility, organization base permissions, and roles for external collaborators. + +
+ **8 December 2025** We've added a new tutorial on how to use Copilot Chat to write code for you. The tutorial steps you through how to create a time tracking web app using only prompts in Copilot Chat. diff --git a/content/admin/concepts/enterprise-best-practices/index.md b/content/admin/concepts/enterprise-best-practices/index.md new file mode 100644 index 000000000000..f966c99db68a --- /dev/null +++ b/content/admin/concepts/enterprise-best-practices/index.md @@ -0,0 +1,14 @@ +--- +title: Best practices for enterprises +shortTitle: Best practices +intro: 'Follow best practices to set up your enterprise''s teams for success.' +versions: + ghes: '*' + ghec: '*' +topics: + - Enterprise +children: + - /organize-work + - /use-innersource +contentType: concepts +--- \ No newline at end of file diff --git a/content/admin/concepts/best-practices.md b/content/admin/concepts/enterprise-best-practices/organize-work.md similarity index 72% rename from content/admin/concepts/best-practices.md rename to content/admin/concepts/enterprise-best-practices/organize-work.md index 79a56ca052f4..4134dcd1eb1a 100644 --- a/content/admin/concepts/best-practices.md +++ b/content/admin/concepts/enterprise-best-practices/organize-work.md @@ -1,6 +1,6 @@ --- title: Best practices for organizing work in your enterprise -shortTitle: Best practices +shortTitle: Organize work intro: Promote collaboration and manage resources at scale by following {% data variables.product.company_short %}-recommended practices for managing organizations and teams. versions: ghec: '*' @@ -15,11 +15,18 @@ redirect_from: - /admin/user-management/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise - /admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise - /admin/concepts/best-practices-for-enterprises + - /admin/concepts/best-practices allowTitleToDifferFromFilename: true --- {% data reusables.enterprise-onboarding.best-practices %} +## Use innersource practices + +Innersource makes it easy for all employees to discover and reuse work. This allows development teams to learn from each other and avoid duplicating effort to recreate common services. + +For guidance on setting up effective innersource practices, see [AUTOTITLE](/admin/concepts/enterprise-best-practices/use-innersource). + {% ifversion ghec %} ## Next steps diff --git a/content/admin/concepts/enterprise-best-practices/use-innersource.md b/content/admin/concepts/enterprise-best-practices/use-innersource.md new file mode 100644 index 000000000000..9297fe91ecd3 --- /dev/null +++ b/content/admin/concepts/enterprise-best-practices/use-innersource.md @@ -0,0 +1,16 @@ +--- +title: Using innersource in your enterprise +shortTitle: Use innersource +intro: Help dispersed teams to collaborate by setting up open source–style workflows in your enterprise, without compromising on security. +versions: + ghec: '*' + ghes: '*' +contentType: concepts +topics: + - Accounts + - Enterprise + - Fundamentals +allowTitleToDifferFromFilename: true +--- + +{% data reusables.enterprise-onboarding.use-innersource %} diff --git a/content/admin/concepts/index.md b/content/admin/concepts/index.md index 4f802bf9c56c..6a84522e8cb1 100644 --- a/content/admin/concepts/index.md +++ b/content/admin/concepts/index.md @@ -11,7 +11,7 @@ children: - /enterprise-fundamentals - /identity-and-access-management - /security-and-compliance - - /best-practices + - /enterprise-best-practices contentType: concepts --- diff --git a/content/copilot/tutorials/copilot-chat-cookbook/testing-code/index.md b/content/copilot/tutorials/copilot-chat-cookbook/testing-code/index.md index 406c8c404a3c..82bb5bd3b18d 100644 --- a/content/copilot/tutorials/copilot-chat-cookbook/testing-code/index.md +++ b/content/copilot/tutorials/copilot-chat-cookbook/testing-code/index.md @@ -12,6 +12,7 @@ children: - /generate-unit-tests - /create-mock-objects - /create-end-to-end-tests + - /update-unit-tests contentType: tutorials --- diff --git a/content/copilot/tutorials/copilot-chat-cookbook/testing-code/update-unit-tests.md b/content/copilot/tutorials/copilot-chat-cookbook/testing-code/update-unit-tests.md new file mode 100644 index 000000000000..76920681ccb1 --- /dev/null +++ b/content/copilot/tutorials/copilot-chat-cookbook/testing-code/update-unit-tests.md @@ -0,0 +1,122 @@ +--- +title: Updating unit tests to match code changes +shortTitle: Update unit tests +intro: '{% data variables.copilot.copilot_chat_short %} can help with updating your tests.' +versions: + feature: copilot +category: + - Testing code + - Author and optimize with Copilot +complexity: + - Intermediate +octicon: beaker +topics: + - Copilot +contentType: tutorials +--- + +When you make changes to your code, it's important to update any tests to verify the new behavior and catch any bugs that the new code has introduced. {% data variables.copilot.copilot_chat_short %} can help you quickly update tests to match your code changes, ensuring your test suite stays in sync with your implementation. + +## Example scenario + +Imagine you have a Python function, `calculate_discount`, that determines the discount for a given purchase amount. In the original code, you get a 10% discount for amounts over $100. You're making changes to the logic of the function, so that only prices over $150 get a 10% discount, and there's now a 20% discount for amounts over $200. + +### Original code + +In the original code, purchase prices above $100 get a 10% discount. + +```python +def calculate_discount(amount: float) -> float: + if amount > 100: + return amount * 0.1 # 10% discount + return 0.0 +``` + +### Updated code + +In the changed code, only amounts above $150 get 10% discount, and amounts above $200 now get a 20% discount. + +```python id=calculate_discount +def calculate_discount(amount: float) -> float: + if amount > 200: + return amount * 0.2 + elif amount > 150: + return amount * 0.1 + return 0.0 +``` + +### Existing tests + +This example shows the existing tests that were written for the original code. + +```python +import unittest +from discount import calculate_discount + +class TestCalculateDiscount(unittest.TestCase): + def test_discount_above_100(self): + # $140 should get a $14 discount (10%) + self.assertAlmostEqual(calculate_discount(140), 14.0) + + def test_discount_below_100(self): + # $80 should get no discount + self.assertEqual(calculate_discount(80), 0.0) + + def test_discount_exactly_100(self): + # $100 is not above 100, so no discount + self.assertEqual(calculate_discount(100), 0.0) + +if __name__ == '__main__': + unittest.main() +``` + +## Example prompt + +You can ask {% data variables.copilot.copilot_chat_short %} to identify and update any tests affected by your logic change. + +```copilot +Given the update to the `calculate_discount` function, update the unit tests that may fail or become outdated as a result. +``` + +## Example response + +{% data reusables.copilot.example-prompts.response-is-an-example %} + +{% data variables.copilot.copilot_chat_short %} analyzes your code and existing tests, and identifies which tests will fail or are now misleading following your code change. + +For example, {% data variables.copilot.copilot_chat_short %} explains that: +* `test_discount_above_100` will now **fail** +* `test_discount_below_100` and `test_discount_exactly_100` will pass, but they are now **misleading**, since the threshold for the 10% discount is now $150, and not $100. + +In addition, {% data variables.copilot.copilot_chat_short %} identifies any **missing test coverage**, such as the new 20% discount tier for amounts over $200. + +{% data variables.copilot.copilot_chat_short %} proposes an updated set of tests. + +### Updated tests + +```python +import unittest +from discount import calculate_discount + +class TestCalculateDiscount(unittest.TestCase): + def test_discount_above_200(self): + # $250 should get a $50 discount (20%) + self.assertAlmostEqual(calculate_discount(250), 50.0) + + def test_discount_above_150(self): + # $175 should get a $17.50 discount (10%) + self.assertAlmostEqual(calculate_discount(175), 17.5) + + def test_discount_at_or_below_150(self): + # $150 is not above 150, so no discount + self.assertEqual(calculate_discount(150), 0.0) + # $80 should get no discount + self.assertEqual(calculate_discount(80), 0.0) + +if __name__ == '__main__': + unittest.main() +``` + +## Further reading + +{% data reusables.copilot.example-prompts.further-reading-items %} \ No newline at end of file diff --git a/content/enterprise-onboarding/index.md b/content/enterprise-onboarding/index.md index a4c66d693bda..a3dffca05b40 100644 --- a/content/enterprise-onboarding/index.md +++ b/content/enterprise-onboarding/index.md @@ -33,6 +33,7 @@ journeyTracks: - '/enterprise-onboarding/setting-up-organizations-and-teams/about-teams-in-an-enterprise' - '/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams' - '/enterprise-onboarding/setting-up-organizations-and-teams/assigning-roles-to-teams-and-users' + - '/enterprise-onboarding/setting-up-organizations-and-teams/use-innersource' - id: 'support_for_your_enterprise' title: 'Creating a support model for your enterprise' description: 'Find out how to get help and choose who will be able to contact Support.' diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/assigning-roles-to-teams-and-users.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/assigning-roles-to-teams-and-users.md index f094b2be794b..f93b6e9a6e50 100644 --- a/content/enterprise-onboarding/setting-up-organizations-and-teams/assigning-roles-to-teams-and-users.md +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/assigning-roles-to-teams-and-users.md @@ -14,4 +14,4 @@ topics: ## Next steps -Now that you've set up organizations and teams to manage people's access to work in your enterprise, learn about support so you can get help when you need it. See [AUTOTITLE](/enterprise-onboarding/support-for-your-enterprise/understanding-support). +Learn how to set up a culture of innersource in your enterprise to allow teams to collaborate and work efficiently. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/use-innersource). diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md index 9104a0749977..31379229d62a 100644 --- a/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md @@ -17,5 +17,6 @@ children: - /about-teams-in-an-enterprise - /creating-teams - /assigning-roles-to-teams-and-users + - /use-innersource --- diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/use-innersource.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/use-innersource.md new file mode 100644 index 000000000000..f52b22374034 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/use-innersource.md @@ -0,0 +1,19 @@ +--- +title: Using innersource in your enterprise +shortTitle: Use innersource +intro: Help dispersed teams to collaborate by setting up open source–style workflows in your enterprise, without compromising on security. +versions: + ghec: '*' +contentType: concepts +topics: + - Accounts + - Enterprise + - Fundamentals +allowTitleToDifferFromFilename: true +--- + +{% data reusables.enterprise-onboarding.use-innersource %} + +## Next steps + +Now that you've set up organizations and teams, learn about support so you can get help when you need it. See [AUTOTITLE](/enterprise-onboarding/support-for-your-enterprise/understanding-support). diff --git a/content/repositories/creating-and-managing-repositories/about-repositories.md b/content/repositories/creating-and-managing-repositories/about-repositories.md index 1db94dffe657..2492d26efe52 100644 --- a/content/repositories/creating-and-managing-repositories/about-repositories.md +++ b/content/repositories/creating-and-managing-repositories/about-repositories.md @@ -100,7 +100,7 @@ People with admin permissions for a repository can change an existing repository ## About internal repositories -{% data reusables.repositories.about-internal-repos %} For more information on innersource, see {% data variables.product.prodname_dotcom %}'s whitepaper [An introduction to innersource](https://resources.github.com/whitepapers/introduction-to-innersource/). +{% data reusables.repositories.about-internal-repos %} For more information on innersource, see [AUTOTITLE](/admin/concepts/enterprise-best-practices/use-innersource). {% ifversion ghec %} diff --git a/data/reusables/enterprise-onboarding/use-innersource.md b/data/reusables/enterprise-onboarding/use-innersource.md new file mode 100644 index 000000000000..51ef77ecbcc5 --- /dev/null +++ b/data/reusables/enterprise-onboarding/use-innersource.md @@ -0,0 +1,52 @@ +You can use innersource practices to drive collaboration and productivity in your enterprise. Innersource makes it easy for all employees to discover and reuse work. This allows development teams to learn from each other's work, share their expertise, and avoid duplicating effort to recreate common services. + +## Make repositories discoverable + +Unless they contain sensitive information, you should aim to make repositories visible to all employees. + +To do this, encourage employees to use **internal** visibility whenever possible. Internal visibility allows any member of any organization in the enterprise to view the repository, regardless of whether the user is a member of the organization that owns the repository. + +You should also set permissive **base permissions** for organizations. An organization's base permission policy determines the default level of access that members of that organization have to all the organization's repositories. Generally, organizations should have at least a "Read" base permission so that all organization members can see any repository. Organization owners can then use teams to grant people greater levels of access in specific repositories. + +If you have more sensitive repositories that should not be widely visible, you can set up a dedicated organization with a more restrictive base permission and add specific teams to this organization. + +For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-internal-repositories) and [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization). + +## Document projects + +Organize and document your repositories so that people can search for work across the enterprise. + +Repository **READMEs** are effective because they're defined in files in the repository, so users can search for them like code. You can also create READMEs at the level of an organization or enterprise account to provide a higher-level overview of where to find different projects. For more formal internal documentation, consider setting up a **{% data variables.product.prodname_pages %} site** or **wikis**. + +You can use **repository topics** to group repositories that contain a certain programming language, are owned by a certain team, and so on. This is another way of making repositories easier to find. + +For more information, see: + +* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes), [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-member-only-organization-profile-readme), and [AUTOTITLE](/admin/managing-your-enterprise-account/creating-a-readme-for-an-enterprise) +* [AUTOTITLE](/pages/getting-started-with-github-pages/creating-a-github-pages-site) +* [AUTOTITLE](/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages) +* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics) + +## Set up a culture for sharing work + +Encourage teams to publicize their work and share resources with other teams. {% data variables.product.github %} has a number of features that make this easier. For example, teams can: + +* Use **discussions** to make their work more visible to other teams. See [AUTOTITLE](/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion#creating-a-discussion). +* Create a dedicated internal repository for sharing **actions and reusable {% data variables.product.prodname_actions %} workflows**, which anyone can reference when they write a workflow within the enterprise. See [AUTOTITLE](/actions/how-tos/reuse-automations/share-with-your-enterprise). +* Share reusable pieces of code in internal packages with **{% data variables.product.prodname_registry %}** registries. For enhanced security, you can give {% data variables.product.github %}'s security features access to these registries. See [AUTOTITLE](/packages/learn-github-packages/introduction-to-github-packages). +* Set up common templates and frameworks as **template repositories** that other people can copy to get started with a project. See [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-template-repository). + +Like with an open source project, you should ensure shared projects have a support model and a clearly defined team of maintainers, especially for services that many parts of your enterprise rely on. Ideally the maintainers team will contain representatives from the different teams that use the service. + +## Hide content from external collaborators + +If you have external contractors or collaborators who need access to your enterprise's projects, you can grant them a different level of access from regular employees. + +Specifically, you may want to hide internal repositories from an external collaborator. To do this: + +* If you use {% data variables.product.prodname_emus %}, provision an account for the user with the **guest collaborator** role. Guest collaborators don't have access to internal repositories by default, but they receive base permissions in organizations where they're added as members. They can also be added as repository collaborators in repositories. +* If you do not use {% data variables.product.prodname_emus %}, add the user as an **outside collaborator** in the required repositories, but ensure they are not added as a member of any organization. + +Outside collaborators (called **repository collaborators** if you use {% data variables.product.prodname_emus %}) only have access to a specific repository. These users are not full organization members, so they do not receive the base level of access for the organization, and they cannot automatically see internal repositories in the enterprise unless they are a member of another organization. + +For more information, see {% ifversion ghec %}[AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/enabling-guest-collaborators) and{% endif %} [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization).