Transfer (Multi-Environment) just one Project Perspective

Hi Roland

It is not possible to do this. Whenever you transfer the project from one environment to the other it will be the whole thing.

So this means that if you choose to deploy a perspective afterwards and have changes in tables not in this area, it will fail on future executions.

This is a common issue you explain, so we have been discussing many ways to solve this issue.

In the current setup I think the best method is to do a three environment setup. When you are done with a part in the Development environment you can transfer it to the middle environment and use the deploy perspective. Then you can check that the changes work, by executing the specific perspective.

If you want to push the changes to production you will have to be at a point where all currently developed parts are at done and then you can transfer from development to test and then production.

Hi Thomas, 

Do you have some more information about the setup you suggest ? 

I don't see the difference with our setup of 2 server. Why can ik use an deploy perspective from development to the middle. And not from development/test to production. 

Do you make a project in de development environmet to deploy to de middle environment en than you deploy all project to the production. ? 

How many environments can you install on one license ? 

We have the same issue and hoping TimeXtender will adress this as soon as possible. This is big down side of how TimeXtender is designed.

We have a three environments setup. Development, test and production. What Thomas means I think is that you do development in dev and let users test in test environment. Then you accumulate all changes in test until everything is in a state where you can deploy to production.

The bottleneck here is that you cannot choose to not deploy all changes to the execution packages. So changes you do not want to deploy creeps in to the execution packages and results in packages failing.

I think TX needs to rethink the whole source control, team development and deployment design in the product. And I hope they will be transparent about it as well.

Yes exactly, thanks for explaining that Martin.

Again it is something we have some suggested improvements for, but they are not currently available, so the former is the best method to do this.

The way to make this work is to make sure you encapsulate changes in a perspective and only deploy those perspectives that are ready on the next environment. Properly dividing work amongst developers and carefully planning makes it workable with the current featureset.