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
branchDon't push tags directly to
master
branchDon't push code directly to
develop
branchDo make a
feature/*
branch fromdevelop
branchDo merge
feature/*
branch todevelop
branch via PR process.Release: When
develop
branch is stable, createrelease
branch i.e.,release/0.1.0
Do create CHANGELOG.md and commit on
release
branchDo merge code commits from
release
branch todevelop
andmaster
branchWe 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 frommaster
based on specific tag or head of themaster
branchDo merge code commits from
hotfix/*
branch to bothdevelop
andmaster
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/*
branchAutomatic 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
orGitHib
PRWhen CI checks pass, Developer crete PR to merge
feature/*
branch todevelop
branchApprovers do code review and merge the PR. Finally delete
feature/*
branch
When PRs merged from
feature/*
branch todevelop
branchCI 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/*
branchAbove
feature/*
steps will also apply torelease/*
andhotfix/*
branchesIn addition, we can also automatically generate Changelog and Release notes.
When
release/*
branch merged tomaster
branch and taggedCI 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
Last updated