Branching.md

Branching

KDActionUtils uses a more complicated branching model, but it gives you more control of the SDLC (Software Development Life Cycle). This branching model allows a clear purpose for adding features, bug fixes, preview releases, QA releases and standard releases.

As a standard contributor, all you have to worry about is creating feature branches and creating pull requests to merge those branches into the develop branch. The rest is taken care of by a solid CI/CD system as well as the maintainers of the project. Only the organization owner and designated team members will manage the release process. So, contributing is very easy!!🥳

NOTE: As you know, everything in software is subject to change, including the branching model. If too many issues or complications occur with the current branching model and/or release process, it will be changed accordingly.

---

Branches Used

Master Branch

Long living branch that represents stable production versions of KDActionUtils:

• Branch Syntax: master
• Branches That Can Merge Into Master:
  • Release branches via pull request
• Created From: none
• Merges Into: none
• Environment: Production
• CI/CD:
  • Upon pull request completion, the release branches are merged into the master branch and are automatically built, tested, and released to production as a nuget package.
  • The testing application is attached as an artifact to the release branch for the purpose of testing.

Develop Branch

Long living branch that represents the most current development in progress:

• Branch Syntax: develop
• Branches That Can Merge Into Develop Branch:
  • Feature branches via pull requests
• Created From: none
• Merges Into: none
• Environment: QA
• CI/CD:
  • Automatically built, tested, and deployed as a QA release upon pull request completion.
  • The testing application is attached as an artifact to the QA release for the purpose of testing.

Feature Branches

Short living branch where a developer's work will be performed and merged back into the develop branch via a pull request:

• Branch Syntax: feature/<issue id>-<description>
  • Example: feature/123-my-branch
• Branches That Can Merge Into Feature Branches: None
• Created From: develop
• Merges Into: develop
• Environment: none
• CI/CD:
  • Build and unit test status checks are automatically run for each change to the pull request.
  • All status checks must pass for a pull request to be completed.

Hotfix Branches

Short lived branch where urgent bug fixes or changes will be performed:

NOTE: Hotfix branches should be carefully reviewed and only performed when the software is considered broken and/or unusable. Changes to this branch should be absolutely minimal and merged directly into the master branch via a pull request.

• Branch Syntax: hotfix/<issue id>-<description>
  • Example: hotfix/123-my-hotfix
• Branches That Can Merge Into Hotfix Branches: none
• Created From: master
• Merges Into: master
• Environment: none
• CI/CD:
  • Build and unit test status checks are automatically run for each change to the pull request.
  • All status checks must pass for a pull request to be completed.

Release Branches

Represents features and/or bug fixes to be released as a production or preview release:

• Branch Syntax: release/v<major>.<minor>.<patch>
  • Example: release/v1.2.3
• Branches That Can Merge Into Release Branches:
  • Preview branches via pull request
• Created From: develop branch
• Merged Into: develop and master branches
• Environment: none
• CI/CD:
  • Can be a major, minor, or patch release.
  • Can be used for preview releases.
  • Preview releases are only done manually.
  • Build, unit test, and version validation status checks are automatically run for each change to the pull request.
  • All status checks must pass for a pull request to be completed.
  • When a release is performed, 2 pull requests are created. One for a merge into the develop branch and one for a merge into the master branch.
  • Upon merging into the develop (QA) branch, a QA release will be automatically performed.
  • Upon merging into the master (Production) branch, a production release will be automatically performed.

Preview Branches

Holds minimal changes for the purpose of upcoming production release stability.

NOTE: Used for refactoring, bug fixes, and changes related to making an upcoming release more stable and to give users the chance to utilize the software and provide feedback before a major release. Introducing major features outside of the changes in the upcoming release are not allowed. These kinds of changes are performed on the preview branch by using preview feature branches.

• Branch Syntax: preview/v<major>.<minor>.<patch>-preview.<prev number>
  • Example: preview/v1.2.3-preview.4
• Branches That Can Merge Into Preview Branches: preview feature branches
• Created From: release branches
• Merged Into: release branches
• Environment: none
• CI/CD:
  • The major, minor, and patch numbers of the preview branch and the release branch it was created from, must match.
  • Build, unit test, and version validation status checks are automatically run for each change to the pull request.
  • All status checks must pass for a pull request to be completed.

Preview Feature Branches

Where a developer's work will be performed when implementing features/changes for a preview branch via a pull request.

• Branch Syntax: preview/feature/<issue id>-<description>
  • Example: preview/feature/123-my-branch
• Branches That Can Merge Into Preview Feature Branches: none
• Created From: preview branches
• Merged Into: preview branches
• Environment: none
• CI/CD:
  • Build and unit test status checks are automatically run for each change to the pull request.
  • All status checks must pass for a pull request to be completed.

---

Branching Diagram