We have three new servers that I'm setting up VisualCron on - DEV, QA, and PROD. Are there any recommendations for how to handle revision control for VisualCron jobs? The different versions of the job typically will reference different connections, different filesystem locations, different credentials - but will otherwise be the same. How are people keeping track of these differences?

If you develop on one server, do you just clone and edit and use naming conventions, save your QA or PROD version, and then export and import to the next environment?

Similar question for VisualCron configuration objects like connections, notifications, conditions, etc.

Thanks for any advice!

Rebeccah

Hi Rebeccah,

I cannot answer for all but my experience talking with different customers have seen different solutions;

1. only importing/exporting certain settings
2. using Variables in the global objects

Now, this can cause problems if the object id is not the same. For example, you need to create the Connection on Server A, use it in Task on Server A. Then export both to server B. Now, you can edit Connection on Server B and next time you just export Jobs (and not Connections) - until you have a new Connection.

Now, we have some ideas in mind to simplify this. We have started working on designing the new Master/Slave relationship and one part of that is the Sync. The idea is that you could set sync, that is subscribing to changes on certain objects between two servers. So, for example you could start syncing all Connections. Then you just sync "Add" and not "Update" between server A and B. And for Jobs you can sync everything all the time. This is still in the design phase so please make your comments about this.

---

When you export/import, are the object IDs hardcoded/the same on the two servers, or does the import process create new object IDs for the imported objects?

I may have to make greater use of variables in my jobs.

Can you use variables to hold object IDs?

Thanks,

Rebeccah

Hi Rebeccah,

1) We Do Import a Master Set of Settings whenever we create a new server, including Consistent Server Paths, Log Locations etc.
This includes some common "Housekeeping" Jobs we run on all servers (Backing up settings for example to a common HA SAN location *away* from all the servers.

2) We are careful with a number of Globals (Users, Global Variables) to set these up once and deploy/promote, rather than create in multiple spots to manage the Object IDs consistently - Object IDs will be a Problem otherwise when you deploy jobs between Servers using Global Objects.
3) For some of these variables where we thought it made sense we do have 'Dev' 'Test' and 'Prod' Versions of variables where we have to and switch between them if we have to deploy a job between environments. . . . for others we use the same common global variable and change it depending on environment / server
4) We have Common Notification Templates and Time Exceptions that we deploy also with these Settings.
5) For Formal Scripts and Key SQL we Deploy these consistently & Promote these through the servers where they are controlled from VisualCron.
6) We also, for those spots where we have code 'snippets' we have an VisualCron API (Powershell) Script we run from a Master Server that trawls through all our servers - jobs - tasks and Outputs Powershell Text and Command Line / Arguments / Working Dir for Execute Tasks and then checks them into a <Mercurial> Repository.


We also have some housekeeping jobs we deploy only as necessary (such as the triggers to monitor and notify whenever any triggers get switched or deactivated - these we just deploy where we need to.


Regards

K

Thanks, K.
I have some questions for you...

1. What do you mean when you say you "deploy/promote" certain Globals, rather than creating them in multiple spots? Is deploying/promoting them different from importing them?
2. I haven't used the VisualCron API at all - can you explain a little bit how you are using it in your item #6?
3. Is it possible (I assume it must be) to export/import just one object or a small set of them, rather than only an entire class of objects at a time? And importing doesn't delete anything, just adds or overwrites?

Thanks,

Rebeccah

Hi Rebeccah,

1. What do you mean when you say you "deploy/promote" certain Globals, rather than creating them in multiple spots? Is deploying/promoting them different from importing them?
- Correct, sorry if the terminology confused. So if a new Global Variable (or Condition, Connection, Notification etc) is required with a new/existing job then it is Created in Dev then 'migrated' through the environments using selective export / import (in your case Dev then QA then Prod). This keeps the Object ID (GUID) of the Objects consistent between the environments. Not all jobs, but certainly the larger / more complicated / critical ones, or the ones we want to work on multiple servers.
- Basically Create Once and Export/Import it wherever else you need it.
- Same thing with Users . . .
- Not a perfect way to do this . . . . measure 3 times cut once comes to mind . . .
- Through the Client when connected to multiple servers works well also where appropriate for Jobs for example

2. We don't use the API a Lot. For us, Parameter passing to powershell has come a long way. You will find more extensive users in the forum, but we do use it a bit (for us from PowerShell). For us it allows us to perform extracts of various visualCron Job and Task Information, or Variables via scripts or programs, for use in scripts / elsewhere but you will find other users doing far more extensive changes to visualcron via the API, particularly if you need visualcron to change, and programmatically rather than via a user change.
So basically the API allows us to connect via a program or script to a visualcron server and then use the object model to access / extract and update the Jobs, Tasks, and Global Objects (Variables etc).

In my example above, we wanted to make sure any code / command lines / Parameters that may only exist in VisualCron are extracted and managed . . . as depending on your Volume of Jobs you can only keep history (and Audit Trails for Changes) around for so long . . .
VisualCron Help provides some more details on the API, and there is an API folder under the installation folder. If you are a .net shop or have an interest then it might be worth a look. We are also aware of the Web API but have not progressed with that as yet, as the existing API is doing what we need.

3. Correct, we rely on *very* selective exports and imports to move these jobs/objects around when we need to. This is a good way to move a job back to another <test> server to investigate issues if you need to. Its also a way to grab something out of a backup.
You may not be this disciplined about all your jobs / servers, but we certainly have more complicated / critical jobs where we are very structured about how they are handled. Good examples of this are any jobs interacting with Banks / Payment Providers . . . . or Jobs dealing internally with particular key systems / databases which may also have Dev / QA / Production setups.
For some jobs we have version numbers as part of the Job name also if the change is major / critical . . . . so v1.0 of a job might be live in Production (Paypal for example) and we may clone a job and have a changed v2.0 moving through Dev / QA / Production, allowing us to manage the cutover and have v1.0 disabled for a short time during transition and support a clean reversion if you need one. This is very much the minority though ! . . . but would often mirror where the scripts or programs the jobs and tasks are controlling may be versioned . . . and potentially quite different (parameters passed for example) between versions.

Happy OCD Day 😎

Hope this helps

Kevin

When you export/import, are the object IDs hardcoded/the same on the two servers, or does the import process create new object IDs for the imported objects?

I may have to make greater use of variables in my jobs.

Can you use variables to hold object IDs?

Thanks,

Rebeccah

You do not need to use Variables. Ids will remain the same. Only time a new Id is created is when adding an object that does not exist from before. Just confirming this. This means that you can easily export/import objects.

---

In our environment, each of our servers operate a single environment (dev/test/qa/uat/prod). We configure each of those servers using a set of environment variables which controls paths, connections, etc which we use for all processing on that machine (VC related or not). For VC, we setup the connection and credential once (on server setup) using a single file and modify to the appropriate values so that the GUID (id) defining the object is the same across all environments. For the jobs, all input parameters and variables are defined using the environment variables. This allows us to create an extract from a single environment, check that into our source code control and deploy to every environment: The jobs themselves have nothing environment specific. As the GUIDs for the dependent objects are the same in all environments, the jobs will automatically use those objects once installed. (If you look at the jobs exports, they only link via the GUID and not the actual content of the dependent objects, such as credentials or connections).

We currently do not use the export functionality as I've struggled to get it to work: KJDavie, I had an open topic regarding this and would be interested to see how you're using the API to export. We do use the API as part of our automated deployment to inject the jobs into the VC environment.

Hope this helps!

Thank you, everyone for posting your experiences.

Rebeccah