Streamlining Deployments with a Cloud‑Native CI/CD Platform at Fangduoduo

1. Overview

With the development of container technology and micro‑service architecture, application iteration has become frequent, making traditional deployment processes insufficient for Fangduoduo's daily massive build and release demands. The operations team therefore created an integrated automated release system that unifies project management, machine management, and CI/CD, greatly improving development efficiency.

2. Release System Ecosystem

The ecosystem consists of three parts:

Core release system services

Code repository / CI server

Target clusters

2.1 Release System Core Service Architecture

The system follows a typical front‑end/back‑end separation architecture, exchanging data via JSON.

Front‑end project : built with the lightweight Vue framework, using Vue‑router for page navigation and providing features such as project management, build version management, test cases, and deployment rollback.

Back‑end project : developed in Python, comprising a Web Server and a Worker component. The back‑end uses Celery for distributed task scheduling with Redis as the message broker. The Web Server (Flask + Gunicorn) receives requests from the front‑end, pushes tasks to Redis, while the Worker monitors the queue, executes tasks, and reports progress back to the front‑end.

<code>发布系统后端相关组件均部署在容器集群内部，不管是Web Server、Worker还是消息队列，都可以进行横向扩展，满足研发团队大量并发的构建/发布需求。</code>

2.2 Teamcode / Jenkins Integration

The Teamcode code repository, based on Gerrit, stores source code and provides code review. Jenkins consumes the repository as “raw material” to run pipelines. The Teamcode‑trigger component watches repository commits and invokes the release system’s webhook, which forwards build requests to the back‑end Worker. The Worker uses the Python jenkins library to communicate with Jenkins, creating and executing pipelines based on parameters supplied by the front‑end. Build artifacts are stored in a container image repository.

2.3 Target Machines / Clusters

Most services are containerized; target clusters are therefore container clusters. The release system communicates with clusters via intermediaries. For Docker Swarm, Portainer provides a RESTful API; for Kubernetes, a custom RESTful service built on the client‑go library interacts with the Kubernetes API Server, supporting deployment, updates, deletions, log access, and WebSocket terminal connections.

<code>Client-go封装后的RESTful服务以容器的方式部署，无状态，可横向扩展</code>

3. Release System Features

Project management – create projects and bind to Git repositories.

Permission management – users initially access only their own projects and can request additional permissions.

Version management – record built versions and allow rollback.

Test cases – run selected test cases after deployment.

Application maintenance – view logs, terminal access, health checks.

Canary release – support for RESTful and Dubbo services, adjusting traffic or injecting canary flags.

4. Actual Workflow

Developers create a project in the front‑end, which triggers the back‑end to set up a repository and record information. The Teamcode‑trigger monitors commits and sends build commands to Jenkins. Jenkins executes the pipeline; the back‑end monitors progress and updates the front‑end. After a successful build, developers deploy the service via the front‑end, monitor deployment progress, and finally manage the running service (logs, terminal, health checks).

5. Future Outlook

The release system has already brought significant convenience to development and operations. Future work will focus on more human‑friendly and intelligent CI/CD processes, integrating additional cloud‑native technologies to provide an even more efficient automated pipeline for the entire development team.