Hi everyone
It's an established industry practice to validate code changes in a test environment, and then promote the same tested code to production.
Is there a simple method of doing this for Control-M schedules? We have a separate test environment for Control-M, so lots of details are different between test and production (server names, owner accounts, shouts, etc) - so a simple export and import won't work for us. At the moment, we have to rebuild the entire schedule from scratch by hand; we haven't had any problems with this so far, but the risk is quite high and I'd like to remove it.
Best method of promoting tested job schedules to production?
Hi
When you said export/import, is it XML format?
Since 6.4, It could be simple to update Control-M jobs, and use XML format to save it, and to update it using variables.
Best practice, is to generate all jobs, save as XML format.
You could create a script searching fields as [owner], [host] to be replace when you move from test to production.
Anyway all process you will do, will be better than to rewrite jobs anytime.
When you said export/import, is it XML format?
Since 6.4, It could be simple to update Control-M jobs, and use XML format to save it, and to update it using variables.
Best practice, is to generate all jobs, save as XML format.
You could create a script searching fields as [owner], [host] to be replace when you move from test to production.
Anyway all process you will do, will be better than to rewrite jobs anytime.
Best method of promoting tested job schedules to production?
Hi Richard,
I would suggest that you look into a few options (excuse me if you're already utilising these):
1. Using global variables as much as possible to limit the amount of differences in job definitions from Test/Development to Production. You cannot do this for everything, i.e., owner name, but in most cases they will help.
2. Use shout destination tables (if not already) so that you don't have to change the destinations from environment to environment. You can even use global variables if you have a standard set of shout messages and you can even include system variables from the jobs in these.
3. Use node groups to avoid having to change node ids.
4. If you have version 6.4, create a preset 'Find and Update' for every environment change (Dev-to-Test, Test-to_Prod, Prod-to-Dev, etc), so that you don't have to write a script to modify xml files.
Hope this helps.
I would suggest that you look into a few options (excuse me if you're already utilising these):
1. Using global variables as much as possible to limit the amount of differences in job definitions from Test/Development to Production. You cannot do this for everything, i.e., owner name, but in most cases they will help.
2. Use shout destination tables (if not already) so that you don't have to change the destinations from environment to environment. You can even use global variables if you have a standard set of shout messages and you can even include system variables from the jobs in these.
3. Use node groups to avoid having to change node ids.
4. If you have version 6.4, create a preset 'Find and Update' for every environment change (Dev-to-Test, Test-to_Prod, Prod-to-Dev, etc), so that you don't have to write a script to modify xml files.
Hope this helps.
-
RichardPeers
Thanks, chaps. I had been thinking about doing exactly as you suggest, but was wondering if there was a better way. At least using scripted changes to the exported files will be a predictable and tested process.
Regrettably, we are still on v6.3, so the preset "Find and Update" is not yet available to us. I may have to push for an upgrade...
The XML export also brings the possibility of using source code control to track each version of the jobs, which is another concern of ours.
Regrettably, we are still on v6.3, so the preset "Find and Update" is not yet available to us. I may have to push for an upgrade...
The XML export also brings the possibility of using source code control to track each version of the jobs, which is another concern of ours.
-
RichardPeers