Sir,
In my Client place rightnow we have only one common environment (Production),now we need to make it as Dev/Test/Prod environments
we have only one Server box license,i need to version the production jobs also.we are using 7.5 on windows.i have to install version control also.
7.5 comes with version control also or we have to buy separately.
please help me with your valuable ideas.
Thanks in advance.
Narasa
Version Control help
Moderators: chulett, rschirm, roy
Re: Version Control help
Yes,that's correct thanks for helpreddy wrote:Sir,
In my Client place rightnow we have only one common environment (Production),now we need to make it as Dev/Test/Prod environments
we have only one Server box license,i need to version the production jobs also.we are using 7.5 on windows.i have to install version control also.
7.5 comes with version control also or we have to buy separately.
please help me with your valuable ideas.
Thanks in advance.
Narasa
Re: Version Control help
Hi Guys,reddy wrote:Sir,
In my Client place rightnow we have only one common environment (Production),now we need to make it as Dev/Test/Prod environments
we have only one Server box license,i need to version the production jobs also.we are using 7.5 on windows.i have to install version control also.
7.5 comes with version control also or we have to buy separately.
please help me with your valuable ideas.
Thanks in advance.
Narasa
Can you Provide steps for how to establish version control by step by step .
Establish? First order of business would be to install it on your PC and then read the pdf documentation that installs along with it. There is a Methodology chapter which walks you through How It Works. Plus it documents the post-install steps you need to complete before you can start using it.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Version Control usually assumes that you're beginning with a development environment, so the first step will be to create the addtional projects (version_control, developement and test), then export the entire production project before importing same into the development project.
You can then initialize Version Control from the development project and proceed as per the manual.
You can then initialize Version Control from the development project and proceed as per the manual.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Ah. I missed the 'only have a Production environment' part for some reason. So Ray is right that you'd need to use the Production project to seed the development project.
The default project name for Version Control is VERSION, however it can be pretty much anything you like nowadays. I'd suggest a slightly different route to getting started, but either way will work...
1) Create a development, test and version control project.
2) Via the Manager, export your entire production project and import into the dev project.
3) Connect to Version Control and Initialize pretty much everything from the development project into VC - jobs, routines, transforms, etc.
4) Promote everything you just brought in to VC to the test project. Make sure you have the 'Compile' and 'Read Only' options enabled when you do this.
5) Again, Promote everything from VC back to Production with the same options. The goal with this step is to get your production project (like your test project) where everything is 'Read Only'.
When you are done, the only place you can make changes will be the development project. Note that the last three steps could take quite some time, especially if you have "alot" of jobs in your project, as everything is first sucked up to your pc before being pushed down to your target project. These first ones will be the worst as afterwards you'll only be moving smaller quantities around.
Now, all of this is predicated on the understanding that by "we have only one common environment (Production)" that means only one Project as opposed to one Server that hosts all projects. And that you are trying to establish new development and test projects. If this isn't the case, please clarify exactly what you have going on so we can adjust our advice.
Hope that helps.
The default project name for Version Control is VERSION, however it can be pretty much anything you like nowadays. I'd suggest a slightly different route to getting started, but either way will work...
1) Create a development, test and version control project.
2) Via the Manager, export your entire production project and import into the dev project.
3) Connect to Version Control and Initialize pretty much everything from the development project into VC - jobs, routines, transforms, etc.
4) Promote everything you just brought in to VC to the test project. Make sure you have the 'Compile' and 'Read Only' options enabled when you do this.
5) Again, Promote everything from VC back to Production with the same options. The goal with this step is to get your production project (like your test project) where everything is 'Read Only'.
When you are done, the only place you can make changes will be the development project. Note that the last three steps could take quite some time, especially if you have "alot" of jobs in your project, as everything is first sucked up to your pc before being pushed down to your target project. These first ones will be the worst as afterwards you'll only be moving smaller quantities around.
Now, all of this is predicated on the understanding that by "we have only one common environment (Production)" that means only one Project as opposed to one Server that hosts all projects. And that you are trying to establish new development and test projects. If this isn't the case, please clarify exactly what you have going on so we can adjust our advice.
Hope that helps.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
chulett wrote:Ah. I missed the 'only have a Production environment' part for some reason. So Ray is right that you'd need to use the Production project to seed the development project.
The default project name for Version Control is VERSION, however it can be pretty much anything you like nowadays. I'd suggest a slightly different route to getting started, but either way will work...
1) Create a development, test and version control project.
2) Via the Manager, export your entire production project and import into the dev project.
3) Connect to Version Control and Initialize pretty much everything from the development project into VC - jobs, routines, transforms, etc.
4) Promote everything you just brought in to VC to the test project. Make sure you have the 'Compile' and 'Read Only' options enabled when you do this.
5) Again, Promote everything from VC back to Production with the same options. The goal with this step is to get your production project (like your test project) where everything is 'Read Only'.
When you are done, the only place you can make changes will be the development project. Note that the last three steps could take quite some time, especially if you have "alot" of jobs in your project, as everything is first sucked up to your pc before being pushed down to your target project. These first ones will be the worst as afterwards you'll only be moving smaller quantities around.
Now, all of this is predicated on the understanding that by "we have only one common environment (Production)" that means only one Project as opposed to one Server that hosts all projects. And that you are trying to establish new development and test projects. If this isn't the case, please clarify exactly what you have going on so we can adjust our advice.
Hope that helps.
Thanks alot datastage Gurus.It helped me lot.
Excellent! One other piece of information to keep in mind that hasn't been mentioned yet is this -
in these more recent releases of VC, not only can the VERSION project be named something different, it now easily supports multiple Version Control projects.
So if you find yourself in a situation where you have many projects 'sets' (dev/test/prod) divided across different 'subject areas', then each area can have its own dedicated Version Control repository project. FYI.
in these more recent releases of VC, not only can the VERSION project be named something different, it now easily supports multiple Version Control projects.
So if you find yourself in a situation where you have many projects 'sets' (dev/test/prod) divided across different 'subject areas', then each area can have its own dedicated Version Control repository project. FYI.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers