I've been trying to get a handle on version control within DataStage and need some pointers in a few areas.
I have saved all of my server jobs and controlling job sequence with the default revision 50.0.0 in the job properties. When I create a releasable .dsx I guess that this will automatically change to 50.1.0 (although I've not tried this yet).
This release will go into User Acceptance testing (UAT) whilst development of the Job Sequence and Server Jobs will continue. Assuming that there are no problems with the UAT testing a further .dsx will be created and released to UAT. The question I have here is what happens if a bug is found in UAT in a server job that I have continued to develop.
If I import the version that I released to UAT will it not overwrite what I have been developing ?
If so then potentially a lot of development work could be lost.
Hopefully, I've got the wrong end of the stick here but is it possible to switch between versions without losing development code ?
I've seen a few posts regarding the Version Control Tool but where does it live and how do I access it ?
I have looked at the books online help and can't find much about the job properties version number and nothing regarding the Version Control Tool. Any pointers or directions to previous posts that I haven't found would be appreciated.
Version Control
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Version Control client is on your DataStage clients CD, separately installable (but no extra licensing).
You will also need to create a separate project in which the versioned objects can be stored.
The version number's minor number is incremented by a promotion (e.g. 50.0.0 to 50.1.0) UNLESS the tertiary number has been incremented by developers (50.0.1).
You can be selective about which versions you move around with Version Control; the default is "latest", but full selectivity is available.
You will also need to create a separate project in which the versioned objects can be stored.
The version number's minor number is incremented by a promotion (e.g. 50.0.0 to 50.1.0) UNLESS the tertiary number has been incremented by developers (50.0.1).
You can be selective about which versions you move around with Version Control; the default is "latest", but full selectivity is available.
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.
Once you install Version Control, you'll have the appropriate online help and .pdf documentation you are looking for.
As to the question of moving versions back into your development project to fix bugs found it test, it depends on if further development has taken place in the meantime and if you want to preserve it.
If you simply push the test version back into dev, then yes - it will overwrite the development version and your work will be lost. When I've been in that situation (which really should be the exception to the rule) you can:
1. rename the current job
2. promote the test version back in
3. make your corrections
4. initialize back into VC then promote back to test
5. make the same corrections to the renamed job
6. delete the version just sent to test (or rename)
7. rename the saved job back to the original name
Much better to ensure the version being tested is good before marching off to the next great release.
I also keep an 'extra' sandbox / playground type project around that I can pull things into without stomping on anything 'real'.
If you haven't done anything further in dev, just make your fixes and repromote, no need to pull anything back.
As to the question of moving versions back into your development project to fix bugs found it test, it depends on if further development has taken place in the meantime and if you want to preserve it.
If you simply push the test version back into dev, then yes - it will overwrite the development version and your work will be lost. When I've been in that situation (which really should be the exception to the rule) you can:
1. rename the current job
2. promote the test version back in
3. make your corrections
4. initialize back into VC then promote back to test
5. make the same corrections to the renamed job
6. delete the version just sent to test (or rename)
7. rename the saved job back to the original name
Much better to ensure the version being tested is good before marching off to the next great release.
I also keep an 'extra' sandbox / playground type project around that I can pull things into without stomping on anything 'real'.
If you haven't done anything further in dev, just make your fixes and repromote, no need to pull anything back.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
As far as I can see there seems to be two methods for releasing code :-
(1) In DataStage Manager whole projects or components can be exported as .dsx files via either DataStage Components or Executable Jobs from under the Export menu.
(2) Reading through the documentation for the DataStage Version Control Client whole projects can be promoted to a Test Project or Production Project.
Does (2) negate the need for (1) ?
Should both be used ?
Also, if method (1) is used then should the .dsx file be placed into Source Safe/Rational/PVCS ?
(1) In DataStage Manager whole projects or components can be exported as .dsx files via either DataStage Components or Executable Jobs from under the Export menu.
(2) Reading through the documentation for the DataStage Version Control Client whole projects can be promoted to a Test Project or Production Project.
Does (2) negate the need for (1) ?
Should both be used ?
Also, if method (1) is used then should the .dsx file be placed into Source Safe/Rational/PVCS ?
I personally wouldn't consider your (1) to be a method for 'releasing' code. Yes, it can be used for migrating components from one server / project to another. It is typically used for creating .dsx exports of entire projects for backup purposes. In my mind, however, there are too many things that don't happen when you export/import that do with VC that I wouldn't consider it as a 'primary' migration tool.
(2) is the 'official' method. It allows the maintenance of multiple versions, tracks promotion history, preserves the previous logs, handles dependencies amongst components and can automatically compile and mark jobs as 'Read Only' (highly recommended outside of dev) during the process. All without having to push export files around.
As to whether (2) negates the need for (1) I think most people would answer that with a 'yes'. Some do both to do as you mentioned, have a copy pushed off to some Corporate Standard versioning software. Some only do a variation on (1).
(2) is the 'official' method. It allows the maintenance of multiple versions, tracks promotion history, preserves the previous logs, handles dependencies amongst components and can automatically compile and mark jobs as 'Read Only' (highly recommended outside of dev) during the process. All without having to push export files around.
As to whether (2) negates the need for (1) I think most people would answer that with a 'yes'. Some do both to do as you mentioned, have a copy pushed off to some Corporate Standard versioning software. Some only do a variation on (1).
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers