Microdeployment

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions > Advanced Deployment > User interface explained >

Microdeployment

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.

Through Microdeployment, as hinted by its name, you can deploy specific, minor changes in your processes.

The image below displays how, for a given process, you can deploy only one specific form (UI).

 

Microdeployment07

 

This article describes the Microdeployment, its prerequisites, considerations, and a step by step guide.

 

Before you start

There are some important aspects to consider before starting a Microdeployment:

 

A Microdeployment, as a procedure, does NOT undergo the same logical 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 you can consider so that it results in 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 envrionment's metadata

The Microdeployment succeeds

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

The Microdeployment fails

 

To use a Microdeployment, some basic environment rules (as those enforced by a traditional deployment) are applicable, such as ensuring that there is only one valid production environment set for one Bizagi project.

A Microdeployment is applicable to both on-premises and cloud projects.

 

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

Document Templates

Message Templates

Forms

Mappings

Queries

 

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

 

What you need to do

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

Consider as an example, that an environment has been already set up having the Vehicle Insurance Policy Underwriting process (as available from our Process Xchange), 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

 

First step (Generate a deployment package including only those specific objects you wish to deploy).

Once changes are implemented, you proceed to generate a .bex file by only considering the form in question.

To do so, go to the seventh step of the wizard and select the Export option.

 

Microdeployment05

 

The Bizagi Advanced Deployment wizard is displayed.

On its top left part there are two tabs, select the Microdeployment option.

 

Microdeployment06

 

A hierarchical tree is displayed where all the objects that can be considered in a Microdeployment are available.

Navigate the tree to find the modified form and tick 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.

 

Microdeployment13

 

Second step (import the package in the target environment).

Head to the management options of your target environment (either the Management portal for cloud environments or by using the ApplyImport.exe tool for on-premises projects), to import the .bex file.

To do so, click the Import option, select the recently created .bex file, confirm that you want to upload it and wait for the process to be finished.

 

Microdeployment08

You can check 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 only available when using the Advanced Deployment or the Export option.

The Microdeployment is NOT available for the One-click deployment feature.

Any object referenced by those ones being deployed must already exist in the metadata, 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 eligble for specific objects of a process, only when such process has already been deployed to that same target environment.

 

Troubleshooting

As mentioned above, a Microdeployment fails whenever you include in the Deployment Package one or more objects of metadata that have not been previously deployed in that same target environment.

In such situations, attempting to import a Microdeployment package displays a message similar to the one shown below.

 

Microdeployment12

 

As hinted by the message, those metadata objects which are not already in the target environment, have their GUIDs displayed for troubleshooting purposes.

Upon clicking Yes, the error message will be copied to your clipboard, allowing you to search for those objects in the Package Visualizer in order to identify them and address the issue later by removing those objects from the Deployment Package.