In this lesson, you will learn how to implement blue-green deployment patterns for systemd unit files to safely transition your automation logic between versions without downtime or service instability.
The Concept of Blue-Green Unit Deployments
In a traditional deployment, editing a live systemd unit file and running systemctl daemon-reload can be risky; a syntax error or a logical flaw might crash an active automation task. The blue-green strategy mitigates this by maintaining two identical service definitions: the "Blue" (current/stable) environment and the "Green" (new/candidate) environment.
Instead of overwriting your service, you version the units (e.g., backup-v1.service and backup-v2.service). You keep only the stable version active, deploy the new version alongside it, and swap traffic or control flow only after confirming the new unit is healthy.
Implementing the Swap
For automation tasks—especially those triggered by timers—you can use the OnCalendar property to your advantage. Rather than editing the active unit, you create a new one:
# /etc/systemd/system/task-green.service
[Unit]
Description=Automation Task Version 2.0
[Service]
ExecStart=/usr/local/bin/automation-v2.py
Once the "Green" unit is defined, verify it with systemd-analyze verify /etc/systemd/system/task-green.service. To perform the switchover, you disable the timer for the "Blue" unit and enable the timer for the "Green" unit:
systemctl disable --now backup-blue.timer
systemctl enable --now backup-green.timer
By leveraging systemd target dependencies, you can also group these units. If the "Green" unit fails, you can immediately revert to "Blue" by simply re-enabling the previous timer, which provides an instant rollback path. This decoupling of the unit definition from the active execution state ensures that your automation infrastructure remains predictable and resilient during updates.
This pattern ensures that you never rely on a single, mutable file that could be broken during a deployment. It forces a clean separation between the stable production state and the experimental candidate, making your automation lifecycle repeatable and safe.
Key Takeaway: By versioning your systemd units and using timer-based activation, you can create a safe, reversible deployment pipeline that eliminates the risk of breaking active automations.