Cloud Native 18 min read

Spock: Qiniu's Continuous Delivery Platform – Architecture, Business Flow, and Best Practices

The article presents Qiniu's Spock continuous delivery platform, detailing its business and technical architecture, pipeline stages from self‑test to release, automation practices, microservice challenges, quality gates, and operational metrics that enable fast, reliable cloud‑native software delivery.

High Availability Architecture
High Availability Architecture
High Availability Architecture
Spock: Qiniu's Continuous Delivery Platform – Architecture, Business Flow, and Best Practices

Li Qian, head of Qiniu's Engineering Efficiency Department, graduated from Zhengzhou University in 2009, built the company's quality assurance system from scratch, and now leads the team that created the Spock continuous delivery platform.

Spock is built on Qiniu's own container product (Kirk) and is named after the logical science officer from Star Trek, reflecting a spirit of fearless exploration.

Scenario & Pain Points

Qiniu has operated for seven years with six core product lines, over 500 components and micro‑services, making its compile and runtime environments complex. The company uses Go (versions 1.1‑1.9), multiple package managers, and requires high release frequency, which demands robust CI/CD tooling such as GitHub/GitLab, Jenkins/Travis, qtest/qappium, Jira, and Confluence.

Ensuring rapid verification of customer scenarios and reliable release readiness is the key challenge.

Spock Business Architecture

Figure 1 shows Spock's pipeline divided into development, testing, and release stages, primarily operated by developers (or SREs).

Self‑Test

Figure 2 illustrates a self‑service testing environment where developers submit a PR, triggering Spock Build, unit tests, static analysis, and optional deployment for rapid verification.

Integration

Figure 3 shows the integration pipeline where QA aggregates multiple PRs for broader testing; integration cycles occur weekly.

Release

Figure 4 depicts the release flow, where the master branch triggers a final Spock pipeline with a full test suite before production deployment.

Spock Technical Architecture

Figure 5 shows the technical stack: Jira for requirement tracking, MQ for task queuing, Reaper for Go compilation (with a custom plugin that stores artifacts in Kirk's registry and Qiniu Cloud storage), Kirk for container orchestration, and Pandora for real‑time log analytics.

Best Practices & Reflections

Automation & Informationization

Automation of the entire pipeline—including demand, code, and test management—reduces manual effort, speeds releases, and maintains quality, especially when QA resources are limited.

Self‑Test Environment & Docker

Docker provides isolated, one‑click test environments, making integration testing easier and more reliable.

Micro‑service Challenges

Micro‑services improve modularity but introduce challenges in container configuration and security; template‑driven configuration and a centralized config center help mitigate these issues.

Release Transparency

Spock automatically creates a release issue linked to the PR, allowing developers, ops, and QA to monitor release status in real time.

Quality Gates

Different quality checks (unit tests, static analysis, integration tests, pre‑release checks) act as gates; failure at any gate blocks progression, embedding quality into the workflow.

Quality Dashboard

Metrics collected from CI/CD and JIRA (e.g., test coverage, code compliance, pipeline pass rate, MTTR) are visualized on a dashboard to drive continuous improvement.

Figure 7 illustrates the quality‑gate workflow.

The article concludes that combining automation, containerization, and data‑driven quality metrics enables Qiniu to achieve high‑frequency, low‑MTTR releases, positioning Spock as a robust cloud‑native continuous delivery solution.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud Nativeci/cdMicroservicesAutomationDevOpsContinuous Delivery
High Availability Architecture
Written by

High Availability Architecture

Official account for High Availability Architecture.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.