From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

Jump to: navigation, search

<keywords content="keywords"> deployment, metadata, publish, environments, recommended practices, environment, administration, metadata administration, deployment features, deployed objects, deployed, deploy, parameter deployment </keywords>

Deployment workings and considerations

It is strongly suggested to acknowledge the following information about deployment in Bizagi:

Bizagi Dependency Engine

Bizagi has a dependencies engine which will run some integrity validations to detect if there are any integrity issues within the project's design and modeling.
This dependencies engine will also detect which entities, forms, rules, etc. are being used by the processes versions to be deployed (so that they are taken into the target environment).
Those entities, forms, rules, etc, in the Development environment which are not used by the processes versions to be deployed, will not be taken into the target environment.

Bizagi Dependency Alerts

Within the integrity validations ran by the dependencies engine, Bizagi may show warning messages (alerts) identified by a yellow icon.
These are not errors and will not stop the deployment execution, nor result in a failed deployment or environment creation.
Alerts can show up best practices considerations or even prompt you about an entity having too many attributes (more than 50), in which case an entity with too many attributes can result in a slower performance while running queries that look up for data in that particular entity.

Parameter Entities Administration Definition

Each parameter entity has in its advanced properties, a definition that states if that particular entity is designed to be managed either in the Production environment or for the Development environment.

Therefore, it is recommended to thoroughly take into consideration and review which parameter entities' values are expected to be deployed from Development into Production.
Notice that parameter entities will not be allowed to be managed in both Development and Production environment; it is necessary to define in which environment will the values for each entity be inserted, edited or disabled.

Even though for the first deployment all the values for the parameter entities are taken from the Development environment to the Production environment (regardless of this definition), in subsequent deployments only the values of parameter entities which are managed in the Development environment are updated and taken into the Production environment.

To set or review this setting, go to the Entities module in the Modules View.
Expand the parameter entities classification to locate a given parameter entity. Right click and select the Advanced Properties option.

Under the Instances tab, you may view or mark the checkbox that sets that the entity is "Manageable in Production" (its values in Development will not be updated into Production).

Alert: Take into account that in order to change this setting, the entity needs to meet certain conditions regarding its attributes-relationships and other considerations. View information about recommendations for your parameter entities administration.

Test and Production settings

Take into account that there are several modules settings which have different values that can be set for each environment.
The environment values presented in Bizagi Studio for the Test and Production environments, may have their values initially set for the first deployment to those environments (so that these values are automatically applied to the target environment).
However and after the first deployment, the administration for these options has to be done directly in the target environment by using Bizagi Management Console.

The previously described applies for the following modules:

Environment options

In the Development environment, you may initially set the values for the "Environment options" that will apply for the Test and Production environment.
This can only be done before the first deployment to that environment is made.

Once the configuration is applied to that given environment, those parameters and definitions for the Test and Production environment will not be editable in the Development environment anymore (through Bizagi Studio); and therefore modifications for those values needs to be done in each environment separately (by using the Management Console).

View more information about the environment configuration and options.

Systems configuration

Interfaces Properties

When creating a New Interface, you may set and define its properties values (URL, web method, and authorization credentials) for each environment.

However, once that interface has already been taken to the Test or Production environment, its properties' values for the other environments may not be edited in the Development environment anymore.

Summarizing and for interfaces, any edition to values existing in the Test or Production environment needs to be done in each environment separately (by using the Management Console).

View more information about the interfaces integration feature.

Provider Properties

When creating a New Provider for the Virtualization or Replication feature, you may set and define its properties' values for each environment.

However, once that interface has already been taken to the Test or Production environment, its properties' values for the other environments may not be edited in the Development environment anymore.

Summarizing and for providers (virtualization and replication features), any edition to values existing in the Test or Production environment needs to be done in each environment separately (by using the Management Console).

View more information about virtualization and replication.

ECM Properties

When creating a New Repository, you may set and define its properties' values for each environment (this includes the folders for the repository).

However, once that the ECM configuration has already been taken to the Test or Production environment, its properties' values for the other environments may not be edited in the Development environment anymore.

Summarizing and for ECM integration, any edition to values existing in the Test or Production environment needs to be done in each environment separately (by using the Management Console).

This same concept applies for the folders definition in the ECM integration.

View more information about ECM integration.

Authentication and LDAP settings

The options presented in the Security module for the authentication options and LDAP in your Bizagi project, may be initially defined before the first deployment.

After the first deployment is done to the Test or Production environment, the administration of these settings is handled separately in each environment.
For example, after a first deployment to Production, editing the authentication type and options or editing the LDAP configuration in Bizagi Studio (the Development environment) will only apply for the Development environment.
Changes in the authentication type and options and/or the LDAP configuration for the Production environment has to be done directly in that environment by using Bizagi Management Console.

View more information about the Security module.

Alert: The treatment and administration for the Authentication and LDAP settings do not apply for the Authorization configuration. Authorization configuration done in the Development environment applies for the Test and Production environments since this settings are deployed into the target environments.

Users

For the first deployment to the Test or Production environment, Bizagi's users (those in WFUSER system entity) can be taken to the target environment (optional).
However and after the first deployment, users administration is done separately for each environment (through the work portal).

For example, new users for the Production environment must be created in the Production environment.

View more information about the Users administration.

User groups in the Organization

Creation of the elements in your Organization for the project (areas, positions, skills, roles, user groups, etc...), is done only in the Development environment.
Although this includes user groups as well, these in particular can be edited in the Production environment by including or removing users for that user group (but these cannot be created nor deleted in the Production environment).

View more information about user groups.

General Concept for Subsequent Deployments

If after a deployment to the Production environment, the final users request or identify that changes are required for your processes in Production, remember that these need to be done in the Development environment (and taken into Production by using the deployment procedure).
Bizagi promotes process improvement, but take into account that the continuous improvements of your processes still need to follow the recommended deployment cycle.
View more about continuous improvements and development after a deployment.

Personal tools

Views

Deployment Workings And Characteristics