Overview
The following section describes fourth and fifth steps of process deployment, as described in From Studio to the cloud.
In this step, you apply a deployment package into a target environment (e.g, testing or production).
Before you start
Before carrying out this step, make sure you and your software are ready:
•Applying a deployment package is a task that needs to be properly planned, coordinated, scheduled and communicated. It implies planned downtime for the service.
•Make sure the Automation Service environment you are going to import the package into has been created, even if it has not been in use yet (i.e., testing, production).
Required profile
The person in charge of this step should be authorized to administer Automation Service environments.
This person does NOT need to be technically skilled since no programming or IT-related tasks are involved. A self-service UI guides the person in charge of this step through the process.
Note that the Import processes option is available in the Management Console available through your Automation Service subscription.
The person in charge of the import will need:
•To have access to the deployment package (.bex file) created in the previous deployment step.
•Internet connectivity and a browser to access the Management Console (as well as credentials with authorized access).
The person does NOT need access to Bizagi Studio (the Development environment).
Deployment package lets you apply a deployment package into a target environment (e.g, testing or production).
How to import a development package
Follow these steps to import a deployment package.
1. Click Upload new package to upload the deployment package
2. Select the .bex file containing the deployment package.
Note that the file name given has no functional significance. However, make sure you are uploading the correct file.
3. Double-check and explicitly confirm this action by clicking Upload package.
Uploading and applying the package involves importing processes, and may take a few minutes:
Once the upload is complete and successful, the package details appear. You can see the content of the package using the package visualizer to see its content using the View content button or cancel the upload.
Click Import if you want to apply the given package in your environment. A window appears showing that this procedure will start the Maintenance Window.
You can click Object list to see the objects included in the packages that have changed.
|
Bizagi has some configurations that can be managed per environment directly from the Management Console (e.g., environment configuration, authentication and authorization configuration, and external systems). Other setups done in the Work Portal such as Live Processes, theme builder and localization, are also independent per environment.
If a deployment package contains metadata related to parameters or environment's configuration, this is only applied to the environment in the first deployment. Subsequent deployments do NOT replace these metadata, because the configurations must be done directly in the environment through the Management Console or the Work Portal. Furthermore, these configurations override any deployment package settings. |
Click Import package to confirm.
Once the procedures is complete and successful, its details are added to the deployment history with status Done. Otherwise, an error message appears.
Zero Downtime Deployment
Any deployment does not need any maintenance window or any reset in the environment. The maintenance window is automatically activated in the following scenarios:
• first deployment
•if the content of the .bex file contains environment configurations.
•If you deploy component libraries.
•If you deploy library rules.
If the .bex file does not match any of the scenarios mentioned, you can apply the package without stopping the environment. That is, current sessions and the execution of the Work Portal for end-users are not affected, and they can continue working on the environment while the package is imported.
Considerations
•For changes in processes that are critical or important, it is suggested to perform a reset of the environment. For example, if you change attribute types, validation rules, or rules that affect the flow of the process.
•Be careful when you deploy changes that affect the execution of tasks or processes. For example, if you change an attribute type in the deployment, it is possible that rules or execution of forms are affected. If this issue is presented to a user, after deployment, it is recommended that the user refreshes the whole site, so the form loads new changes after the cache has been flushed.
Deployment history
The Previous processes table shows you the previous deployments performed. This table has the following columns:
NAME |
DESCRIPTION |
|---|---|
File name |
Name of the deployment package. |
Load status |
Defines the result of the package upload. Possible values are Error and Done. |
Uploaded by |
Name of the users who uploaded the deployment package. |
Uploaded date |
Date when the deployment package was uploaded. |
Upload Time |
Time when the deployment package was uploaded. |
View content |
Opens the package visualizer to see the content of the deployment package. This option is available when the package was successfully applied. |
Download |
Downloads a copy of the deployment package. This option is available when the package was successfully applied. |
Last Updated 2/10/2022 6:35:18 PM