OuroDev Git Workflow

From OuroDev
Revision as of 10:16, 24 October 2020 by Chet (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The following agreed upon development lifecycle describes the workflow used for working with and delivering code for Volume 2.

Branch organization

The main/origin development repo is CoX/Source. Our data repo is CoX/2401-bin-server.

Feature Branches

All development for features or bugfixes shall be completed in feature branches that are created from the develop branch. Each dev will be responsible for creating and maintaining their feature branch. To be promoted to the develop branch, a feature branch shall submit a Pull Request (PR) to CoX/Source.

Develop branch

The develop branch is the latest "unstable" or in-development codebase. All feature branches are merged into the develop branch using PRs. See the PR submission rules for what is required to merge a PR into the develop branch.

Master branch

The master branch is the latest "stable" codebase. All releases reside in the master branch. When the develop branch reaches a potential release state, it is merged into master. A tag is then applied to the master branch to mark it as either a release candidate or a final release version.

(Optional) Release candidate tags

Sometimes the master branch will have a release candidate (rc) tag applied to it. This is usually when some additional testing needs to be done before declaring a final release version.

Release tags

Each final release shall be marked in the master branch with a release tag. Most servers should utilize builds from a release tag, as the master branch may sometimes represent release candidates with stable, but incomplete feature implementation. These final release tags are in the form of “v2-i1.0.0”, representing volume 2, issue 1, update 0, patch 0.

PR submission rules

For a PR to be submitted to the develop branch, the following criteria must be verified:

  1. The PR branch must pull from develop prior to submitting the PR.
  2. The PR branch must build.
  3. The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature.
  4. The PR must be reviewed and approved by 2 approved reviewers. Currently, approved reviewers are anyone with the Mender or Vindicator role.
  5. All NEW code must follow the [OuroDev Coding Standards] (to be determined)