In Denodo, the term “Environment Management” refers to the managing of the metadata of the Denodo installations used at different points of the software deployment lifecycle (e.g. development, staging, production) and/or at different geographical locations.
Certain properties of the metadata elements are considered “environment-dependent”. For example, a data source may point to different DBMS installations in the development and production environments, so the access details (URI, access credentials…) for that data source will change depending on the environment.
Denodo manages this situation by introducing the concept of “environment”. For each environment, Denodo can generate a file specifying the metadata’s environment-dependent properties (e.g. the URIs and connection details of data sources). When loading metadata from a different environment, the process can be configured to use the properties of the target environment instead of the origin ones.
An environment (in our VCS integration context) consists of a name and an optional description. There are .properties files in the VCS repositories for each environment-dependent element:
- One .properties file for each environment that was active each time the element was checked in.
- A default .properties file, which will be used if there is no .properties file for the selected environment when checking an element out. Each time an element is checked in, its default .properties file is replaced in the VCS repository.
A comprehensive list of elements that are considered environment-dependent can be found in the section Export to a File with Properties, along with their environment-dependent properties.
To open the wizard to manage the VCS environments, click VCS management on the menu Administration and then, click Environments.
In this dialog, administrator users can manage the environments.
When you add/modify an environment, Virtual DataPort sends a commit to VCS server with a properties file that contains the name of the environment and its description. When you delete an environment, Virtual DataPort deletes it from the VCS server.
By selecting an environment and clicking Set as default, the user can choose what environment will be active when using the global VCS configuration (this will be the case of the databases configured to use VCS with the default environment, as seen on Environment Management). After creating the first environment in a repository, it will be automatically set as the default environment.
Note that after changing the server’s environment (either here or in the specific configuration of a database, as seen in Environment Management), the change will not be effective until the next time the user executes a check in or check out operation, or a pull or a push. This does not affect the databases with specific environment configuration.
After creating the environments, you have to do one of these:
Alternative to Environments¶
When importing metadata from a local repository into the server, it is possible to choose an environment. In this case, the selected environment’s properties (that must exist in the local repository) will be used to generate the final metadata. Alternatively, the user can provide a unique file containing all the properties needed to import the metadata.
Furthermore, the user can choose to export metadata generating both a properties file and a template VQL file. Then, the values in the generated properties file can be changed as necessary and the file can be used to import the template metadata. This will be the preferred methodology when importing metadata into a production server (see the sections Developers Use Their Own Virtual DataPort Server and Developers Share the Same Virtual DataPort Server). The section Export to a File with Properties explains how to export metadata with a properties file.