Before carrying out a process deployment in Bizagi, please consider the following.
1. General requirements regarding processes implementation
1.1 Processes check-in
Make sure that the process versions planned for deployment are all checked-in in the Development environment.
To do so, in Bizagi Studio select Expert View, and click the Processes module.
Processes to be deployed should be all checked-in. Verify that no one else is working on the model, and that the processes can be checked-out:
Coordinate the deployment with other team members of your project, so they are aware of the timing of this procedure and can agree which Bizagi process versions will be deployed.
1.2. Acknowledging how and which objects are deployed
Bizagi handles deployment differently according to what is, or is not, taken to the Production environment. Furthermore, some objects might require special attention when required for deployment.
It is important to understand deployment behavior and features as they vary according to the selected module (Entities, Security, Systems, etc.).
For instance, Parameter Entities have a special configuration in which you can select individually each attribute to be deployed.
1.3. Deciding if your development data should be taken into the environment
Bear in mind that when moving a project from a Development environment to another environment you need to consider whether you need the data that you have been using in the development environment: User's data and parameter entities managed in production. If that is the case, additionally from performing a deployment, a Data Synchronization must be performed.
2. Technical requirements
If you plan on using an authentication method different than Bizagi and you are performing a deployment to an environment with no users on it (normally this would only be the case for a project's first deployment), follow these steps so that you can correctly configure your users and authentication without getting locked out of the Work Portal:
1.Perform the deployment with the authentication method set to Bizagi. This lets you access the Work Portal as the Admon user without providing any credentials.
2.Once in the Work Portal you can manually enter your users, or alternatively you can rely on the method of your choice to synchronize your users' information into the WFUser table (SOAP, Excel file, LDAP Synchronization, or performing a Data Synchronization procedure).
3.Perform an IISRESET so that the Admon user can no longer access the Work Portal.
4.After having your users registered in the Work Portal, use the Management Console to set the authentication method to your preferred one.
If you plan on using LDAP authentication with periodic users synchronization, you may ignore the previous steps since you will only need to wait until the next synchronization happens for your users to be able to log into the Work Portal.
Consider the information below regardless of the type of deployment chosen.
2.1 Environments upgraded to the same Bizagi version
When this is not the first deployment to the same environment (Test or Production already exist), the Development and the target (Test, Staging or Production) environment projects are updated to the same Bizagi release.
To ascertain the version of a project, use the Management Console options to see the project's information:
2.2 Database servers having the same database version.
The database instance of the Test or Production environment needs to have the same version as that of the Database Server in Development.
For Microsoft SQL Server, it means applying the same major version and service packs:
For Oracle, the servers must have the same version and the same release number:
2.3 Database servers having the same character settings
The Database instance of a Test or Production environment needs to have the same character settings as that defined for Development.
If using Microsoft SQL Server, the server collation must match:
For Oracle, the database servers must have the same character set configuration: