Designing a Multi‑Environment CI/CD Architecture with Jenkins

Automated deployment aims to solve problems such as numerous projects, multiple environments, slow continuous integration, cumbersome deployment operations, error‑prone manual steps, and the need for automated operations.

Jenkins is the leading open‑source CI&CD platform, offering over 1,000 plugins to support building, deploying, and automating any project.

Goals

Support multiple branches, environments, projects, configuration files, and programming languages.

Enable one‑click builds and cluster releases.

Provide one‑click rollback of historical versions.

Allow quick addition of new deployment projects via configuration.

Allow multiple projects to share a single job for publishing or rollback.

Additional optional features include GitLab‑triggered builds, automated testing, DingTalk notifications, email alerts, and more.

Final Effect

One‑click publish

One‑click rollback

Jenkins Directory Design

----jenkins-ex      jenkins build‑time directories
------software      Jenkins installation directory
--------master
--------slave
------backup        Jenkins backup directory
--------master
------module        Functional modules, each sub‑folder holds related files
--------common
----------script    Shared scripts for all modules
------publish       Publish functionality
--------settings
----------config    Build‑time configuration files (e.g., jenkins_profile.pubxml, project configs)
------------test-publish-template-app-config.json   Project mapping config
----------script    Scripts invoked by Jenkins jobs
------source-code   Source code checkout directory
--------test
----------系统标识
------------应用名
------build-result  Build artifacts (compiled results)
--------test
----------系统标识
------------应用名
------temp-file     Temporary files generated during job execution
--------builder-history   Build history records
--------job-params        Parameters passed during build
------app-config    Environment‑specific config files for applications
--------test
----------系统标识
------------应用名
------other-sub-module
……

Naming Conventions and Standards

Jenkins job naming

Job names are all lowercase, words separated by hyphens (e.g., publish-template-onekey-deploy).

Convention: module‑environment‑function (e.g., publish‑test‑onekey‑deploy).

Component jobs within a module: module‑c‑component (e.g., publish‑c‑pull‑code).

Input parameters start with the prefix p_.

Script naming inside jobs

Variables are all lowercase, words separated by underscores.

Other standards

Path variables end with a backslash ( \).

Backup names use # as a separator to simplify parameter extraction (e.g., p_app_key#2019-1219-1503).

Architecture Design

CICD Architecture Diagram

The CICD process runs in two LANs: a build server (development intranet) and a deployment server (production intranet).

Project Mapping Configuration File Design

To enable a single job to publish or rollback different projects via a dropdown, a flexible project‑mapping configuration file is required, as illustrated below.

The configuration includes environment, code branch, deployment path, excluded files, and project information such as unique identifier, directory name, source path, language, and cluster nodes. The app_config node can override parent settings and is an array, allowing easy addition of new projects.

One‑Click Publish Job Design

The "one‑click publish" workflow consists of: assembling project parameters → fetching latest code → building packages → pushing files to servers → backing up the application → copying to a temporary folder → deploying to the target directory.

Key input parameters are illustrated in the following diagrams.

One‑Click Rollback Job Design

During publishing, a record is saved with a key like p_app_key#2019-1219-1503. To rollback, the user selects a historical project, the system extracts the key, retrieves the corresponding configuration, and rolls back to the specified version.

Input parameters for rollback are shown below.

Simple Multi‑Environment CICD Process

Software companies typically have several environments (development, testing, production). The diagram below shows a simplified CICD workflow for each environment.

Trigger strategy

Development environment: manual trigger (or nightly automatic trigger) to avoid excessive builds on every commit.

Testing environment: automatic trigger, as merges are less frequent and can be safely automated.

Production environment: manual trigger to maintain strict control over release timing.

Source: https://www.cnblogs.com/heyuquan/p/jenkins-multi-env-cicd-architecture.html

Recommended reading:

Red‑Black Tree Illustrated with Hundreds of Images

Dada O2O Backend Architecture Evolution: From Zero to 4,000 Concurrent Requests

-END-

Architecture Digest – Large‑scale Websites, Big Data, Machine Learning