Skip to main content

The project version has quite a few fields that relate to the OTAP environment. Often a path, database name or other property changes from one environment to the other.

Project versions have a status, and some statusses imply one OTAP-environment or another.

Would it be a lot of trouble to add OTAP-specific settings at the project level, and declare a project version status for which it is valid?

It still means some editing in case of distributed server environments, but it makes some releases easier to manage.

Hi Boudewijn,

Runtime configurations capture all the properties specific for an environment. A runtime configuration contains the server and database, file storage locations etc. You can make a runtime configuration for every step in your OTAP/DTAP.

Important to know is that the runtime configurations are specific for each project version. It is up to the discretion of the developer to choose the correct runtime configuration on the correct project version when the developer wants to run a certain environment.

I'm not sure whether forcing the development team to maintain a mapping between project version statusses and runtime configurations would be helpful. What are your thoughts on this?

My thoughts:

I would expect that the development team would only indicate which project version is ready for deployment and that a configuration manager can select a ready project version and import it into TAP. And that after importing the model the configuration manager can also update the associated database to fit this model.

I would definitely not expect a development team to do such a thing, because this is against the principle of ownership.

Is this way of importing a ready project version possible from IAM?

PS I would also expect that a ready project version can not be changed by the development team, but that any changes would be part of another project version.

Reply


Terms & ConditionsCookie settings