# 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 


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://xmlking.gitbook.io/micro-apps/advanced/gitops.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.