Microdeployments

<< Click to Display Table of Contents >>

Navigation:  Low-code Process Automation > Studio Cloud - Authoring environment > Deployment  > How to generate a deployment package >

Microdeployments

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 doesn't 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, or change one business rule. 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 11.2.2 to 11.2.4, or from 11.2.4 to 11.2.4. You cannot apply a microdeployment for lower versions, for example, from 11.2.4 to 11.2.2 is not possible.

 

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 (e.g. Testing or Production environment).

 

In other words, when performing a Microdeployment there is one aspect that 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 that are already present in the target environment's metadata

The Microdeployment succeeds

Objects being deployed refer to other objects that are not present in the target environment's metadata

The Microdeployment fails

 

To use a Microdeployment, some basic environment rules (as those enforced by a traditional deployment) are 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 for a Microdeployment:

 

Rules

Mappings

Message Templates

Forms

Document Templates

Queries

Start forms

Search forms

Custom columns

Triggers

Processes

Processes shared to Live Processes

Parameter managed in development

 

Any other type of objects are not available, and so, these are not shown in the Microdeployment wizard.

 

Microdeployment of a Process

The following steps provide a high level outline of the actions that you need to follow to successfully carry out a Microdeployment.

 

1.Generate a deployment package including only those specific objects you wish to deploy.

2.Import the package in the target environment.

 

Example

An environment has been already set up having the Vehicle Insurance Policy Underwriting process, which is operational in a Production environment.

For this example, the Microdeployment targets a cloud environment.

 

Microdeployment01

 

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 (UI) for that Register Client and Vehicle Data looks as shown below.

 

Microdeployment02

 

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:

 

Microdeployment04

 

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.

 

Microdeployment05

 

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 serach Filter the objects you want to export. You can use the Filter field to find the process. Click Next.

 

Microdeployment14

 

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.

 

Microdeployment07

 

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 (MC).

2.To do so, click the Import option or Upload new package option in Management Console (MC) 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.

 

Microdeployment08

 

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 unfinished/undesired changes were not mistakenly included.

 

Microdeployment09

 

At this point you have successfully carried out a Microdeployment, and your manager's suggestion is now fulfilled!

 

 

Important considerations

Consider the following when using a Microdeployment:

The Microdeployment is available when using the Deployment.

Any object referenced by those ones being deployed must already exist in the metadata of the target environment, otherwise the Microdeployment procedure will fail.

Those referenced objects are NOT automatically included (because a thorough Dependency Analysis is not performed).

For this reason, a Microdeployment is eligible for specific objects of a process, only when such process has already been deployed to that same target environment.

If you are microdeploying Customize Columns, make sure that the variables or vocabularies, are previously deployed so its metadata exists in 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

As already mentioned, a Microdeployment fails whenever one or more metadata objects are included in the deployment package that have not been previously deployed to the same environment.

 

It is important to review the deployment logs, in case any errors occur during the export of the package.

 

In these situations, when trying to import the .bex file, a message similar to the one shown in the following image is displayed.

 

Microdeployment12

 

The message shows the GUIDs of those objects whose metadata was not present in the target environment, so that you can analyze it and use that information to solve the problem.


Last Updated 12/10/2024 12:29:23 PM