{"id":4803,"date":"2023-06-07T09:59:31","date_gmt":"2023-06-07T09:59:31","guid":{"rendered":"https:\/\/staging.elixirrdigital.com\/us\/?p=4803"},"modified":"2025-03-17T13:11:30","modified_gmt":"2025-03-17T13:11:30","slug":"github-enterprise-overview-and-best-practices","status":"publish","type":"post","link":"https:\/\/staging.elixirrdigital.com\/us\/2023\/06\/07\/github-enterprise-overview-and-best-practices\/","title":{"rendered":"GitHub Enterprise Overview and Best Practices"},"content":{"rendered":"

GitHub Enterprise<\/a>\u00a0is a self-hosted version of\u00a0GitHub<\/a>\u00a0that provides organizations with the flexibility to manage their own development environment. In this blog, we will cover the basics of setting up a repository, including branch protection rules and other security settings, as well as how to integrate GitHub Enterprise with\u00a0Amazon Web Services<\/a>(AWS) using\u00a0GitHub Actions<\/a>.<\/p>\n

1. Introduction to GitHub Enterprise<\/h2>\n

To get started with GitHub Enterprise, the first step is to set up a new repository. A repository is essentially a container for your project, including all the code, documentation, and other files that you need to develop and maintain your software.<\/p>\n

When setting up a new repository in GitHub Enterprise, it is important to consider the security settings you will use to protect your code. This can include things like branch protection rules, which prevent unauthorized changes to certain branches of your repository. You can also configure other security settings like two-factor authentication and access controls to ensure that only authorized users have access to your code.<\/p>\n

2. Setting up a Repository in GitHub Enterprise<\/h2>\n

Developers can often end up working in a GH Enterprise since it offers a closed space to the owners of the project. Specifically, when project owners choose to adopt GitHub Enterprise, they are required to create an organization. This organization serves as a container for all repositories associated with the project. In this blog, we will focus on setting up a repository within the organization, without covering organizational settings that developers are less likely to encounter.<\/p>\n

2.1 Creating a New Repository in GitHub Enterprise<\/strong><\/p>\n

At the organization home page navigate to the Repositories tab and click New Repository.<\/p>\n

\"\"<\/p>\n

Proceed with choosing a name for the repository. Visibility of the repository should be Internal, but that depends on the use case of the repository. Click on Create repository and follow instructions to locally initialize the repository.<\/p>\n

2.2 Adding and Managing Collaborators<\/strong><\/p>\n

To add collaborators or teams to your specific repository, navigate to the Settings tab and click on Collaborators and teams on the sidebar. It is important to adhere to the principle of least privilege (POLP<\/a>). That means that we should limit collaborator\u2019s access rights to only those that are strictly required to do their jobs. In the example below, Marin is a developer so that means he only needs the \u2018Write\u2019 role to be able to do his job.<\/p>\n

\"\"<\/p>\n

2.3 Branching Strategy<\/strong><\/p>\n

Standard practice for branching strategy is to use certain branches as environments. These environments should correspond to \u2018Production\u2019, \u2018Stage\u2019 and \u2018Development\u2019. However, it all depends on the project\u2019s use case. For this blog, we will use \u2018production\u2019, \u2018stage\u2019 and \u2018development\u2019 branches.<\/p>\n

The \u2018development\u2019 branch is used to test a recently developed feature; if tests are successful on the \u2018development\u2019 branch, then the feature can proceed to the \u2018stage\u2019 branch.<\/p>\n

The \u2018stage\u2019 branch is a second stop for a feature to be tested. Typically, the \u2018stage\u2019 branch is a replica of the \u2018production\u2019 branch, with the same configurations and infrastructure, allowing developers and testers to test their changes in an environment that closely resembles the production environment. If the tests are successful on the \u2018stage\u2019 branch, then the feature can proceed to the \u2018production\u2019 branch.<\/p>\n

The \u2018production\u2019 branch is where the feature gets officially deployed. At this point, the feature is stable and safe for the production environment.<\/p>\n

\"\"<\/p>\n

A branching strategy impacts how we can integrate the repository with AWS. In this case, we can designate one account for each environment branch in our repository. For example, let\u2019s say that in this repository developers are developing CloudFormation templates which are used for deployment through GitHub Actions. If they push a feature to the \u2018development\u2019 branch, that\u00a0CloudFormation<\/a>\u00a0template would get deployed to the development AWS account; if the feature were pushed to the \u2018stage\u2019 branch, it would get deployed to the stage AWS account, etc.<\/p>\n

2.4 Development Strategy<\/strong><\/p>\n

We have covered environment branches so far, now it\u2019s time to see how we will develop new\u00a0features<\/a>. The best practice for feature development would be to create a separate branch that could be called \u2018feature\/description-of-the-feature\u2019 (we\u2019ll refer to this branch as feature branch throughout the blog). Feature branches such as this one should be created from one of the environment branches, in some cases that might be \u2018production\u2019 or \u2018development\u2019 \u2013 this is usually defined along with the branching strategy, since this depends on the use case.<\/p>\n

\"\"<\/p>\n

Let\u2019s say we have created a feature branch and we have developed a feature on it. Now it is time to push to the \u2018development\u2019 branch. We should do that by creating a pull request from the feature branch to the \u2018development\u2019 branch.<\/p>\n

A\u00a0pull request<\/a>\u00a0(PR) is the best practice because it provides an overview of the feature that we are trying to merge to the environment branch. It also contains an overview of test results for that feature. We will cover more of this later.<\/p>\n

2.5 Secrets and Variables<\/strong><\/p>\n

Secrets<\/a>\u00a0and\u00a0variables<\/a>\u00a0come in several types.<\/p>\n

Organization secrets and variables are accessible by all repositories within an organization. Repository secrets and variables are only accessible by the repository where they are defined (though they can also be passed to other repositories). That will not be covered in this blog.<\/p>\n

Environment secrets and variables, on the other hand, are specific to a particular environment, and we will cover them in the next section.<\/p>\n

2.6 Environment Setup<\/strong><\/p>\n

Located in Settings, there is an \u2018Environments<\/a>\u2019 tab. Environments are useful because we can create a set of rules, secrets, and variables for a specific environment.<\/p>\n

For example, we can create three environments called \u2018development\u2019, \u2018stage\u2019, \u2018production\u2019. Let\u2019s say that we want to have a variable called AWS_ROLE which is different across environments, and we want to avoid having three variables in code where each would have the same purpose but different value. In that case we can specify AWS_ROLE in all three environments and assign a different value for each environment.<\/p>\n

This is useful when GitHub workflows are created, then we can specify in which environment job is running, so when we use a variable, it will use the value from the specified environment. For example, if we define that the job is running in the \u2018production\u2019 environment, then if we use the AWS_ROLE variable in that job, the workflow will know that it should grab the value from the \u2018production\u2019 environment.<\/p>\n

Furthermore, Environments are also useful when we want to specify which branch can deploy to the environment. If we define that only \u2018feature\/*\u2019, meaning, branches starting with \u201cfeature\/\u201d can deploy to the environment, it will automatically deny any other branches which would try to deploy to it.<\/p>\n

\"\"<\/p>\n

2.7 CODEOWNERS<\/strong><\/p>\n

In GitHub,\u00a0CODEOWNERS<\/a>\u00a0is a feature that lets you define individuals or teams responsible for code within a repository. This feature is particularly useful in large projects where many contributors are working on the codebase. Code owners can be defined for any file or folder within a repository. When a pull request is opened that modifies a file or folder that has a CODEOWNERS file associated with it, the individuals or teams defined in the CODEOWNERS file will be notified and asked to review the pull request.<\/p>\n

Code owners can be defined in the file CODEOWNERS in the root of the repository or any subdirectory. The CODEOWNERS file follows a simple syntax where each line represents a file or folder path, followed by a space or tab, and then the list of code owners (GitHub usernames or team names) for that file or folder.<\/p>\n

\"\"<\/p>\n

In this example, user \u2018sukyca\u2019 is the owner of \u201c.github\/workflows\u201d directory and if any change occurs, that user will be asked to review that change in a pull request.<\/p>\n

2.8 Branch Protection Rules<\/strong><\/p>\n

GitHub\u00a0branch protection rules<\/a>\u00a0are a powerful tool for ensuring that the code in your repository is of high quality and adheres to the team\u2019s standards. These rules can be applied to specific branches and can enforce a wide variety of requirements. Some common examples of branch protection rules include requiring pull requests to be reviewed by multiple team members, preventing force pushes to a branch, and requiring certain status checks to pass before changes can be merged.<\/p>\n

If we have a branch named \u2018production\u2019 and we want to protect it by using Branch Protection Rules, we need to navigate to Settings and click on Branches. Click \u2018Add rule\u2019 and make sure that the rule name is the same as the name of the branch, otherwise the rule will not apply to the branch. In this case, we would create a rule called \u2018production\u2019.<\/p>\n

\"\"<\/p>\n

It is a good idea to check \u201cRequire a pull request before merging\u201d rule as it will enforce developers to use pull requests instead of pushing directly to the branch.<\/p>\n

We can also specify how many approvals we require before the pull request can be valid. This will force responsible users (Codeowners) to check the code before it is released into the environment.<\/p>\n

\"\"<\/p>\n

Furthermore, we can check \u201cRequire status checks to pass before merging\u201d rule, which will disable the pull request from being merged until the specified jobs are ran successfully.<\/p>\n

For example, we have a \u2018pr_opened.yml\u2019 workflow which has \u2018build\u2019 job in it, if we specify that \u2018build\u2019 job is required to pass, then the pull request will wait for it to execute successfully, otherwise it will not let the pull request to get merged.<\/p>\n

\"\"<\/p>\n

These were some of the most common rules to be applied to a branch. Of course, this all depends on the project use case, so feel free to explore.<\/p>\n

3. Conclusion<\/h2>\n

This blog has provided insights into key features and practices of GitHub Enterprise that can greatly enhance collaboration, security, and development processes within your organization. By leveraging these tools and strategies effectively, teams can optimize their workflows and achieve greater productivity and success in their software development endeavors.<\/p>\n

Certainly, our\u00a0DevSecOps team is readily available to assist you in designing, managing, and building such infrastructures within GitHub Enterprise.\u00a0We\u2019re here to help!<\/p>\n","protected":false},"excerpt":{"rendered":"

In this post, we will cover the basics of setting up a repository, as well as how to integrate GitHub Enterprise with Amazon Web Services.<\/p>\n","protected":false},"author":6,"featured_media":6284,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35,32],"tags":[],"related_service":[48],"related_industry":[],"class_list":["post-4803","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dev-sec-ops","category-aws"],"acf":[],"card":"

\n
\n \"\" <\/div>\n
\n
\n

\n Blog <\/p>\n \n

\n GitHub Enterprise Overview and Best Practices\n <\/h2>\n <\/a> <\/div>\n
\n

\n In this post, we will cover the basics of setting up a repository, as well as how to integrate GitHub Enterprise with Amazon Web Services. <\/p>\n

\n

\n 07 June 2023 <\/p>\n

\n
\n IT Services <\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n<\/article>\n","_links":{"self":[{"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/posts\/4803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/comments?post=4803"}],"version-history":[{"count":0,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/posts\/4803\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/media\/6284"}],"wp:attachment":[{"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/media?parent=4803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/categories?post=4803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/tags?post=4803"},{"taxonomy":"related_service","embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/related_service?post=4803"},{"taxonomy":"related_industry","embeddable":true,"href":"https:\/\/staging.elixirrdigital.com\/us\/wp-json\/wp\/v2\/related_industry?post=4803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}