Overview
Often, there are situations where you need to apply a minor change into a specific part of a project without affecting the majority of it.
Given that in such situations, you still need to deploy changes, as minor as they can be, you need to make sure that such deployment does not include objects which may alter other parts of your project.
Some examples of those situations are:
•The need to change some specific texts or labels on Forms.
•Change only one Query Form.
•Change one business rule.
•Change execution properties of a Task, such as retry count or asynchronous behavior.
For such situations, Bizagi introduces the Microdeployment feature.
Considerations with Bizagi versions
A Microdeployment considers the same restrictions as a normal deployment. When you are microdeploying you have to make sure that the version of your target environment, Test or Production, has the same version or superior from your Development environment.
For example, you can deploy from Spring 2025 to Summer 2026, or from Fall 2025 to Fall 2025. You cannot apply a Microdeployment for lower versions, for example, from Summer 2025 to Fall 2025.
Before you start
There are some important aspects to consider before starting a Microdeployment:
•A Microdeployment, as a procedure, does NOT undergo the same configuration steps of a traditional deployment. You may consider the Microdeployment as a shorter and faster procedure when compared to other deployments.
•As such, a thorough Dependency Analysis is NOT performed when exporting a package to an environment.
This means that any metadata included in the exported .bex file must already exist in the environment where that .bex will be imported into, for example the Test or Production environment.
•In addition to general metadata considerations, this also applies specifically to task related elements. References to forms, rules, or dependent elements are not transported and must already exist in the target environment.
In other words, when performing a Microdeployment there is one aspect to consider for a successful deployment: object references.
The following table summarizes the possible outcomes:
Situation |
Outcome |
|---|---|
Objects being deployed only refer to other objects already present in the target environment metadata |
The Microdeployment succeeds |
Objects being deployed refer to other objects not present in the target environment metadata |
The Microdeployment fails |
|
To use a Microdeployment, the basic environment rules remain applicable, such as making sure that there is only one valid Production environment set for one Bizagi project. |
What can you include in a Microdeployment?
Not all objects can be included in a Microdeployment due to some of them having complex references.
The following list considers objects which are eligible:
•Activity Actions
•AI Agents
•Custom columns
•Document Templates
•Forms
•Mappings
•Message Templates
•Parameter managed in Development
•Performers
•Processes shared to Live Processes
•Queries
•Rules
•Search Forms
•Start Forms
•Triggers
•Vocabularies
Additionally, Microdeployment supports Task level updates, allowing you to transport specific execution properties of the following objects:
•User Tasks
•Service Tasks
•Manual Tasks
•Events
•Gateways
Objects not included in this scope:
•Sequence flows or connectors
•Artifacts
•Subprocesses as independent objects
Task Microdeployment
Task Microdeployment allows you to update specific properties of tasks within a process without redeploying the entire process or affecting unrelated elements.
Supported properties
Only execution related properties are included, such as:
•Name
•Display Name
•Retry Count
•Asynchronous State
Visual modeling properties, such as position changes, are excluded and do not appear in the Graphic Query.
Behavior and scope
•Only the main object is transported and references remain as identifiers.
•Child objects and referenced elements are excluded.
•The package contains only the properties of the selected object.
•Existing validations and deployment rules remain unchanged.
Considerations
•The Parent Process must already exist in the target environment.
•Subprocess type tasks are supported only if the related process already exists in the destination environment.
•You are responsible for ensuring required dependencies are already deployed.
Microdeployment of a Process
To perform a Microdeployment:
1.In Bizagi Studio, go to the Export/Import tab and select the Microdeployment option to retrieve the list of available objects.
2.Select one or more objects.
3.Generate a package that contains only the selected objects.
4.Go to the Management Console of the target environment and import the package.
5.Wait for the system to validate and apply the changes.
6.Review the Audit log where each operation is recorded automatically.
Example
An environment has been already set up having the Vehicle Insurance Policy Underwriting process, which is operational in a Production environment.
In this example, the Microdeployment targets a cloud environment.
Description
The initial state of this scenario is:
•The Vehicle Insurance Policy Underwriting process has a first activity called Register Client and Vehicle Data.
•The Form for that activity looks as shown in the image below.
•Your manager pointed out that the Case information group shown in the Form is no longer desired. In other words, you will need to delete this Case information group from the Form.
•Assuming you and your team colleagues are currently working in the Development environment, while implementing other unfinished changes, then it becomes clear that you need to perform a Microdeployment, so that those other changes do not affect operations of your process.
Performing the changes in the Development environment
The first thing is actually making the minor changes to the process (as pointed out by your manager).
In the following image, you can see how the group is not present anymore and the Policy Owner Information is now the uppermost element of the IP_CustomerVehicleBasicData Form:
Generate a deployment package including only those specific objects you wish to deploy
1.Once changes are implemented, you proceed to generate a .bex file by only considering the Form in question. To do so, go to the Export/Import tab and select the Microdeployment option.
2.In the Microdeployment wizard window, you must select Microdeployment type between Processes and Experience Matrix. For this case, select the Processes view.
3.Then, you must filter the objects you want to deploy. Select the objects in the left panel of the wizard and in the right panel, select the process and/or subprocess of the selected objects. You can search Filter the objects you want to export. You can use the Filter field to find the process. Once you have selected the items, click the Next button.
According to your selection, a list shows all the objects that can be considered in a Microdeployment are available.
4.Use the Filter field or navigate the panel to find the modified element and check it to indicate that it is included in the Microdeployment.
5.Click the Export button and select a directory in your machine where you want the deployment package (.bex file) to be saved.
Import the package in the target environment
To import the package in the target environment follow these steps:
1.Head to the Management options of your target environment to import the .bex file. You can do this from the Management Console.
2.To do so, click the Import option or Upload new package option in Management Console and select the recently created .bex file. Confirm that you want to upload it into your environment and wait for the process to be finished.
You can make sure that the Microdeployment was successful, by checking the Form of the first task, making sure that the Case information group is no longer present. Since the import did not result in an error, you can assume that no new metadata was introduced by the import within your target environment.
Thus, you can rest assured that no unintended changes were mistakenly included.
At this point you have successfully carried out a Microdeployment, and your manager's request is now fulfilled.
|
Consider the following when using a Microdeployment: •The Microdeployment is available when using the Deployment. •Any object referenced by those being deployed must already exist in the metadata of the target environment. •These referenced objects are NOT automatically included because a full Dependency Analysis is not performed. This also applies to task related objects and their dependencies. •If you are microdeploying Custom Columns, make sure that variables or vocabularies are previously deployed. •Task Microdeployment only includes execution properties and does not transport related forms, rules, or visual configurations. •The package includes only the selected object properties, ensuring minimal impact on the target environment. •In Automation service, a maintenance window can be triggered automatically if the Microdeployment package contains an element that requires resetting the cloud-based environment. Refer to the Bizagi Cloud Maintenance window documentation for more information. |
Troubleshooting
A Microdeployment fails when the package includes metadata objects not already present in the target environment.
If this happens, review the deployment logs in the Management Console under Track > Tracing > Execution. These logs help identify the missing objects by showing their GUIDs, so you can resolve the issue accordingly.
Last Updated 1/7/2022 4:31:56 PM