1.6.1 How to implement Deploy/Import

Abbreviations, used in the manual:

QG - Quality Gates

EF - Execution Flow

RDA - Reference Data Administration

RDAD - RDA Designer

FW - Form Wizard

The Deploy / Import process allows you to transfer objects such as FWs, Tests, EFs, and reference data between Projects and Environments , etc.

Before proceeding with this manual, ensure that you have followed the steps outlined in the following manual: Deployments

Follow the next steps:
 

1. Define Deploy and Import paths:
 

a. Define the Export/Deploy path in the Administration module: 
The Export/Deploy path is a global setting that specifies the default directory where Deployment packages will be saved. This is essential for ensuring a consistent location for Deployment packages, which can then be transferred to the desired environment or system.

1. Navigate to the Administration module: "System Admin -> System Setting -> General Settings -> System Properties -> Export files location"
2. Set the "Export files location" field. This path is the default location for saving exported/deployed objects created on Deployment. This path can be located either on the server where quilliup is installed or in a shared folder.

Example of a Shared Folder Path for Windows:

b. Define the Environment:

The environment is a path/location where Deployment packages are created, as well as the definition of which operations (Deploy/Import) are allowed within this environment.

Please see related detailed manual: Environments

1. In Administration module navigate to: "System Admin -> System Setting -> General Settings -> Environments".
2. Click the "Add Environment" button.
3. In the opened form, fill in all relevant fields, including valid values for the "Path to Deploy" field:

Note: when defining Deploy and Import paths in the system, the paths are automatically organized with subfolders based on the different modules and functions within the system.
When you set a Deploy or Import path for an environment, the system will automatically create subfolders for each module. These subfolders will store the corresponding deployment packages associated with each module, simplifying the process of finding and managing files: 

1. Administration module
2. QG module
3. RDA module

For example, when deploying a Test in QG module, you will find the Deploy package in the chosen Environment path under subfolder named "2".

--------------------------------------------------------------------------------------------------------------------

2. Deploy an item:

1.  
   1. In the required grid (e.g., Tests, EFs), select the item(s) to deploy. Multiple items can be selected at once.
   2. Click "Deploy" button.
   3. Assign a name to the Deploy package and choose an Environment from the list.

QG module example:



RDA module example:

When "Choose Objects To Deploy" is enabled, you can manually select which related objects to deploy by marking or unmarking the checkbox for each specific item in the "Selected Objects" section.

if enabled, these objects will be deleted (by ID) in the Import Environment, if they exist.

 

3. Import an item:

a. Define the Import Path:

1. In the Administration module navigate to to: "System Admin -> System Setting -> General Settings -> System Properties".
2. Set the appropriate value for the "Imported objects location" field. This is the Import path:

 

b. Import Options:

Option 1:

in QG or RDAD modules, in the upper-right corner, click the arrow sign containing all the objects available for Import:

Option 2:

1. Navigate to the required module: "Settings ->Deployments -> Imports"
2. In the grid, view the list of all the packages available for Import in your Import location.
3. Click the arrow on the right side to Import a specific package.
4. Choose the Project to use for importing the selected package.
5. Click the "Import" button.

Order of Entities for Deploy/Import:
During the Deploy / Import processes, there is a specific order in which entities should be deployed or imported. This order is important to ensure that configurations and resources are correctly applied, and that there are no compatibility issues between the different components of the system. Certain entities in the system may depend on others, so following the correct order can directly impact the success of the process.

 

Below is a comprehensive list of the entities that can be deployed or imported within the different modules, along with the logical order for their transfer.

1. Order of Deploy/Import in Administration Module:

In the Administration module, the following entities can be deployed or imported in the listed order:

• Users
• Groups
• Mailing Groups: configuration of mailing lists.
• Network Locations: information related to networked systems and servers.
• Email Templates: HTML Email templates.
• Slack Templates: Templates for Slack messages used for notifications.

2. Order of Deploy/Import in RDA module:

In the RDA module, the following entities can be deployed or imported in the listed order:

• Roles: Roles that define user permissions and access within the system.
• Projects: includes project-level configurations and details.
• Data Sources
• Dropdowns
• Sidebars
• FW: FW used for data entry or configuration purposes.

3. Order of Deploy/Import in QG module:

In the QG module, the following entities can be deployed or imported in the listed order:

• Roles: Roles that define user permissions and access within the system.
• Tag Groups: Tags used for categorizing or labeling items.
• Projects: full project configurations.
  Note: when deploying the project, related objects (Data sources and Roles) are also deployed automatically.
• Data Sources: Configuration and mappings for data sources.
• Rules: Business or data rules configured within the system.
• Scripts: Scripts used to automate tasks or configurations.
• Variables: System or user-defined variables for use within processes or scripts.
• Data Sets: Groups of data used in testing
• Tests: Testing configurations.
  Note: When deploying testing configurations, any associated data sets are deployed automatically.
• EFs: Configurations for the order and logic of executing tests.