Zeva2 Continuous Delivery Structure

Zeva2 Trunk Based Release Model

Learn why this version control management practice is common practice among DevOps teams. https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development

Semantic Release

Fully automated version management and package publishing https://github.com/semantic-release/semantic-release

Conventional Commit

Simple conventional commit messages:

• feat: add export button → Yes (minor release)
• fix: handle null user → Yes (patch release)
• perf: optimize search query → Yes (patch release)
• chore: update dependencies → No
• docs: update README → No
• refactor: simplify auth middleware → No
• test: add user service tests → No
• ci: adjust release workflow → No
• build: bump Node version → No
• style: format lint rules → No

With scopes:

• feat(api): add pagination → Yes (minor release)
• fix(ui): prevent double submit → Yes (minor release)
• chore(ci): update GitHub actions → No
• docs(README): add setup guide → No

Breaking changes:

• feat! : remove legacy endpoint → Yes (major release)
• refactor(auth)! : change token format → Yes (major release)
• feat: remove legacy endpoint + BREAKING CHANGE: ... → Yes (major release)

Semantic release commit message (auto generated by semantic release):

• chore(release): 1.2.3 [skip ci] → No (it’s the release commit itself, and [skip ci] prevents CI)

Husky

A npm package to enforce the conventional commit

Feature Flag

Use feature flags to disable the unmatured feature on prod release

Zeva2 Pipelines

release-dev.yaml

Every commit to main triggers this pipeline. It does the following:

• run the jest test suit
• based on the conventional commit history, the semantic release process decides if needs to create a release
• if there is a new release created, build the images on Openshift Tools namespace
• deploy the images on Openshift Dev environment.

promote-test.yaml

Manually triggered pipelin to deploy the images to Openshift Test

• provide the image version to be deployed
• create the pull request with the version changed in CD Repo
• once the pull request is approved, the version will be deployed on Oepnshift Test environment

release-prod.yaml

Manually triggered pipelin to deploy the images to Openshift Prod. Same logic as the test deployment.