Home›DevOps›Deploying AutoSys JIL to Production Safely: Backup, Diff, Rollback
Intermediate
3 min · November 08, 2026
Deploying AutoSys JIL to Production Safely: Backup, Diff, Rollback
Release AutoSys JIL changes safely: back up with autorep -q, use update_job (never delete_box to edit), apply with jil, diff before and after, and roll back.
N
NarenFounder & Principal Engineer
20+ years shipping production infrastructure and CI/CD at scale. Drawn from code that ran under real load.
Roll back: a reverse update_job file (old values) written before the release; jil < before.jil re-adds deleted jobs; delete_job anything the release added.
CI/CD: JIL in git, reviewed, applied to test, then production.
✦ Definition~90s read
What is Deploying AutoSys JIL to Production Safely?
AutoSys job definitions are changed by feeding JIL to the jil command. A safe release backs up the current definitions with autorep -q, applies changes with update_job (not delete and re-insert), compares before and after, and has a reverse file ready as the rollback.
★
Editing a JIL release is like renovating one room.
Plain-English First
Editing a JIL release is like renovating one room. update_job repaints the walls. delete_box knocks down the room with all the furniture in it, and your plan only rebuilt the walls.
One JIL file on a Friday, forty missing jobs on Monday. Most JIL release incidents come from using the wrong verb or having no backup. This guide gives a five-step release and the rollback.
Pick the Right Verb
update_job changes only the attributes you list. insert_job creates a new job and fails if it exists. delete_job removes one job. delete_box removes the box and all jobs inside it.
release.jilJIL
1
2
update_job: FIN_BOX
start_times: "02:30"
🎯 Key Takeaway
update_job to change; delete_box deletes everything inside.
Back Up and Diff
autorep -q prints definitions as JIL. Save one before the change and one after, then diff them.
Write the rollback before you release: an update_job file with the current values of everything the release changes. autorep -q writes insert_job, so reloading the backup only recreates jobs that were deleted; existing jobs report that they already exist. Delete jobs the release added with delete_job.
rollback.shBASH
1
2
3
4
5
6
7
8
# rollback.jil, written before the release
update_job: FIN_BOX
start_times: "02:00"
# roll back
jil < rollback.jil
jil < before.jil # re-creates any deleted jobs
echo 'delete_job: FIN_NEW_JOB' | jil
⚠ The backup isn't a full rollback
autorep -q writes insert_job. It restores deleted jobs, but it won't change jobs that still exist.
🎯 Key Takeaway
Rollback = reverse update_job file + backup for deleted jobs.
CI/CD
Keep JIL in git, review diffs in pull requests, and apply the same file to a test instance before production. Run the release with the same backup and diff steps in your pipeline.