Control-M code deployment best practices
Posted: 04 Sep 2009 9:19
Hi There,
I am quite new to Control-M and I am into this project where they use a very unique way of deploying the control-m xml into production as part of every new release of our application.
1. Every time there is a new release, we generate the complete control-M xml file containing all the jobs using a custom built shell-script based tool.
2. This tool takes some excel sheets(with job dependencies and other relevant etc) as inputs and comes out with a complete XML for all the 3000 jobs.
3. Even if there is 1 new job as part of release, we need to completely generate this new xml and deploy in production. (well, this is how its been for the past 7 years)
4. Once the xml's are ready, we purge and do a complete upload for all the 3000+ jobs in production.
This approach is causing us huge problems lately because of wrong xml generations etc.
Now, I would like to understand various ways of moving the control-m code(may be xmls or something else) from one environment to other and kindly let me know if there is an industry-wide best practice that is followed.
Also, is there any best way of maintaining the code(xml or something else) in any configuration management tools?
By the way, we use Control-M 6.3 on unix. Please apologize if i missed to give you any obvious information that I should have. Its just lack of knowledge.
Thanks Guys!
Kondal
I am quite new to Control-M and I am into this project where they use a very unique way of deploying the control-m xml into production as part of every new release of our application.
1. Every time there is a new release, we generate the complete control-M xml file containing all the jobs using a custom built shell-script based tool.
2. This tool takes some excel sheets(with job dependencies and other relevant etc) as inputs and comes out with a complete XML for all the 3000 jobs.
3. Even if there is 1 new job as part of release, we need to completely generate this new xml and deploy in production. (well, this is how its been for the past 7 years)
4. Once the xml's are ready, we purge and do a complete upload for all the 3000+ jobs in production.
This approach is causing us huge problems lately because of wrong xml generations etc.
Now, I would like to understand various ways of moving the control-m code(may be xmls or something else) from one environment to other and kindly let me know if there is an industry-wide best practice that is followed.
Also, is there any best way of maintaining the code(xml or something else) in any configuration management tools?
By the way, we use Control-M 6.3 on unix. Please apologize if i missed to give you any obvious information that I should have. Its just lack of knowledge.
Thanks Guys!
Kondal