> For the complete documentation index, see [llms.txt](https://xmlking.gitbook.io/micro-apps/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://xmlking.gitbook.io/micro-apps/develop-2/advanced/gitops.md).

# GitOps

## Constraints

### Branches

Main branches

* **main** for production
* **Develop** for next release

**main** branch always represent stable, production ready code. last commit on `main` 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 **main** 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 `main` 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 `main` branch
* **Don't** push tags directly to `main` 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 `main` 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 `main` based on specific tag or head of the `main` branch
  * **Do** merge code commits from `hotfix/*` branch to both `develop` and `main` 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 micro/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 `main` branch and tagged
  * CI run **build** step (build jars, build docker images with stable **version** from *Latest/Highest* git tag on `main` 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 micro/core --version=$VERSION -f config.yaml`)
  * CI run **e2e test** step (run ??? ), targeting *integration* **GKE** cluster/namespace