DSXchange

w951bvc wrote:The problem is that it seems with Version Control that I cannot promote by category.

I don't have the time right now to fully absorb your issues, but this popped out at me. You can initialize by Category, which in turn means you can (in essense) promote by Category as well. It's one of the right-click options.

Craig;

This is true. But with this approach every time I have a change, I would need to check in the whole application; I couldn't simply check in the new/changed job and leave it at that. So in order to ensure I have a good copy, I would first have to push the latest copy to development (which should be there already, but you never know), make my change, then push the whole thing back into VC.

A number of our core applications are rather hefty in size, so I'd like to keep the amount of code that needs to be pushed around to a minimum.

Though I think you're certainly correct, this approach would take care of the fundamental problem. I'm just trying to see if there might be anything a bit less unwieldy I could try.

Thanks,

->Richard Carpenter

I would never push anything into development from VC. Firstly you might be wiping out in progress development work and secondly you are filling your version control comment full of useless information.

You don't need to initialise the entire category each time, you can incrementally add those items that have changed and break your release cycle into major releases and minor releases. If you switch to the Details view in DS Manager you will see the Date/Time Modified column, you sort your jobs by this column and compare the dates to your Version Control date to build a list of jobs that have changed since the last release.

I don't have VC loaded at the moment, does it display the Date/Time Modified field in the initialise form? Can you sort by this heading and just choose those jobs that have been changed recently?

I'm with Vince on the whole push-back-into-dev thing. I only do it when I know something there is borked and I need to "reset" it to the last good version.

And, no, it does not show details in the Initialize form - which is unfortunate. It would be nice if it gave us some help in the process, but it doesn't. I generally work from a list of submitted changes, or simple toggle back and forth to a Manager session sorted by Modification Date to check what I am doing.

I don't really follow when you say this, Richard:

But with this approach every time I have a change, I would need to check in the whole application; I couldn't simply check in the new/changed job and leave it at that.

Why would you need to check in the whole application? Perhaps I'm missing something here. I routinely check in only changed jobs. If I need to promote an entire Batch (Category) again, I can go back to the original batch and during the process make sure I select the 'Highest Version' option. If I have a 1.1 version in the batch I am selecting, but also have a 1.2 and a 1.3 that were brought in after that, it would automatically select the 1.3 version from the other batch for promotion.

Does that help at all?

Vincent;

That's an excellent point, that I could compare the timestamp in development to that in VC, in order to verify that the code in development has not been tampered with since the last check-in. I'm definitely jotting that one down.

Craig;

The problem with the "Highest Version" option is what if the module I'm adding is a NEW module? Then I could no longer use the old named batch - I believe I would have to create a new batch, which goes back to me having to check everything in again.

And at that point I'd be responsible for the integrity of the entire application, which is why I mention grabbing a known good copy of the application before I start any changes at all.

->Richard

Truth to tell, I haven't made much use of Named Batches but I understand your concern. I'll poke around tomorrow in the office and see if there's something in Version Control that may help.

Anyone out there actually using Named Batches or with insight on the issue want to chime in, be my guest... Vincent and I won't mind.

We use Version Control for promotion to QA and Prod. We also use Named Batches in this process. However, we only use named batches when it makes sense to do so. For example: We set up a named batch which includes all jobs necessary for a phased release of ETL. Once we have this named batch set up if we have fixes or issues, we reinitialize ONLY the parts with changes. This increments a new version for these jobs, but if you select 'highest version', your batch is still correct.

Also, there are numerous chances to setup new Named Batches, for example, given the above example - I have a named batch but now I need to add another job to this named batch. I initialize the new jobs to get them in version control. Now I am ready to move everything to QA, so I select the Named Batch (knowing that this does not include the additional job), it selects the majority of the necessary jobs and I add the additional job to it. When I select 'promote' it gives me the opportunity to set up a new named batch - which I do. Now I have a named batch that includes not only the origional set of jobs, but also the new additional job.

This is just one example of how to use this feature. It is very flexable and you can make it work well in most situations.

Good luck!

Aaron

Currently DataStage 8.5 has a separate tool - ' Information Server Manager' which can diractly perform version control of DataStage jobs and native stages.

Did you notice that you're adding to an eight year old thread?