In the article "Don't Want to Give Up Jenkins? You Can Still Be Cloud-Native (opens new window)," we detailed how to quickly improve efficiency and engineer satisfaction by using Zadig while retaining Jenkins. However, while this approach can achieve some significant results, it does not fundamentally address the heavy burden of system maintenance on operations personnel. In practice, managing and maintaining Jenkins involves numerous issues such as plugin compatibility, memory leaks, user permission management, and script maintenance, which require a significant amount of time from operations personnel. Therefore, can Jenkins be completely phased out and all existing tasks migrated to Zadig for execution? The answer is yes. Zadig not only possesses all the functionalities of Jenkins but also automates complex processes in the software development lifecycle.
# What Makes Zadig Workflows Unique?
The Zadig workflow engine was initially built on Kubernetes capabilities, leveraging Kubernetes' dynamic resource allocation to enable concurrent execution of multiple tasks. Compared to Jenkins, this can save at least 50% of resources and improve task execution efficiency by at least 40%.
The design of Zadig workflows aligns more closely with real-world business scenarios and supports the orchestration of any systems and tools involved in the product delivery process, such as project management systems, code hosting platforms, testing platforms, deployment tools, configuration management tools, data management tools, approval systems, and enterprise-built systems. In addition to the basic capabilities of CI workflows (such as cloning code, executing shell scripts, triggers, notifications, and caching), Zadig workflows support the following additional capabilities:
- Support for shared builds, build templates, and serverless resource builds across multiple services
- Support for concurrent builds, deployments, and tests across multiple services
- Support for task status changes, configuration changes, and data changes in project management
- Support for blue-green deployments, canary deployments, phased gray deployments, MSE full-stack, and Istio full-stack deployments
- Support for release process approvals
- Support for building using
Branch,PR/MR,Branch+PR/MR,Tag, orCommitmethods based on actual branch strategies during execution - ..
# Differences in Workflow Implementation Details
| Key Workflow Components | Jenkins | Zadig |
|---|---|---|
| Execution Environment | Manually Created Environment | Extendable Cloud-Native Environment and Dependency Packages |
| Code Information | Decentralized Code Source Configuration | Unified Management of Multiple Code Sources |
| Execution Scripts and Variables | Decentralized Script Writing | Unified Script Configuration Standards |
| Scheduled Triggers | Scheduled Triggers | Multiple Customizable Trigger Strategies |
| Code Change Trigger | Plugin Code Triggers | A Variety of Trigger Strategies |
| Workflow Chaining | Triggering Based on Workflow Status | Service-Oriented Flexible Orchestration and Scheduling |
| Multi-Task Concurrent Execution | Script-Based Concurrency Control | Cloud-Native Task GUI Concurrency Configuration |
| Concurrent Task Quantity Control | Resource Node-Based Concurrency Control | Unified Management of Concurrency Scheduling Policies |
# How to Migrate Jenkins Configurations to Zadig
The following sections detail how to migrate configurations from Jenkins to Zadig, breaking down the process into different stages.
# Comparison 1: Execution Environment
For the environments dependent on workflow tasks, Jenkins requires manually setting up the environment on the corresponding nodes, while Zadig supports managing the basic environment and dependency software packages for task execution. This facilitates platform operations and maintenance to control the basic resources used in business construction, testing, and other processes, ensuring the security and compliance of resources.
The execution environment for Jenkins tasks is specified by selecting the running node in the configuration. The software packages used during task execution need to be installed and managed on the corresponding node.
The execution environment for Zadig tasks is specified by selecting the operating system and dependency software packages in the configuration.
# Comparison 2: Code Information
For internal code sources used in the enterprise, Jenkins manages them in different tasks, while Zadig integrates them centrally by administrators to ensure the security of code sources.
The following example uses GitLab to compare the configuration of code information on Jenkins and Zadig.
Jenkins configures "Source Code Management" to define the code source.
Zadig supports the integration of code hosting platforms such as GitLab, GitHub, Gerrit, Gitee, and other general Git code sources. After integration, it can list the authorized code repository information in the code base, including Branch, PR/MR, Tag, etc., which is more intuitive and user-friendly for developers.
- Step 1: Integrate the code source. Refer to GitLab Code Source Integration (opens new window) for the specific process
- Step 2: Configure code information in the task. Zadig build, test, code scan, and general tasks all support pulling code information.
# Comparison 3: Execution Scripts and Variables
For the definition of service execution scripts and variables, Jenkins manages them in a decentralized manner across different tasks, while Zadig standardizes the service build process through build templates, reducing the burden of operations and maintenance management.
The following example uses a multi-service code repository to build and push images, comparing the differences between Jenkins script writing and Zadig script writing.
The Jenkins execution script and variables are shown in the figure below. The script primarily handles service build, image build, and image push processes. The variables $SERVICE, $VERSION, and $PWD need to be defined in the configuration.
The Zadig execution script and variables are shown in the figure below. Zadig builds have built-in $SERVICE and $IMAGE variables, making the script more concise.
Differences between the two:
- Zadig automatically performs the
docker loginoperation based on the configured image repository during task execution, so there is no need to declare it in the script. - In Zadig, the image naming rules support unified configuration and management. Refer to Policy Configuration (opens new window) for more details, so there is no need to define the generation rules for the
IMAGEvariable in the script.
# Comparison 4: Scheduled Triggers
Scheduled execution of workflow tasks is a common scenario. Jenkins can configure scheduled triggers for the default parameters of workflow tasks. In addition to specifying the trigger time period, Zadig also supports configuring task execution variables, providing more flexibility.
Jenkins triggers support configuring Cron expressions to schedule tasks.
Zadig timers support multiple triggering methods, including timed loops, interval loops, and Cron expressions, to meet various scheduling needs. Additionally, compared to Jenkins using default parameters, Zadig timers allow configuring different workflow execution variables, providing more flexible customization options.
# Comparison 5: Code Change Triggers
Automatically triggering workflow execution when developers submit code is a common practice in Continuous Integration and Continuous Deployment (CI/CD). In Jenkins, this requires relying on plugins. In contrast, Zadig has built-in Git triggers, which do not require additional plugins and can meet various trigger scenarios through flexible configuration, thereby improving overall efficiency.
Jenkins can implement code change-triggered tasks by installing plugins.
Zadig Git triggers support code change triggering by defining code information, trigger events, code file directories, and workflow execution variables. This allows the corresponding workflow to be triggered flexibly and accurately when the code base changes, meeting the execution of various complex automated processes.
In addition to the above two triggers, Zadig also supports various other triggers, including "JIRA Triggers," "Feishu Project Triggers," and "General Triggers." Refer to Workflow Triggers (opens new window) for more details.
# Comparison 6: Workflow Chaining and Orchestration
For some service-oriented tasks within the enterprise, such as security scans, they need to be managed uniformly and used in multiple workflows. Typically, these tasks are managed centrally by security departments or platform teams and then called in various business workflows. To reduce the burden of implementation and subsequent maintenance, a multi-workflow chaining approach is generally chosen to achieve more efficient task scheduling and management.
Jenkins triggers other tasks by configuring "Build Other Projects."
Zadig's workflows are designed in a service-oriented manner, allowing configurations such as testing and code scanning to be centrally managed and easily attached to various workflows. This design makes configuration and management more efficient and allows these services to be flexibly applied in different workflows, improving the maintainability and scalability of the overall workflow.
# Comparison 7: Multi-Task Concurrent Execution
Multi-task concurrent execution is particularly critical in complex software development processes, continuous integration, and deployment. This can significantly reduce engineers' waiting time, improve overall R&D efficiency, and accelerate project progress, enabling more flexible responses to changing needs.
The Jenkins pipeline supports concurrent execution of different "stages." Refer to the following structure for detailed configuration.
pipeline {
agent any
stages {
stage('Build and Deploy Services') {
parallel {
stage('Service 1') {
steps {
echo "构建和部署 Service 1 过程"
}
}
stage('Service 2') {
steps {
echo "构建和部署 Service 2 过程"
}
}
stage('Service 3') {
steps {
echo "构建和部署 Service 3 过程"
}
}
}
}
}
}
The Zadig workflow only needs to turn on the "Concurrent Execution" switch at the "Stage" level to achieve concurrent execution of multiple tasks within the stage.
# Comparison 8: Concurrent Task Quantity Control
Both Jenkins and Zadig support concurrent execution of multiple tasks within the same workflow. Jenkins controls the number of concurrent tasks through resource nodes, while Zadig uniformly manages concurrency scheduling policies and has the ability to flexibly control task priorities.
Jenkins controls the concurrency of multiple tasks by configuring the "number of task executions" on the node. The concurrency of a single Jenkins task can be specified in the task configuration.
Zadig implements concurrency control by modifying the "Task Concurrency Number Setting" in the task configuration. The "Workflow Execution Concurrency Number" controls the number of workflows executed simultaneously, and the "Single Task Service Concurrency Number" controls the number of tasks executed concurrently within the same stage of the same workflow. Additionally, in scenarios where low-priority tasks occupy the global concurrency number, this can be addressed by configuring the "Execution Concurrency Number" of the workflow. Zadig offers more flexible task concurrency control, enabling it to handle complex task concurrency scenarios within the enterprise.
In addition to the above capabilities, Jenkins extends more functionalities through plugins, while Zadig can develop "Custom Tasks (opens new window)" to integrate with enterprise-built systems, meeting the complex processes of the enterprise.
