OuroDev Git Workflow: Difference between revisions
Created page with "To facilitate the creation of a stable client and server, development of i24 towards a Volume 2 stable release will follow the following agreed upon development lifecycle. ==..." |
Updated the description of the dev workflow |
||
| Line 1: | Line 1: | ||
The following agreed upon development lifecycle describes the workflow used for working with and delivering code for Volume 2. | |||
== Branch | == Branch organization == | ||
The main/origin development repo shall be [https://git.ourodev.com/CoX/Source CoX/Source] | The main/origin development repo is [https://git.ourodev.com/CoX/Source CoX/Source]. | ||
The other important repo is [https://git.ourodev.com/CoX/Source CoX/Assets]. | |||
=== 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 [https://git.ourodev.com/CoX/Source 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 [[#PR submission rules|the PR submission rules]] for what is required to merge a PR into the develop branch. | |||
=== | === Master branch === | ||
The | 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 | === Release tags === | ||
Each | 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 == | == PR submission rules == | ||
For a PR to be submitted to | For a PR to be submitted to the develop branch, the following criteria must be verified: | ||
# The PR branch must pull from | # The PR branch must pull from develop prior to submitting the PR. | ||
# The PR branch must build. | # The PR branch must build. | ||
# The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature. | # The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature. | ||
# The PR must be reviewed and approved by 2 approved reviewers. | # The PR must be reviewed and approved by 2 approved reviewers. Currently, approved reviewers are anyone with the Mender or Vindicator role. | ||
# All NEW code must follow the [OuroDev Coding Standards] (to be determined) | # All NEW code must follow the [OuroDev Coding Standards] (to be determined) | ||
Revision as of 10:38, 26 June 2019
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. The other important repo is CoX/Assets.
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:
- The PR branch must pull from develop prior to submitting the PR.
- The PR branch must build.
- The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature.
- The PR must be reviewed and approved by 2 approved reviewers. Currently, approved reviewers are anyone with the Mender or Vindicator role.
- All NEW code must follow the [OuroDev Coding Standards] (to be determined)