Skip to content

6. Possible workflow

Jump to bottom
Sergey Krasilnikov edited this page Feb 13, 2024 · 1 revision

The best approach for possible GitHub workflow could be described with the next steps:

  • Auto CI/CD builds of the 'release' branch should be userd for public releases;
  • Auto CI/CD builds of the 'development' branch should be used internally;
  • The 'hotfix' branch should be use for quick fixes after the release;
  • Personal development branches, like 'dev1/feature1' and 'dev2/feature2' should be forked from 'development' for implementing features;
  • When work inside the personal branch is finished, it should be merged into 'development' and pushed;
  • After pushing changes to 'development', CI/CD will prepare an auto build with a unique build number for internal use;
  • When the 'development' branch is ready to be merged into 'release', a pull request to the 'release' branch should be created;
  • After passing all checkings the PR could be merged into the 'release' branch;
  • After merging to 'release', CI/CD will prepare an auto build with a unique version number for public release;
  • Also, the changed that were merged will be pushed to the 'hotfix' branch in order to be up to date with 'release';
  • If some quich fixes or changes necessary, they could be implemented inside the 'hotfix' branch;
  • Then a pull request should be created to add quick fixes to the 'release' branch;
  • After passing all checkings the PR could be merged into the 'release' branch;
  • After merging to 'release', CI/CD will prepare an auto build with a unique version number and a hotfix number for public release;

Every commit after a pull request into the 'release' branch will have its own version tag and related build artifacts, which could be used to publish a release inside a GitHub repo.

Clone this wiki locally