All resources for this project is hosted on GCP (Google Cloud Platform) and uses all resources managed by GCP. For the operator services, all applications are deployed in the Cloud Run environment.
Every service has a healthcheck endpoint at the root path where you can check the status of the service and the current version running.
{ "status": "healthy", "version": "v.0.1.4" }
Normally you should see a healthy value in the status field. When the status value is unhealthy, it means that one or more service dependencies in the service does not work properly.
Service deployment is automated by the GitLab CI/CD through its runner service. A push to master branch will trigger a build and deployment to the development environment and a push to tag will trigger a build and deployment to the staging environment.
Since this project is stored in a Monorepo, deploying the application as a set of services relies on the CI/CD flow of the application. Refer to the .gitlab-ci.yml file for a detailed utliziation of the Gitlab CI with the project.
You will also see two different versioning format in the version value, v.*.* and preview-*. The former is a tagged version of the image, which in most cases has passed the staging environment and should be found in both staging and production environment, while the latter should only be found in development environment since it corresponds to the GitLab pipeline ID of the commit.
sample GitLab pipeline ID. Pipeline #259 will submit to image version v.0.3.63 and pipeline #260 will submit an image version of preview-260
Version tag is used independently in each services. A tag is created when changes or commits are deployed to the development environment and has passed the manual testing by the QA. Upon creating a new tag, GtiLab CI/CD will deploy the tag to the staging environment.
Version tagging is in the following format:
v.[MAJOR-VERSION].[MINOR-VERSION].[REVISION]
Major version only changes on a major API update with breaking changes to the previous version.
Minor version is updated on a major bug fix, optimisation, or a new functionality within the API or service.
Revision number is updated on a minor bug fix or a hotfix for the current version.