Is there a preferred method for implementing VC? Our production environtment has about 460 jobs and 1400 tables descriptions amongst other things. Does it make sense to take a baseline by initializing the Version project with a snapshot of Production?
Or, does it make sense to just start bringing objects down from Production to Version as needed. We have about 10 Full Time DataStage developers and I need to minimize the impact to them.
Thanks,
Kevin Janes
Version Control - Baseline
Moderators: chulett, rschirm, roy
A big question is: are you running 'released' jobs in production? Version Control ends the practice of releasing and packaging jobs for testing and production. Instead the source and binaries are migrated, first from development into Version Control and then from there into Test and/or Production.
We ending up freezing our projects at a point where development matched both test and production, removing the released versions and then replacing them with the dev versions after importing into VC and promoting into test/prod. If you aren't using released jobs, you could come straight from production into VC... do you have a test project?
It's simple to import everything as that is what it defaults to when you run 'Initialize from a Project'. You could do that once and then do the 'as needed' bit from then on. With your 10 developers, are you planning on letting them promote their own code, or will some central point manage the promotion?
I'm not really sure what kind of impact this will have on your developers, unless they are all going to promote their own code. About the only requirement to pulling stuff into VC is the job must be 'idle', not running or open in Designer, things like that.
Version Control is a nice addition to DataStage. It makes it easier to migrate jobs from project to project, gives you source to view in all projects (which released jobs don't have) and gives you the ability to roll-back to *any* previous version. Be aware there is a 'bug' where the minor number only supports a single digit in spite of what the docs show. This means it will only store 9 versions before it starts to overwrite the last minor rev. You need to increment the major number (manually) before this happens.
Hope this helps,
-craig
We ending up freezing our projects at a point where development matched both test and production, removing the released versions and then replacing them with the dev versions after importing into VC and promoting into test/prod. If you aren't using released jobs, you could come straight from production into VC... do you have a test project?
It's simple to import everything as that is what it defaults to when you run 'Initialize from a Project'. You could do that once and then do the 'as needed' bit from then on. With your 10 developers, are you planning on letting them promote their own code, or will some central point manage the promotion?
I'm not really sure what kind of impact this will have on your developers, unless they are all going to promote their own code. About the only requirement to pulling stuff into VC is the job must be 'idle', not running or open in Designer, things like that.
Version Control is a nice addition to DataStage. It makes it easier to migrate jobs from project to project, gives you source to view in all projects (which released jobs don't have) and gives you the ability to roll-back to *any* previous version. Be aware there is a 'bug' where the minor number only supports a single digit in spite of what the docs show. This means it will only store 9 versions before it starts to overwrite the last minor rev. You need to increment the major number (manually) before this happens.
Hope this helps,
-craig
We are not running "released" versions to Production. Changes moves periodically on an individual basis. Sometimes projects may constitute many objects but we do not move an entire package representing all objects with each release.
For instance, three jobs and 12 tables may move on Firday, and the following week a different set of 5 jobs and 7 tables move. We have a "Development/Test" environment and then a Production environment. Traditionally, we create .dsx's from test and import into Production.
I will probably initialize VC from "Test/Development", since that is where active work is occuring and it has a reduced set of objects. A single admin will promote from VC to Production.
Thanks,
Kevin
For instance, three jobs and 12 tables may move on Firday, and the following week a different set of 5 jobs and 7 tables move. We have a "Development/Test" environment and then a Production environment. Traditionally, we create .dsx's from test and import into Production.
I will probably initialize VC from "Test/Development", since that is where active work is occuring and it has a reduced set of objects. A single admin will promote from VC to Production.
Thanks,
Kevin