Hello community,
I need help figuring out how to promote DataStage code to our different environments from subversion.
Our site has three environments, namely development, test and production. We have integrated them with our svn repository using Information Server Manager and the subclipse plugin. The idea is that we would commit the DataStage code from one environment to the svn repository and from there deploy to another environment.
My questions are:
- Has anyone done this? What are the steps we should follow?
- Is there any way to automate this process?
- Is this an approach others have taken with SVN to support dev/test/prod environments?
Your comments and suggestions are appreciated.
Promote code between dev / test / prod from subversion
Moderators: chulett, rschirm, roy
I too am interested in this thread. I'm in the process of setting up the same framework. These are just my ideas so far as I'm preparing to roll this out for the team.
Obviously have a Dev and Test branches created off of the trunk which is the prod.
Disable developers from logging into the prod environment. All designer development should be done in the dev environment, then committed and promoted up. Otherwise the production environment will just be horrible out of sync, and rolling back or disaster recovery will be painful.
Automation should be possible since all SVN commands can be called from a command line. If you automate the process though, you'll have to declare a blanket conflict resolution. Again this really shouldn't be a problem because the datastage jobs are treated as binary in SVN so it's not like you can really pick and chose which lines of code from two difference versions of a job that you want. Basically it's a all or nothing. So in your automation command you'll want to specify to always "use theirs" when you're doing the merge from Dev -> Test and Test -> Prod because you'll be assuming the newest code is always the one you want.
I haven't yet figured out how I'm going to have a checked out copy of the compiled datastage files and push them to the prod site during the automation. In the eclipse program there's the "Replace from workspace" command which upload from my computer to the server. I still need to figure out a way to automate that portion.
I'm considering if there's a need to have specified "Change Control Admins" who get to select which commits are merge up through test and prod or to just have each developer responsible for selecting which commits should be included each time the automation script runs.
I'd be interested hearing specifics from others how they implemented a code repository/change control process with datastage.
Obviously have a Dev and Test branches created off of the trunk which is the prod.
Disable developers from logging into the prod environment. All designer development should be done in the dev environment, then committed and promoted up. Otherwise the production environment will just be horrible out of sync, and rolling back or disaster recovery will be painful.
Automation should be possible since all SVN commands can be called from a command line. If you automate the process though, you'll have to declare a blanket conflict resolution. Again this really shouldn't be a problem because the datastage jobs are treated as binary in SVN so it's not like you can really pick and chose which lines of code from two difference versions of a job that you want. Basically it's a all or nothing. So in your automation command you'll want to specify to always "use theirs" when you're doing the merge from Dev -> Test and Test -> Prod because you'll be assuming the newest code is always the one you want.
I haven't yet figured out how I'm going to have a checked out copy of the compiled datastage files and push them to the prod site during the automation. In the eclipse program there's the "Replace from workspace" command which upload from my computer to the server. I still need to figure out a way to automate that portion.
I'm considering if there's a need to have specified "Change Control Admins" who get to select which commits are merge up through test and prod or to just have each developer responsible for selecting which commits should be included each time the automation script runs.
I'd be interested hearing specifics from others how they implemented a code repository/change control process with datastage.
Thank you for your answer MrBlack. That's an interesting approach.
I find myself with more questions:
- Is merge the only option that would allow moving the code between environments?
- Using merge means that my flow would be something like this (thinking in moving from Dev -> Test):
Commit from Dev -> Merge Test and Dev in working copy -> Commit merge -> Replace code from Working copy
- Is there a more straightforward way to layout the flow?
Again, comments and suggestions are appreciated and I hope more people can comment on this topic.
Thanks.
I find myself with more questions:
- Is merge the only option that would allow moving the code between environments?
- Using merge means that my flow would be something like this (thinking in moving from Dev -> Test):
Commit from Dev -> Merge Test and Dev in working copy -> Commit merge -> Replace code from Working copy
- Is there a more straightforward way to layout the flow?
Again, comments and suggestions are appreciated and I hope more people can comment on this topic.
Thanks.