Hi experts,
Would you please be able to share your experiences with setting up automated deployment of DataStage, Information Analyzer and ISD jobs? What is the best approach these days?
We will have 2 release Microsoft TFS Servers to support our non-Prod and Prod ETL servers. Looking to avoid installing IIS client on these release servers if possible but still need to be able:
- deploy IA and DS jobs at minimum
- compile DataStage jobs on target server after deployment automatically
- capture deployment/compilation status logs
Regards,
Novak
Automated deployments using Team Foundation Server?
Moderators: chulett, rschirm, roy
Novak, our protocol as an example:
Code and unit test in DEV, export design only.
Import design to INT (integration), compile and test.
Export design and executable from INT.
Import design and executable to SAT/CAT (test).
Run final tests.
Export design and executable from SAT/CAT (or, with no test fails, use the export from INT), for import to PRD.
Code and unit test in DEV, export design only.
Import design to INT (integration), compile and test.
Export design and executable from INT.
Import design and executable to SAT/CAT (test).
Run final tests.
Export design and executable from SAT/CAT (or, with no test fails, use the export from INT), for import to PRD.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
Hi guys,
I have not explained this well.
The focus is on the automated deployment tools, ie. Jenkins, Mamboo or TFS in our case.
What are some of the best practices these days.
An option could be to have IIS objects:
1) compiled
2) exported
3) stored into version control
4) tagged with the relevant release ID (or sprint name)
but what would be the best approach beyond that? TFS can only use istool if IIS client is installed on its server. Or can istool be accessed from release server remotely?
Cheers,
Novak
I have not explained this well.
The focus is on the automated deployment tools, ie. Jenkins, Mamboo or TFS in our case.
What are some of the best practices these days.
An option could be to have IIS objects:
1) compiled
2) exported
3) stored into version control
4) tagged with the relevant release ID (or sprint name)
but what would be the best approach beyond that? TFS can only use istool if IIS client is installed on its server. Or can istool be accessed from release server remotely?
Cheers,
Novak
-
- Participant
- Posts: 527
- Joined: Thu Apr 19, 2007 1:25 am
- Location: Melbourne