When you update job logic in SchedulerX, deploying directly to all workers risks impacting production workloads. SchedulerX supports label-based canary release, which routes jobs to a subset of workers for validation before a full rollout.
How it works
SchedulerX workers report labels to the server through heartbeats. Each job can target workers that carry a specific label, either through static configuration or at runtime. This label-based routing is the mechanism behind canary release.
The workflow:
Assign labels to workers -- for example,
grayfor canary andprodfor production.Route a job to
gray-labeled workers for testing.Verify the results.
After successful verification, promote the change to
prod-labeled workers.
Choose an approach
| Approach | When to use | Rollback |
|---|---|---|
| Dedicated canary job | Ongoing canary testing -- you need a persistent canary job running alongside production | Delete the canary job; the production job continues unchanged |
| One-time canary run | Quick pre-release verification -- test a single execution on canary workers without duplicating the job | No rollback needed; the production schedule is unaffected |
Assign labels to workers
Workers must have labels before you can use label-based routing. SchedulerX supports two methods.
Set labels at application startup
Specify labels through the Properties configuration. The following example uses a Spring Boot application:
spring.schedulerx2.label=${label}Replace ${label} with the target label value, such as prod or gray.
Inherit labels from EDAS or MSE traffic tags
If your application runs on Enterprise Distributed Application Service (EDAS) or Microservices Engine (MSE), traffic labeling automatically applies labels to SchedulerX workers. No code changes are required -- workers inherit labels from the traffic tags configured in EDAS or MSE.
This method is useful when you already use end-to-end canary release in MSE, because SchedulerX workers pick up the same labels without additional configuration.
Create a dedicated canary job
Copy the production job to create a separate canary job, then assign labels to isolate traffic between them.
Add the
prodlabel to the production job.Copy the production job to create a canary job.
Add the
graylabel to the canary job.Run the canary job to validate on
gray-labeled workers.
After verification succeeds, update the production job with the validated changes and remove the canary job.
If verification fails, delete the canary job. The production job continues to run on prod-labeled workers without interruption.
Run a one-time canary test
To verify a single execution on a canary worker without duplicating the job, manually trigger the existing job on a specific label in the SchedulerX console.
In the SchedulerX console, locate the job.
Select run the specified label once and choose the
graylabel.The job runs once on the
gray-labeled worker. The regular production schedule continues unchanged onprod-labeled workers.
Automate the one-time run with CI/CD
Use continuous integration tools such as Jenkins to trigger the one-time canary run automatically. This integrates canary verification into your deployment pipeline so that each release is validated on canary workers before promotion.
