Entity types
Entity types are used throughout the deployment process and some affect how DROPS operations are carried out. Types are categories for components, environments and infrastructure items. The different types of each entity are defined by an admin in the Preferences menu under Artifacts and Configuration.
Component types are used to categorize components in order to easily see what kind of artifacts they contain. Components can contain any type of artifact and any combination of different artifacts. Usually, they contain a group of artifacts that together create an individual part of a larger application/software/website/etc. Categorizing them creates a way to identify these individual parts of the whole application.
Component types might be web archives, executables, SQL database artifacts, IBM i save files, etc.
Component types are selected when creating and/or editing a component but selecting a component type is not mandatory.
If strategy or activity templates are not defined for the component type, choosing a type does not change how a component functions. However, if an import strategy template or a deployment activity template have been defined for the component type, choosing a type will associate the templates to the component; and changing the type of a component will override any templates previously associated with the component.
For more information about managing components, refer to Components.
For more information about managing component types, refer to Component types.
Environment types are used to categorize the nature of your environments and to manage user roles and rights according to how you use the destination site.
There are a number of environment types available by default which enable you to organize different deployment targets by their intended function.
You may need to deploy the same content to a test or training environment as well as a production environment.
An environment type is a set of properties that characterizes the operational need related to the creation of an environment. The properties are:
- the nature of the operational need,
- the workflow order,
- the production flag that indicates if the operational need occurs on an in-production environment.
Choosing an environment type may change a user's access authorization. Global roles can be applied to environments based on their type which means that a user may have the correct role to access/edit/deploy to testing environments but not production environments.
Environment types are mandatory and are assigned to environments when creating and/or editing them.
The development (Dev), test (Test) and production (Prod) check boxes mark the environment type according to how it is used.
The workflow order defines the order in which applications should be deployed to environments. The workflow considers the type with the lowest workflow number the first environment type to deliver to and the highest number the last.
The Color option makes it possible to associate a color to any Environment Type to help differentiate them. Click on the Color field to display the Color Picker box, select a color then click OK.
The Roles associated with the management of environment types are defined here.
Environment types should not be confused with environment extensions which may require extended configuration.
Any numbers can be used to define the workflow, except decimals. However, using single-digit numbers may limit use if you have more than 10 types of environments. It is suggested to use three-digit numbers so that you can insert new types between existing types later.
A deployment plan contains multiple environments so that the developing application can be tested on a test environment, then delivered to a training environment and finally to the final production environment. Testing environment types should be first in the workflow (100), training types second (200) and production types last (300). Later, you could add a UAT testing environment type between testing and training by giving it a workflow number of 150.
For more information about managing environments, refer to Environments.
For more information about environment extensions, refer to Environment type extended configuration.
Infrastructure item types are used to categorize the services found on target systems and to manage their specific extended configuration. You can search for infrastructure items based on type. Choosing an infrastructure item type is very important because the associated extended configuration options provide connection details on a type-to-type-basis. Only default types will contain extended configuration but you can create new types of your own to categorize your infrastructure items however you need to.
If an infrastructure item is intended to create the link between DROPS and a TOMCAT, IBM i, ARCAD server, a JDBC or Docker, there is necessarily more information to configure in order for the connection to be authorized than there is for a "normal" type destination (ex: Windows). These types are provided by default in the DROPS Studio.
The extended configuration for an infrastructure item is managed in the Infrastructure Item editor after the type is selected.
Infrastructure item types are mandatory and selected when creating and/or editing an infrastructure item.
For more information about managing infrastructure items, refer to Infrastructure items.