Everything I have read here and elsewhere mentions the use of the VERSION project for the Version Control repository. How does one manage the objects when performing migrations in multiple initiatives? Seems to me that after a few batches for each initiative have been performed it would be difficult to keep track of the different objects if they are maintained in the same VC project (not to mention that the project would be large, and require special consideration if backing up or exporting). Are separate VERSION projects created for each initiative? Are naming conventions utilized to facilitate filtering? Something else which would work better?
Thanks,
Stan
Version Control for Multiple Projects
Moderators: chulett, rschirm, roy
-
stan_taylor
- Charter Member
- Posts: 14
- Joined: Tue Mar 04, 2003 3:27 pm
Stan - Let me see if I can help. I'm curious, have you tried Version Control yet or are you just in the consideration / checking it out stage?
What do you mean by 'initiative'? We use DataStage in two main areas: our Data Warehouse and an eCommerce application. Would that be what you are calling initiatives? I'm going to assume so going forward. Since we use three projects per initiative, that means six projects all rolling into VC. Our VERSION project isn't especially large, it *is* larger than any individual project but it's definitely less than the sum of all of the other projects - even though the VC project contains one or more copies of every job (routine, table def, etc) in every other project. I'm guessing that's because it only stores the source. We run on a Unix server and have never needed to give any "special consideration" to the backup because of Version Control.
We haven't had any issues with things being "difficult to track", and we've run upwards of 500 batches of changes into it over the years (been using it since the 4.x days). You do have to be aware of a couple of things. VC does not use the Category when it stores stuff, so you will see an alphabetical list of job names in the default view, much like life before Categories in DS. Because of that, and because Project doesn't play into that either, you need to make sure your job names across 'initiatives' are unique, otherwise they will get folded together. The naming convention we use for Jobs makes this a non-issue for us. Routines, on the other hand, can be a problem if (for example) you had two routines with the same name in different initiatives that were not exactly the same. It could get a little confusing if you just look at the job display, but it's not as bad as it sounds because the Batch (and the ability to view by batch) keeps them straight. When you import a group of changes into VC, they are grouped into a *batch* and that batch can be (and is generally always) used to 'uplift' them from there to QA and Production. *It* knows which version (or collection of versions) of 'GenericSuperJob' and all of its supporting changes that you need even if sometimes you may not be sure. [:)]
When I mentioned it doesn't show Category or Project, I don't mean to imply that it doesn't store them or use them or care about them... it does. It's just that it doesn't display any category information and the projects are listed in the version history it keeps. Technically, there's nothing to stop you from taking something in VC from one initiative and promoting it into another initiative's project, but then you can do that same thing right now with import/export or the Packaging Wizard.
Version Control assumes a single dedicated VC project per server. I *think* that you technically could maintain multiple VERSION projects, but it wouldn't be worth the effort IMHO. A good naming standard that took into consideration your initiative would help, but I don't think even that would be *critical* to the success of your endevour to utilize VC.
Sorry this got kinda long. It's getting late and I hope it made enough sense to be helpful. [|)]
-craig
What do you mean by 'initiative'? We use DataStage in two main areas: our Data Warehouse and an eCommerce application. Would that be what you are calling initiatives? I'm going to assume so going forward. Since we use three projects per initiative, that means six projects all rolling into VC. Our VERSION project isn't especially large, it *is* larger than any individual project but it's definitely less than the sum of all of the other projects - even though the VC project contains one or more copies of every job (routine, table def, etc) in every other project. I'm guessing that's because it only stores the source. We run on a Unix server and have never needed to give any "special consideration" to the backup because of Version Control.
We haven't had any issues with things being "difficult to track", and we've run upwards of 500 batches of changes into it over the years (been using it since the 4.x days). You do have to be aware of a couple of things. VC does not use the Category when it stores stuff, so you will see an alphabetical list of job names in the default view, much like life before Categories in DS. Because of that, and because Project doesn't play into that either, you need to make sure your job names across 'initiatives' are unique, otherwise they will get folded together. The naming convention we use for Jobs makes this a non-issue for us. Routines, on the other hand, can be a problem if (for example) you had two routines with the same name in different initiatives that were not exactly the same. It could get a little confusing if you just look at the job display, but it's not as bad as it sounds because the Batch (and the ability to view by batch) keeps them straight. When you import a group of changes into VC, they are grouped into a *batch* and that batch can be (and is generally always) used to 'uplift' them from there to QA and Production. *It* knows which version (or collection of versions) of 'GenericSuperJob' and all of its supporting changes that you need even if sometimes you may not be sure. [:)]
When I mentioned it doesn't show Category or Project, I don't mean to imply that it doesn't store them or use them or care about them... it does. It's just that it doesn't display any category information and the projects are listed in the version history it keeps. Technically, there's nothing to stop you from taking something in VC from one initiative and promoting it into another initiative's project, but then you can do that same thing right now with import/export or the Packaging Wizard.
Version Control assumes a single dedicated VC project per server. I *think* that you technically could maintain multiple VERSION projects, but it wouldn't be worth the effort IMHO. A good naming standard that took into consideration your initiative would help, but I don't think even that would be *critical* to the success of your endevour to utilize VC.
Sorry this got kinda long. It's getting late and I hope it made enough sense to be helpful. [|)]
-craig
-
stan_taylor
- Charter Member
- Posts: 14
- Joined: Tue Mar 04, 2003 3:27 pm
Craig -
Thanks for your post, and all of your other helpful posts to this forum, for that matter. Your assumption of the definition for intiative is correct - we have been using that to differentiate what we might normally be called a project from a DataStage project to avoid confusion. We are not even in production yet, but should have two initiatives live by the end of the month, with a third going live in July and a fourth in August. From the standpoint of someone who has little experience with DataStage (and none of it in a production environment yet), I appreciate the feedback from someone who has gone through all the trials and tribulations. For example, it is comforting to know that the use of Batches for categorization is sufficient when multiple initiatives are handled in a single VERSION project. And length is no issue (although you lost some sleep over it) - hopefully this thread will provide enough details to answer similar questions in the future.
Thanks,
Stan
Thanks for your post, and all of your other helpful posts to this forum, for that matter. Your assumption of the definition for intiative is correct - we have been using that to differentiate what we might normally be called a project from a DataStage project to avoid confusion. We are not even in production yet, but should have two initiatives live by the end of the month, with a third going live in July and a fourth in August. From the standpoint of someone who has little experience with DataStage (and none of it in a production environment yet), I appreciate the feedback from someone who has gone through all the trials and tribulations. For example, it is comforting to know that the use of Batches for categorization is sufficient when multiple initiatives are handled in a single VERSION project. And length is no issue (although you lost some sleep over it) - hopefully this thread will provide enough details to answer similar questions in the future.
Thanks,
Stan