This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

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.


1 - Frontend Microservice CI

Detailed Explanation of Frontend Microservice Repository CI

Frontend Microservice CI process details



The flowchart above describes 4 .yml GitHub Action files for CI process of frontend microservices. Unlike the backend microservices, frontend microservices are not released as packages, so the branch tagging job does not include building and uploading the NPM software package. Frontend microservices only build software and upload it on Docker, not NPM or PyPi.


To check the details, go to the .github/workflow directory in each directory. We provide an example of the workflow directory of the frontend microservices with the below link.


2 - Backend Microservice CI

Detailed Explanation of Backend Microservice Repository CI

Backend Microservice CI process details



The flowchart above describes 4 .yml GitHub Action files for CI process of backend microservices. Most of the workflow is similar to the frontend microservices' CI. However, unlike the frontend microservices, backend microservices are released as packages, therefore the process includes building and uploading PyPi package.


To check the details, go to the .github/workflow directory in each directory. We provide an example of the workflow directory of the backend microservices with the below link.


3 - Frontend Core Microservice CI

Detailed Explanation of Frontend Core Microservice Repository CI

Frontend Core Microservice CI



Frontend Core microservices' codes are integrated and built, uploaded with the flow explained above. Most of the workflows include set-up process including setting Node.js, caching node modules, and installing dependencies. After the set-up proccess, each repository workflow is headed to building process proceeded in NPM. After building, both repositories' packages built are released in NPM by code npm run semantic-release.


Check semantic-release site, npm: semantic-release for further details about the release process.


Also, unlike other repositories deployed by the flow from Docker to Spinnaker and k8s, spaceone-design-system repository is deployed differently, based on direct deployment through AWS S3.


To check the details, go to the .github/workflow directory in each directory.


4 - Backend Core Microservice CI

Detailed Explanation of Backend Core Microservice Repository CI

Backend Core Microservice CI process details



Backend Core microservices' 4 workflow related GitHub Action files are explained through the diagram above. Unlike the other repositories, pushes in GitHub with tags are monitored and trigger to do building the package in PyPi for testing purposes, instead of workflow tasks for master branch pushes.


Also, Backend Core microservices are not built and uploaded on Docker. They are only managed in PyPi.


To check the details, go to the .github/workflow directory in each directory.


5 - Plugin CI

Detailed Explanation of Plugin Repository CI

Plugin CI process details


Plugin repositories with name starting with ‘plugin-’ have unique CI process managed with workflow file named push_sync_ci.yaml. As the total architecture of CI is different from other repositories, plugin repositories' workflow files are automatically updated at every code commit.



We can follow the plugin CI process, step by step.


Step 1. push_sync_ci.yaml in each plugin repository is triggered by master branch push or in a manual way.

Step 2. push_sync_ci.yaml runs cloudforet-io/actions/.github/worflows/deploy.yaml.

Step 2-1. spaceone/actions/.github/worflows/deploy.yaml runs cloudforet-io/actions/src/main.py.

  1. cloudforet-io/actions/src/main.py updates each plugin repository workflow files based on the repository characteristics distinguished by topics. Newest version files of all plugin repository workflows are managed in cloudforet-io/actions.

Step 2-2. spaceone/actions/.github/worflows/deploy.yaml runs push_build_dev.yaml in each plugin repository

  1. push_build_dev.yaml proceeds versioning based on current date.

  2. push_build_dev.yaml upload the plugin image in Docker.

  3. push_build_dev.yaml sends notification through Slack.



To build and release the docker image of plugin repositories, plugins use dispatch_release.yaml.

  1. dispatch_release.yaml in each plugin repository is triggered manually.

  2. dispatch_release.yaml executes condition_check job to check version format and debug.

  3. dispatch_release.yaml updates master branch version file.

  4. dispatch_release.yaml executes git tagging.

  5. dispatch_release.yaml builds and pushes to Docker Hub with docker/build-push-action@v1

  6. dispatch_release.yaml sends notification through Slack.



For further details, you can check our GitHub cloudforet-io/actions.


6 - Tools CI

Detailed Explanation of Tools Repository CI

Tools CI process details



spacectl, spaceone-initializer, tester repositories are tools used for the spaceone project. There are some differences from other repositories' CI process.


spacectl repository workflow includes test code for each push with a version tag, which is similar to the CI process of backend core repositories.


spaceone-initializer repository does not include the workflow file triggered by ‘master branch push’, which most of repositories including spacectl and tester have.


Tools-category repositories use different repositories to upload.

  • spacectl : PyPi and Docker both
  • spaceone-initializer : Docker
  • tester : PyPi


To check the details, go to the .github/workflow directory in each directory.