Shift Quality to the Left

Introduction

Shift Left is a term used to describe finding defects as early as possible in the software development cycle. From an SDLC view it is putting a focus on pushing quality checks into the planning and design phases, where the costs of building the wrong thing are much lower than if a feature were to be built and it wasn’t what anyone wanted.

SDLC

From a GitHub DevOps perpective, Shift Left is focused on pushing quality checks as close to the individual engineer as possible. This is where the costs of catching defects is the lowest and the impacts to others is the least. It provides an increased confidence that what is in the development branch has met a solid quality bar and is a significant step toward having a quality product.

GitHub

The set of standards in the following sections are subject to change over time as GitHub and third party tools evolve. They are current as of 12/4/2022.

Branches

It is assumed that all development follows the GitFlow workflow (i.e. not Git Trunk).

Branches are provided by default:

  • development - code is merged into development using feature branches and pull requests; code promotes to staging

  • staging - only code from development should be merged into this branch; code promotes to main

  • main - only code from staging should be merged into this branch; production code

  • post-deployment - contains examples of terraform code, basic cicd and Terraform to create a resource group

Pull Requests

A Pull Request is created by an engineer and is the process whereby the engineer wants to have that code promoted into the development branch as part of the product. This code is developed to meet the requirements of a user story or fix a bug.

Pull Request configuration in the GitHub repo settings defaults to:

PullRequest

Though all merge types are supported, it is highly recommended to use Squash merges in order to have a more succinct GitHub commit history.

Automatically delete head branches is on by default so that any feature branches created by developers are deleted when the PR is merged. This keeps the number of remote branches low and reduces noise when managing branches in GitHub. For example, as an engineer I push code from my branch feature\12345-user-auth to development, when the PR is approved and merged, feature\12345-user-auth is deleted from the remote (i.e. the GitHub repo).

Additional settings for Pull Requests are in the Branch Protection Rules.

Quality Checks

At its core, Shift Left is about quality. Required checks enforced in the repo include:

Branch protection rules

Branch protection rules that are on by default for development, staging and main:

  • Ensure Pull Requests are required

  • Ensure Pull Requests require approval by at least one other team member (i.e. code review and approval)

  • Dismiss Pull Request approvals when new commits are pushed. Protects against engineer gets an approval, makes more changes and they don’t get reviewed, since the PR is already approved.

ProtectionRule1

Status checks

As part of the Branch protection rules, status checks are setup to ensure quality. Unit tests are a great example of a very common quality check that should occur. Note: the status checks do not come available in the GitHub UI until they are run the first time in your pipeline.

  • Require status checks to pass before merging. With this checked, if unit tests or other quality checks don’t pass, the code cannot be merged.

  • Require branches to be up to date before merging. Ensures that the code that is being validated includes any recently changed code by other engineers that may not have been there when the PR was originally created.

  • Do no allow bypassing settings. This ensures admins also have to meet the PR rules and can’t direct merge into repos.

ProtectionRule2

Common cases for status checks:

  • Unit Tests (API, UI)

  • E2E Tests

  • Snyk. Static analysis for security issues. Connected to your repo as a Webhook.

Security Analysis

In addition to Snyk, Dependabot and GitHub Advanced Security are configured to look for code issues. Dependabot scans code and informs you of any security vulnerabilities in your dependencies. GitHub Advanced Security will scan for any secrets you have saved in code (instead of in Terraform variables or Azure KeyVault).

The settings below can be a bit confusing at first glance. Options that have a red Disable button are the ones enabled.

CodeAnalysis

Additional Recommendations

GitHub Teams

The Collaborators and teams settings section of your repo is where you grant others access to your repo. By default, anyone within the Seagen org has Read access. In addition, you will have a default group DeploymentReview that is the group of users that can approve a code promotion from your main repo to production.

For others who you want to have more than Read access, such as engineers on your team, it is simpler to have permissions granted by role instead of for each individual user. Creating an Admin team and a Contributors team with Admin and Write permissions, respectively, makes it simple to administer - simply add users to the group to which they need to belong. Here’s an example from OmniVivo:

Teams

Linking Code to Azure DevOps Boards

Each Pull Request should be related to an Azure DevOps story or bug fix. To easily track what code is for which story, the AB#[number] syntax can be used in the Pull Request description. For example, AB#50948 indicates the code in the PR is to address Azure DevOps story #50948. The link is clickable from within the PR and in Azure DevOps, the PR, when merged, will appear as a GitHub Pull Request link in the Development section of the story or bug. More information on Microsoft’s site.

CODEOWNERS

Remember those GitHub Teams you setup? You can make them, or really anyone, a default reviewer. When a PR is created, the owners listed in this simple file located in your .github directory automatically become reviewers of your PR. The file needs to be named CODEOWNERS without a file extension. See GitHub for more info.
Example CODEOWNERS file contents:
* @Seagen/omnivivo-admin @Seagen/omnivivo-contributors

PR Template

A PR Template is a template that automatically appears in the pull request body when an engineer creates a PR. It can contain whatever sections or checklists you think would be beneficial to your team. Here’s an example that prompts the engineer for a summary of changes, the link to Azure DevOps story or bug and any UI screenshots:

PRTemplate

The template is defined as a pull_request_template.md file located in your .github directory. The example contents for the image above:

## Summary of changes

## Story or bug number

## Checklist before requesting a review

- [ ] I have performed a self-review of my code
- [ ] I have added|updated unit tests
- [ ] I have added|updated E2E tests, where applicable
- [ ] No new errors or warnings in the console during execution
- [ ] Consider impacts your code may have on others and communicate them in the summary and/or in Teams
- [ ] Consider whether you should add|update documentation in the repo or in the ADO Wiki

## Screenshots

More information on Pull Request Templates can be found on GitHub

*Images in the introduction section of this page are from https://nonamesecurity.com/whitepaper/active-testing