Multiple ODX for different enviroments

Hi,

In TimeXtender data integrator (next-gen) it is possible to seperate the ODXs between the environments. During a transfer/ migration you could then select to copy e.g. ODX DEV to ODX ACC, etc. as shown below:

Kind regards,

Devin

Hi Devin, 
Appericiate your quick response. 
 

I'm not that familiar with next-gen.So If I understand correctly you could compare instance to Enviroment (DEV/PRD) and by promoting project from one instance to another, TX will know which part of ODX it should connect to?

Can you implement metadata changes to ODX table in DEV while PRD will remain uneffected? 
 

Kind regards, 

Dror

Hi Devin, 

This is very interesting… I'm almost hooked 😀

One more (off-topic). In version 20.10 you can segment code into Timextender projects. Is this also possible in next-gen?

Kind regards, 

Dror 

Hi Dror,

What do you mean with segment code?

Hi Devin, 

Just a way ro arrange the tables or other objects into meaningful subjects. 

You mean like "perspectives”? Otherwise could you please add a screenshot of what you mean?

Hi,

TDI / 6xxx / next-gen does not have the project concept anymore. In migration scenarios you can merge projects together into instances, or decide to keep them separate. In general, there is no longer a “global” project scope, but everything is scoped to an instance. Between instances of different type you synchronize, between instances of the same type you promote (or “migrate” as it is now called).

Hi Devin, 

In 20.10 you can use projects to bundle DWH elements. We use project if we want to isolate DWH elements which are ready for production. 

rory.smith

That’s a shame. we have scenario’s where in development only part of the DWH (instance) ready for production. How can you isolate and migrate only the apporopiate objects?  

Hi,

environment transfer / promotion / migration currently copies all metadata across from one (instance) repository to another. I typically use perspectives and certain crosschecks to manage what is deployed on the next environment / instance. Exactly how this is done depends on things like the length of the cycle and how many people make up the team among other variables.

If you use projects as a subdivision, you typically lose overall lineage and may end up depending on external SQL Connections / Business Units which require changes of approach in the new release as well.

Hi rory.smith, 

How would you define your experience with next-gen in general and enviroment promotion in particular? 
Does it work for you? 
 

We have a team of 3 developers and have a frequent release cycles of 2 weeks. If everybody is developing on the same instance it would be very hard to select only to the correct, modified objects to deploy to production. 
I totally agree that when working with projects you would lose the overal lineage ,having external SQL connection between projects is not ideal but If you want to work on a modular approach I don’t see any other way other than using perspectives (only bad experience here)

Hi,

we run this approach with customers where there may be > 5 developers working at the same time. The perspective approach works as long as your developers are able to follow a disciplined process. We have some customers who do a rolling approach where everything gets promoted to the next environment every two weeks or so (i.e. rolling approach), we also have customers who ensure everything is ready.

The main tips and gotcha's in 20.10.x and older are that:

• Divide the work so that only one person works on one thing, especially with Semantic Models
• Use Perspectives to manage what to Deploy on subsequent environments
• Use Work Items
• Talk to each other so that everyone knows what is going on
• Mapping changes are immediate (you can work around with conditionals) this means you may break other layers in other environments if you are not careful
• Deleting and changing things is always dangerous and should typically be avoided. I.e. make a new table with your changes and once you are done merge flows through that, removing the mappings to the old table instead of mutating the existing table that others may depend on
• There is only one ODX, so don't change sources for Dev if that change will break Prod

In the new release each instance has its own repository, leading to less clashes. You can also more easily promote, as this is done per instance. There are differences between 20.10.x and 6xxx that could lead to rework, but you should be spending effort on refactoring anyway (everyone does right? :-) ). Some of the differences may lead to “we cannot go to the new release today”, obviously reporting those blockers helps TimeXtender to prioritise what to adapt.

Hi,

Thanks for the elaborate answer. That’s certainly put me on the right direction. 

One very last question (I promise): I heard TX was working on migration tool to help the upgrade from 20.10 to  next-gen. Did it reach maturity? given the scale of our environment, staring from scratch is no-go

Hi @dsvartzman ,

the tool is there. See:

• Migration Tool - Upgrade from TimeXtender Classic to TimeXtender Data Integration Tutorial

There are some legacy features that will prevent it from being able to migrate a project (see: 

• Migration Tool - Project Validation

). It can also merge existing projects together into Prepare instances. Note that there are a lot of details that matter for this, and that it is a fair amount of work for a large implementation.

devin.tiemens, rory.smith 
Many thanks for your help 🙏!