Community forum

Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


jmccord
2014-02-06T22:44:12Z
Noticed that in VC_Settings that the Jobs.xml contains the information about the job setup within Visual Cron.

We would like to setup a simple/repeatable processing for migrating new jobs between two seperate servers (One being development / the other production).


Is it possible to import a snapshot of the jobs from one instance(dev) into another instance (prod) providing a means to sync the environments.

Initial thought was to migrate the jobs.xml to provide this functionality but VC may have binding to a particualar server that would make that difficult.

Please provide direction.
Sponsor
Forum information
Support
2014-02-06T22:46:54Z
It is pretty easy to schedule export and manually import. But it is also quite easy to use the VisualCron API to connect to one server and extract information an then connect to other server and import. Probably not more than 20 lines of code.

An alternative is to use the API to write an application that syncs all objects in realtime. There are events for all changes in the API but this probably takes a little more time.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
KJDavie
2014-02-06T23:53:58Z
Hi,

We do this regularly, from development & test to a variety of production servers.

We also schedule regular pushes of backups of this information onto a NAS for Backup, Reuse & DR purposes.

I would note that 'cherry picking' just jobs becomes difficult in practice because you often need other xml / objects to maintain the integrity of the job on the target server. i.e. you need to be thinking about variables, notifications, credentials, ftp connections, connections, certs, pgp etc not just jobs.

At this stage we do this via the client, rather than the API for the above reasons.

Also you need to consider and be consistent how you master information.

For example migrating users (so they have the same GUID everywhere, not creating them in each). This is commonly seen when you migrate a job created by a user that has been created again in another server rather than migrated <see attached screen print>
KJDavie attached the following image(s):
Scroll to Top