1.0.0

GitOps

Constraints

Branches

Main branches

  • Master for production

  • Develop for next release

master branch always represent stable, production ready code. last commit on master is always the tag commit.

We use develop branch for automatic building jars and docker images then publish to nexus and GCR via Continuous Integration(CI) process. We use master branch for automatic deployment to integration GKE cluster/namespace via Continuous Deployment(CD) process.

Supporting branches

  • Release naming release/#.#.#

  • Feature naming feature/*

  • Hotfix naming hotfix/*

Supporting branches are temporary. after merging, they get deleted.

Restrictions

Restrict commits directly to master branch except merges by Release Manager role Restrict commits directly to develop branch, and allow only PR mergers.

Do's and Don'ts

  • Don't push code directly to master branch

  • Don't push tags directly to master branch

  • Don't push code directly to develop branch

  • Do make a feature/* branch from develop branch

  • Do merge feature/* branch to develop branch via PR process.

  • Release: When develop branch is stable, create release branch i.e., release/0.1.0

    • Do create CHANGELOG.md and commit on release branch

    • Do merge code commits from release branch to develop and master branch

    • We shouldn't merge any features directly to the release branch

    • We should only add bug fixes and release note, changelog to release branch.

  • Hotfix: If you need to patch a release,

    • Do make a hotfix/* branch from master based on specific tag or head of the master branch

    • Do merge code commits from hotfix/* branch to both develop and master branches via PR process.

  • Push feature branches back to origin repo so others can collaborate

  • Use the GitHub/BitBucket website to create pull requests from feature branches

  • Don’t accept your own pull requests!

CI/CD Automation

Following actions are triggered on CI (jenkins, github actions)

  • When code commits pushed to feature/* branch

    • Automatic code review: CI run code quality checks(run unit tests, linting, code coverage, code quality checks with sonar )

    • CI continuously check code quality with each push and update build status on BitBucket or GitHib PR

    • When CI checks pass, Developer crete PR to merge feature/* branch to develop branch

    • Approvers do code review and merge the PR. Finally delete feature/* branch

  • When PRs merged from feature/* branch to develop branch

    • CI run build step (build jars, build docker images with next SNAPSHOT version)

    • Here the computed version looks like 0.2.1-SNAPSHOT

    • CI run publish step (publish jars to Nexus, publish docker images to GCR)

    • CI run deploy step (deploy new images to integration GKE cluster via helm i.e., helm upgrade bigfoot/core --version=$VERSION -f config.yaml)

    • CI run e2e test step (run ??? ), targeting qa GKE cluster/namespace

  • When code commits pushed to release/* branch

    • Above feature/* steps will also apply to release/* and hotfix/* branches

    • In addition, we can also automatically generate Changelog and Release notes.

  • When release/* branch merged to master branch and tagged

    • CI run build step (build jars, build docker images with stable version from Latest/Highest git tag on master branch)

    • Here the computed version looks like: 0.2.0

    • CI run publish step (publish jars to Nexus, publish docker images to GCR)

    • CI run deploy step (deploy new images to integration GKE cluster via helm i.e., helm upgrade bigfoot/core --version=$VERSION -f config.yaml)

    • CI run e2e test step (run ??? ), targeting integration GKE cluster/namespace

PreviousAdvancedNextGradle

Last updated