Task 01 - Branching & Policies (20 minutes)

Introduction

In the previous exercises, we successfully implemented an end-to-end CI/CD pipeline! However, the current workflow will immediately promote every small change directly to production. This isn’t an ideal scenario, especially when Munson’s Pickles and Preserves is making updates to the Team Messaging System after it’s been promoted to production or is even in the testing phase. Best practices are to avoid working directly against the main branch in your repository to avoid conflicts and protect the production environment.

With GitHub, Munson’s Pickles and Preserves can solve these challenges using a practice called branching. Some may refer to this as the GitHub flow. When a developer wants to make a change, add a feature, or fix a bug, the developer begins by creating a new ‘branch’ or copy of the main codebase. Then, the developer makes changes and commits them. A pull request is created to merge these changes back into the main branch. This pull request may or may not involve some testing, discussion and approval. Finally, changes are merged back into the main codebase, and the branch can be deleted.

Description

In this task, you will practice the GitHub flow. Additionally, GitHub offers a feature for explicitly protecting against changes directly to the main branch. These are called branch protection rules, and you will start by implementing one.

Ask GitHub Copilot, “Why should I enable branch protection on a GitHub repository?” to learn about the benefits of branch protection.
Create a branch protection rule which prevents developers from committing changes to the main branch in the repository.
Create a feature branch, make a small change to the code (i.e.,/Application/src/RazorPagesTestSample/Pages/Index.cshtml), and sync this branch with the GitHub repository.
Ask GitHub Copilot, “What do I need in a codeowners file?” Then, define a code owner for the /Application directory. Your branch policy should require a review from the code owner.
Create and complete a Pull Request, merging your code change into the protected branch.

Success Criteria

You have a branch protection rule which prevents changes from being committed to your main branch.
Changes to the application (i.e.,/Application/src/RazorPagesTestSample/Pages/Index.cshtml) are committed to a feature branch.
Before a pull request is completed:
- A code owner must approve the changes (hint)
A completed pull request merges with the protected branch and is automatically deployed to the dev environment.

Learning Resources

Tips

If your GitHub account was created on the ‘Free’ tier, then in order to create a Branch Protection rule your repository must be public. To change a repository from private to public, visit the ‘Settings’ tab, and scroll to the bottom where you have the option to ‘Change visibility.’
If using the git command line interface, you can find a number of sample git commands that are useful for branching. (Make sure to focus on the ‘git’ commands, rather than ‘gitflow’.)
If using the git command line interface, try adding ‘–help’ after a command to get helpful information about arguments and usage.

Solution

Expand this section to view the solution

Go to Settings, Branches, and select Add branch protection rule
For the “Branch name pattern” use main. If you wanted this to apply to a certain name format you could also use a regex pattern.
Ensure that Require a pull request before merging is checked
- Keep Require approvals checked and set the number of approvals to 1
- Select Require review from Code Owners
Add the CODEOWNERS file to specify the code owners for the repo and applications.
Testing the branch protection rules is hard if it is your personal repo and you are the Owner, as Owners can bypass branch protection rules. One way to verify the rule is properly in place it to edit the file in your browser and then commit the change and select the main branch. If the rule is in place, you’ll get a warning about bypassing the rules and committing the change.
If you choose Create a new branch, the warning will be removed and you can propose the change.
Once you’ve proposed the change in a new branch, you can create a pull request to merge the branch into main. If this is a repository you own, a review is not mandatory because you are able to approve your own commit. To test this, set the approver to the GitHub account of another learner on your team so you test this out.

The screenshot below shows what happens if you are your own approver. You’ll see there is nothing in the Reviewers section.

This screen demonstrate what happens when you set the code owner to another GitHub account: that person will automatically show up in the Reviewers section. There are three indicators next to the user:
- Crescent Moon: username will be requested when the pull request is marked ready for review
- Shield: username is a code owner
- Dot: Awaiting requested review from username
If you have an active license for GitHub Copilot Enterprise you can use Copilot for Pull Requests to generate a summary for the pull request.
When you try to create the pull request, you will see an error indicating that a code owner review is required. As an administrator of the repository, you can bypass the owner review branch protection, but this is a permission only granted to the administrators.
Once the pull request has been merged and closed, you can delete the branch.

Advanced Challenges (optional)

Preventing direct pushes into specific branches like main is a good security practice, but we might wish to take things a step further and introduce manual gating within a GitHub Actions workflow.

Using the .NET deployment workflow you created in Exercise 03, introduce a manual approval step after deploying your .NET web application to the test server and before deploying it to the production server.

Advanced Challenge Solution

Expand this section to view the advanced challenge's solution

In order to require manual approval of a GitHub Actions workflow job, perform the following steps:

Navigate to the Settings menu. In the Code and automation menu, select Environments. If you do not already see an environment named “prod,” select New environment to create a new environment.
If you need to create a new environment, name it “prod” and select Configure environment. If you already have a “prod” environment, select the link.
Select the Required reviewers box and add one or more learners as required reviewers. You may also add team names to the required reviewers list. Then select Save protection rules to apply this change.

Open your .NET deployment YAML file and make sure that you have specified the environment named “prod” in the GitHub Actions workflow job that deploys to production. For example, here is the relevant section from dotnet-deploy-3.yml with the environment included.

 deploy-to-prod:
  
 runs-on: ubuntu-latest
 needs: deploy-to-test
 environment:
   name: prod
   url: https://{your_prefix}-prod.azurewebsites.net/
    
 steps:
 - uses: actions/checkout@v3
    
 - name: 'Login via Azure CLI'
   uses: azure/login@v1
   with:
     creds: $

 - uses: azure/webapps-deploy@v2
   with:
     app-name: '{your_prefix}-prod'
     images: {your_registry_name}.azurecr.io/techboost/dotnetcoreapp:$

Kick off the GitHub Action workflow. Once it reaches the step whose environment is “prod,” the status icon will change to a clock. Select the title of that action to drill into this instance.
For any jobs awaiting approval, you will see the same clock icon. Select the job itself to continue.

If you are an administrator, you may select the Start all waiting jobs button to circumvent the approval process.
The job will indicate that it is awaiting approval. Select the Review pending deployments link to continue.
For each environment requiring review, you may select that environment’s checkbox and leave a comment. Then, select Approve and deploy to unblock the workflow.

Alternatively, you could use the third-party Manual Workflow Approval GitHub Action implement approval.