Differential Deploy and Execute

I've not experienced this behavior in TX versions prior to 17.12.  I've typically been able to deploy/execute only modified tables/views and it will work as you'd expect.  Perhaps this is a regression testing type issue?

Ok.  Maybe I'm encountering a bug then when adding new tables.  It seems to want to execute the entire business unit.  I've been playing around with it and the Modified Objects option seems to only execute modified objects in most cases... trying to figure out what is breaking it.

Hi David,

This is Doug Wynkoop from TimeXtender US Support.  I've turned this into support ticket - please add any additional information you discover to that ticket!

Best regards,

Doug Wynkoop

Very true... so if a staging table is modified, the differential execute wouldn't know to also execute the fact or dimension table it's populating.  

Fair enough that you wouldn't be able to catch everything, but the developers should have a good idea of what else needs to be executed.

How about this... maybe a prompt allowing a developer to add the incremental deployment items to the execution queue?  This way at least those could go into the queue and start executing and we can then drag in the other tables which need to be refreshed as a result.

There are a couple use cases for this:

1) A developer is pushing a few changes between environments.  The new environment is scheduled to load in several hours, but it's the developer's bedtime and he/she would like to make sure the changes execute properly before calling it a night.  Incremental deploy, execute only those changes, and then refresh other impacted tables.  Doing this provides a reasonable amount of getting a good night's sleep and not having to wake up because of a failure during the scheduled execution.

2) Data issues have been discovered and a quick fix needs to be pushed out to production in order to appease the masses.  

Obviously, this can all be accomplished with careful notation of changes between versions and making sure that you execute each of the effected objects afterwards.  I usually have to scroll through the differential deployment task list to see what has been checked off, so at the very least, it would be nice to be able to just get a simple list of objects effected by the differential deployment.  It's easy to miss something if there are a lot of tables impacted.

I would like to have differential check as the initial step in environment transfer, and from that step get a selection of objects I would like to transfer.  In my opinion one should not transfer objects still in development to the production environment, which one is forced to do in the current setup.

The production environment should be a clean production environment!

Hi Sigurður, 

I recommend creating a new thread on this request!  It's a relatively common request, and deserves its own space. 

Best regards,

Doug Wynkoop

This would definitely be useful.

After environmental transfer to production, I usually deploy and execute each layer (ODX, STG, DW) individually. If you have an ODX with hundred tables and only 10 have changed or been added you only need to execute those. Currently, I manually note them down and add them to the execution queue to save execution time since the ODX is already up to date from the last nightly run. 

Hi everyone, 
The option is available to deploy differential and execute "Only modified tables and views"  of course you would need to this by opening the project in the destination environment. However, typically we recommend running a full scheduled execution in order to validate all data in dependent & related tables etc. I'm going to go ahead and mark this one as completed, but let me know if I'm missing the point here.