Hi Steve,

Thanks for your help on this. This is exactly what I was looking for.

I have now successfully integrated this into my code release procedure such that the state of production interfaces are now maintained and are now also saved back into the production class definition.

My procedure is basically as follows:

1. Save the state of production interfaces

2. Load and compile the new code set

3. Retrieve previously stored interface states

4. Save interfaces back into the production class definition.

5. Force an update of the production to restore the previous running state of all interfaces.

Doing this ensures that any new interfaces in the production class are picked up, the state of any existing interfaces is maintained, the production class definition correctly matches the state of all interfaces, and no manual intervention is required to update the production state (i.e. via the management portal).

As a side note I have discovered that the production class definition must be compiled in all namespaces that use it in order for changes to be picked up. We have a common application set in a separate database which is referenced by multiple namespaces so I have to switch to the appropriate namespace and compile all code relevant to that namespace locally. This differs from our standard Cache installations where we have the same situation but in that case the code only needs to be compiled in the application namespace and all other namespaces that use it can happily reference it.

Finally, the difficulties we have encountered in our code release procedure has highlighted a number of questions for us in relation to the Ensemble system design and in particular the role of the production class definition.

While a great number of settings can be stored locally for an Ensemble instance via the use of System Default settings (file paths, IP addresses, ports etc.) the Enabled/Disabled state of an interface is part of the production class definition. It makes sense to us that this really should be stored as data.

In fact the whole production class definition is really just a set of configuration data and we question why this must be maintained as a class definition rather than just stored as a set of data elements to be referenced.

The current design causes difficulties particularly when there is concurrent development occurring. We are currently still in the fairly early stages of our integration of Ensemble and as such we are bringing new interfaces on at a regular rate and these are being worked on by multiple developers. The issue we encounter is that because the interface definitions are all stored in the production class, if we want to deploy a new interface ahead of another we have to remember to temporarily remove the interface we are not deploying. This causes interruptions/delays in development and there is the risk that if we forget to do this then we could break the system we are deploying to as the production class may contain an interface for which there is no underlying supporting code. This has actually already happened to us. 

If the interface definitions were merely a set of data elements it would be very easy to segregate the implementation of one interface from another and we would not experience the issues we have with concurrent development.

We would be interested to hear how other customers manage this situation and  would be eager to hear from anyone who has some inspiration or experience in working with Ensemble on a large scale and just how you manage these difficulties and we look forward to engaging with Intersystems further on this also.

Regards,

Jo