Skip to content
This repository was archived by the owner on Jul 16, 2025. It is now read-only.

GitHub Workflow

Jump to bottom
Charles Hu edited this page Sep 17, 2024 · 2 revisions

Introduction

The follows describes a general workflow for developing a feature/bug fix for this project repository. Most development should follow the following guidelines though rare exceptions may occur which are handled at the discretion of the PM, QA/Tester, and DevOps roles.

These guidelines are non-exhaustive and are subject to change depending on the needs of the project.

Workflow

  1. Ensure that your feature or bug is located in a new feature/bug fix branch. New features/bug fixes should always be first developed and introduced in a branch to prevent the introduction of poor/buggy code to the main branch (and thus the production deployment).

    • You can create a branch either directly on GitHub or by using git.

    • Do not create a fork of this repository. It will break CI/CD functionality which is specifically targeted against this repository in particular.

  2. Create a pull request for your new branch. This pull request serves as a place for other team members to track and review your work.

    • Your pull request should include the following information:

      • A brief description of what is being added in the main comment.

      • An assignment of individuals you want to review your PR as reviewers.

        • All PRs must include @charleshu-8, @BlockadeRunner, and @Pigf00d as reviewers at minimum.

      • The individuals assigned to work on this feature as assignees.

      • Labels to describe the general purpose of your PR.

    • An example of a PR following these guidelines can be seen here.

  3. Regularly commit any operational feature/bug fix progress to your feature/bug fix branch. This helps us know how far along you are in development and allows us to give credit for what you have worked on so far.

    • While not necessary, you can add a -s flag to your commit commands to certify the authenticity of the commit and direct it back to you for authorship.

  4. When you are finished with feature/bug fix development, ping your assigned reviewers to begin reviewing your code and its functionality.

    • The PM, QA/Tester, and DevOps roles can freely review any part of the new feature/bug fix but they must focus on performing the following minimum:

      • PM: Ensure the code is robust, readable, and conforms to the standard conventions of the overall code base.

      • QA/Tester: Ensure that the functionality that is addressed by the new feature/bug fix is operational and does not generate unexpected behavior.

      • Devops: Ensure that the PR passes CI tests/checks and operates as expected in new deployments.

    • In addition to the review, the QA/Tester must concurrently develop tests for any new feature (not bug fix) in a separate PR. That PR is subject to the same rules as outlined in this document.

    • A reviewer can perform a review in GitHub as so.

  5. Once the PR has been reviewed and any applicable tests have been created, the PR can be merged and the branch can be deleted.

  6. The feature should now run through the deployment pipeline and appear on the deployed GitHub Pages site.

Clone this wiki locally