How GrowingIO Built Its CI/CD Pipeline: Lessons for SaaS DevOps

Purpose

This article describes GrowingIO’s CI/CD practices on its SaaS product line, sharing experiences that can be referenced by other teams.

What is CI/CD

CI/CD is a set of automated practices that enable frequent delivery of applications. It consists of Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment.

CI – Continuous Integration

Developers frequently commit code to the main branch; each commit triggers compilation, automated testing, static analysis, and verification before merging.

CD – Continuous Delivery

After CI validates the code, the pipeline automatically publishes the verified build to a repository, ensuring the codebase is always ready for production deployment.

CD – Continuous Deployment

The final stage automatically deploys the application to production, though deployment can be paused for business reasons.

How to Implement CI/CD

Four main approaches:

Purchase a commercial DevOps product or service (e.g., Atlassian, Azure DevOps, Alibaba Cloud DevOps).

Integrate existing internal tools (project management, code hosting, artifact storage) with light custom development.

Adopt open‑source DevOps platforms such as PiggyFish, noting the need for maintenance effort.

Build a custom solution from scratch, suitable for very large enterprises.

Tools Used

Code repository: Phabricator (private deployment).

CI server: Jenkins (supports Pipeline‑as‑Code, Kubernetes agents).

Quality management: SonarQube.

Artifact repository: Nexus.

Deployment tool: Capistrano.

Container orchestration: Kubernetes, Docker.

Source Code Management Strategy

Branch strategy is tightly coupled with CI/CD pipelines. GrowingIO prefers trunk‑based development but falls back to short‑lived feature branches when necessary.

Branch Descriptions

Master : Main integration branch, always release‑ready; direct pushes are prohibited.

Release : Temporary branch for urgent releases when Master cannot be used.

Feature : Active development branch; short lifespan to avoid merge conflicts.

Local : Developer’s personal branch used for diff submission via Phabricator.

Feature Development Process

Features are split into sub‑tasks, each developed in local branches, reviewed via Diff in Phabricator, tested, and merged back to the feature branch before finally landing on Master.

CI Process

Two pipelines:

Feature‑based CI : Jenkins monitors feature branches, runs static checks, unit tests, builds Docker images, and deploys to a dedicated integration environment.

Diff‑based CI : After a Diff is submitted, Phabricator triggers Jenkins to run checks, SonarQube analysis, and reports results back to the Diff.

Release Strategy

Adopts an Agile Release Train with a fixed weekly release cadence, typically on Tuesday evenings.

Quality Requirements

Comprehensive regression testing is performed before each release, with a Code Freeze period where only QA can land changes to Master.

Problems and Shortcomings

Releases are source‑code based, causing long compile times and potential environment drift.

Insufficient automated test coverage, leading to manual checks.

Fragmented CI/CD workflow across emails, DingTalk, and multiple Jenkins jobs.

Blue‑green rolling deployments halve cluster capacity during upgrades, limiting release windows.

Summary

The article outlines CI/CD concepts, the tools GrowingIO employs, and its practical implementation, acknowledging current gaps and future improvements such as binary‑based releases and tighter workflow integration.