CICD

Detailed Explanation of SpaceONE CI CD Pipeline and Architecture

SpaceONE CICD Architecture



CI process is mainly processed by GitHub Actions described in .github/workflows directory of each repository. The process can be triggered automatically through events such as pull requests or push, or manually. Continuous integration includes software building, uploading image in docker, and releasing package in NPM or PyPi. Docker Image is built with all dependency packages to include.


CD process is mainly processed by Spinnaker. Spinnaker deployment is triggered by detecting image upload in docker hub. After the triggering event, Spinnaker automatically deploys the microservice to Kubernetes, with Helm chart prepared for each repository to prepare the infrastructure for the deployment.


Role of cloudforet-io/spaceone Repository



Before we discuss the CI process of each repository, we should check the cloudforet-io/spaceone repository (or ‘root’ repository). Root repository serves a role as a trigger of all repositories to start the CI process. Through manually starting one of the GitHub Action the root repository has, most of the repositories detect the action and their GitHub Action is triggered.


Repository Categories


SpaceONE repositories can be divided into 5 different categories based on their characteristics in CI/CD process.


  1. Frontend microservice
  2. Backend microservice
  3. Backend Core microservice
  4. Frontend Core microservice
  5. Plugin
  6. Tools

Core microservices are differentiated with ordinary microservices, since they support the other services by serving various functions such as framework, library or system.


CategoriesRepository
Frontend microserviceconsole, console-api, console-assets, marketplace-assets
Backend microservicebilling, config, cost-analysis, cost-saving, identity, inventory, monitoring, notification, plugin, power-scheduler, secret, spot-automation, statistics, supervisor
Backend Core microserviceapi, python-core
Frontend Core microserviceconsole-core-lib, spaceone-design-system
Pluginplugin module repositories (excluding ‘plugin’ repository)
Toolsspacectl, spaceone-initializer, tester

** Some repositories might not fit in the categories and standards. To check more details in CI/CD, check our GitHub repositories' .github/workflow files.


Versioning System


SpaceONE uses 3 digit versioning system in the format of ‘x.y.z’. The version scheme is displayed in the table below.

CategoryFormatDescriptionExample
Developmentx.y.zdev[0-9]+api, python-core only1.2.3dev1
Release Candidatex.y.zrc[0-9]+Every release has RC during QA1.2.3rc1
Final Releasex.y.zOfficial Release version1.2.3
Hotfixx.y.z.[0-9]+Hotfix of Final Release1.2.3.1

Released Packages & Images


Packages and images released in CI process can be found in the links above.


Continuous Integration Process



CI process of each repositories can be organized by 4 different kinds of triggering events.


  1. Master Branch Push :
    If the master branch in GitHub get pushed, GitHub Action occurs by CI_master_push.yml file, which builds the software and uploads to the registry such as Docker or NPM. After the process, CloudONE team is notified through Slack.

  2. Create Release Branch :
    Each repository can create release branch manually or by cloudforet-io/spaceone repository’s event. After initialization, GitHub Action triggers branch tagging action.

  3. Branch Tagging :
    By being triggered by the event above or getting pushed with version tags, each repository can tag branch with GitHub Action by updating the version in both local and master branch, building the software, and uploading the output to registries such as Docker or PyPi. After all process is done, Slack notification is automatically sent to CloudONE team.

  4. Reflect Branch Update :
    The last CI process to be described is updating the version file in the master branch of each repository. This process is triggered by the branch tagging action or cloudforet-io/spaceone repository GitHub Action.



While most of the process can be explained with the description above, Continuous Integration processes differ by the repository categories described above. To learn about CI of each repository type, visit the document linked below.