clio-ver

Introduction

CLiO, a Software as a Service, is consisted of numerous microservices. Each microservice provides unique functions operating on distributed data with its own load-balancing/redundancy strategy. For this distributed structure of SaaS, a CLiO-specific way of versioning evolves and emerges for its microservices.

This tool provides convenience of managing CLiO versioning.

Deployment branches

Each of CLiO's microservices are deployed through 3 stages corresponding to 3 branches.

master → sandbox

master branch is the main development branch. All feature or fixes are branched from master and merged back in after review. Once merged, code on master branch is tested, version is bumped and deployment happens on sandbox environment essentially making code available for other development activities.

staging → staging

staging merges master when appropriate for acceptance review. Merges are tested then versions are bumped before deployment on staging environment.

production → production

production merges staging when appropriate for going live. Merges are tested then versions are bumped before deployment on production environment.

Versioning

clio-ver follows a subset of rules of Semantic Versioning 2.0.0.

master ⤴ alpha

All merges on master are considered alpha. Alpha version follows this format:

MAJOR.MINOR.PATCH-alpha.INCREMENT

On each merge, clio-ver next inspects git history since last release to staging for any commit type tag.

• xxx* increments MAJOR portion by 1 since last release version to staging.
• fea: increments MINOR portion by 1 since last release version to staging.
• xxx: increments PATCH portion by 1 since last release version to staging.

(xxx indicates any 3-letter commit type tag.)

INCREMENT portion are increased by 1 if the latest MAJOR.MINOR.PATCH version has already satisfied the history since last release.

staging ⤴ beta

All merges on staging are considered beta. Beta version follows this format:

MAJOR.MINOR.PATH-beta.INCREMENT

On each merge, clio-ver next inspects git history since last release to production. If merged alpha version matches previous beta version by MAJOR.MINOR.PATCH, INCREMENT portion is increased by 1. if merged alpha version does not match previous beta version by MAJOR.MINOR.PATCH, merged alpha version is then converted to first beta version with identifier beta.1.

production ⤴ production

All merges on production are considered mature and carries no alpha nor beta status. Production version follows this format:

MAJOR.MINOR.PATCH

On each merge, clio-ver next inspects merged beta version and removes any pre-release identifiers.