OuroDev Git Workflow: Difference between revisions
Updated the description of the dev workflow |
No edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
The following agreed upon development lifecycle describes the workflow used for working with and delivering code for Volume 2. | The following agreed upon development lifecycle describes the workflow used for working with and delivering code for Volume 2. | ||
== Branch organization == | ==Branch organization== | ||
The main/origin development repo is [https://git.ourodev.com/CoX/Source CoX/Source]. | The main/origin development repo is [https://git.ourodev.com/CoX/Source CoX/Source]. | ||
Our data repo is [https://git.ourodev.com/CoX/i2401-bin-server CoX/2401-bin-server]. | |||
=== Feature Branches === | ===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]. | 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 === | ===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. | 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 === | ===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. | 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 == | ===(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. | 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 === | ===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. | 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 the develop branch, the following criteria must be verified: | 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 pull from develop prior to submitting the PR. | ||
# The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature. | #The PR branch must build. | ||
# The PR must be reviewed and approved by 2 approved reviewers. Currently, approved reviewers are anyone with the Mender or Vindicator role. | #The PR branch must clearly provide a feature or bugfix and steps to resolve the bug or test the feature. | ||
# All NEW code must follow the [OuroDev Coding Standards] (to be determined) | #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) | |||
Latest revision as of 09:16, 24 October 2020
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:
- 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)