@arisan/clio-ver v0.1.7
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 tostaging
.fea:
increments MINOR portion by 1 since last release version tostaging
.xxx:
increments PATCH portion by 1 since last release version tostaging
.
(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.