How to create a small development/training environment for Integrity LM

[VolkerEckardt]

Hello,

I am in a discussion with my client how to create a small training/development environment.

Obviously there are different options. Therefore, I'd like to use this forum to discuss with you which approach you suggest / you already have used in the past successfully.

Option 1: Solution Export/Import to get all IM Configurations

=> According to my experience this might work, but has not to. Especially when you have many users defined, this export sometimes crashes or is not installable, unfortunatelly.

Supports "Source" - no,

Supports "Workflow&Documents" - yes

Supports "Data" - no

Option 2: Stage to Empty

=> If Option 1 does not work, this is the alternative. You connect an empty Integrity environment and configure "stage to empty". The beauty with this is that you can even select which configurations you like to move. 

Supports "Source" - no

Supports "Workflow&Documents" - yes

Supports "Data" - no

Hint: "Stage to empty" is suggested to be used when you have to build up the PROD from TEST, like in my current engagement. 

Option 3: Clone an existing environment

Easier said then done, especially when you have 4 TB++ of data in your environment.

Supports "Source" - yes

Supports "Workflow&Documents" - yes

Supports "Data" - yes

Hint: This option is not really an option because we asked for a small ! environment. 

I am looking forward to your ideas or suggestions to fulfill this request.

Thank you!

Volker

[JensN.]

Hi Volker,

we're facing such decisions (or pre-decision discussions) consistently. And we've done all three options in the past. Always with more or less problems. The option with the least problems was option 3, but as you said, this is also the option with most resource comsumption.

But beside the discussion about your particular project there are (in my point of view) other problems when you want to set up development environments:

It is always problematic to develop at one system with more than one developer at the same time at the same objects. To avoid this, we would like to have one development environment for each developer and an integration environment for, ahemm, integrating the solutions from each development system. PTC doesn't have any solution for this (not even a development license system).

It is also problematic if not impossible to connect more than one development system by staging to one integration system with the built-in staging connection. So  ootb-staging is obviously no solution for distributed development.

Cheers, Jens

[VolkerEckardt]

Hi Jens,

You are right, there are no OOTB solutions for this "distributed dev environements" topic. We do have quite strong helper tools, but it's not a click-and-distribute action.

I understand from configuration perspective that the tool (Integrity) should support such functionalities, before a good project process can be defined.

In my current engagement we use the Option 1 successfully. First, each developer has to have a server lisence. And second, when ready, he has to merge the changes with changes from colleagues manually. This is error prone, and sometimes difficult to manage.

I don't think this is Integrity specific, lots of software tools have this issue when customizing or even pure setup can be done concurrently.

Perhaps someone else has suggestions or even best practices to share with us?

Volker

[alabonte]

IMPORTANT: Ensure that you have functional, known good, database backups in place in an event of a rollback becoming necessary

IMPORTANT: Ensure that you have functional, known good, filesystem backups in place in the event of a catastrophic failure

IMPORTANT: Due to the complicated nature of this operation, it is very strongly recommended to test this migration in a test environment before attempting a real production migration

Volker,

From a Technical Service point of view, the 3^rd option you present is the only supported option – cloning an existing environment. The steps required to accomplish this have been documented in an Article CS189144.

As you noted, you could get a more desired outcome if you use options 1 or 2, but this will be for “Workflows & Documents” ONLY and not include any Data or Source information. Also, what you present in options 1 and 2 relies on functionality that isn’t published in documentation, for the simple reason that it is a delicate task and must be performed exactly right to get the desired results. Our abilities to provide assistance to customers using options 1 or 2 are strictly limited due to this.