Advanced deployment considerations

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Deployment  > Advanced Deployment >

Advanced deployment considerations

Overview

Before you continue with the deployment make sure you acknowledge the following considerations.

 

1. Initial deployment through the One-click Deployment recommended

When running your Processes in a .NET platform, it is recommended to perform an initial deployment (the first deployment) through the One-click Deployment.

This will assist the creation of the target environment (Work portal, database and Scheduler service) and allow Bizagi to validate objects which should not be deleted or modified from that point on, in the Development environment.

If using the One-click Deployment for this purpose is not suitable, then you will need to create the initial database with Bizagi's blank model through the Advanced Deployment executable files.

 

2. Once through Advanced Deployment, there's no turning back.

It is OK, if you choose to switch to the Advanced Deployment if you had already used the One-click Deployment (but not vice versa).

This means that once you choose to use the Advanced Deployment  to perform your Deployments, it will not be possible to go back and attempt to use the traditional One-click Deployment available in Bizagi Studio.

 

In other words, for any project which has already used the Advanced Deployment, any Deployments will need to be done using the same Advanced Deployment.

 

3. Always create backups.

The Advanced Deployment does not create backups of any database.

Remember that as a contingency measure, it is always recommended to take backups of all your existing environments before doing major changes to any environment.  Major changes include a Deployment by either the advanced or traditional One-click procedure.

 

This means that when using the Advanced Deployment, a backup snapshot of your target environment (Test or Production) should always be taken at least before applying any Import files.

 

4. Do not delete objects in development unless unused in production

It is really important that you acknowledge the following: when using the Advanced Deployment, Bizagi Studio won't be performing any validations for dependencies. This means being able to tell if an object has been already deployed to Production.

Due to this, it is strictly required that objects in the Development environment are not deleted (when being used in Production already), and that you always create new versions of Processes whenever you need to perform adjustments over Processes.

 

5. Plan and coordinate your deployment

Similarly to the One-click Deployment, it is recommended to schedule and perform the Advanced Deployment at non-working hours.

This also promotes any contingency measure towards restoring a backup (previous snapshot of the solution), should the Deployment results not be as expected.

 

6. Consider additional environments if needed

When Processes instances are critical, and depending on the nature of the changes incoming from Development (i.e it is strictly needed to test existing instances), you may choose to use an alternative environment (Staging or Production Replica), used to perform rigorous testing and user acceptance tests, especially focused on the existing Production cases (live Process instances).

This means that beforehand, you should create a temporary environment for the sole purpose of testing the final Deployment into Production.

By doing this, and through a backup and restore approach, you would have a way to review if any changes or additional information are required for the Deployment.

When using such environment, make sure that the SMTP Server, any configured interfaces, ECMs or data providers, the set e-mails for your users or any other setting, does not trigger your actual Production settings.

 

7. Conditions to include objects in the deployment package

Take into account the conditions used by Bizagi to include objects in a deployment package.

 

Objects that are part of the processes to be deployed: the deployment package contains all objects that make up the processes chosen to be deployed. For example business rules, allocation rules, forms, entities.

Components being used in the process. The deployment package includes components used in the chosen processes. For example, if a rule uses the Holiday schema, said holiday schema is included in the deployment package.

Objects that have been manually selected in the Advanced tab: if you select an object in the Advanced tab, it is included in the package even if it is not being used in the processes to deploy.

 

These conditions are not exclusive. Therefore, if one of them is met, the component is included in the package. For example, if you leave unmarked the Roles element but the chosen processes use a role, the roles are included in the deployment package.

 

The following elements have intrinsic composition. This means that if one of the elements is included due to any of the conditions above, all the other elements of the same type are included:

oRoles

oSkill

oAreas

oPositions

oLocation

oOrganization

 

If you use attributes in complex or dynamic expressions and those attributes are not used anywhere else, you need to force them to deploy.

 

Required profile

The profile of the user working with the Advanced Deployment needs to:

1. Have a basic understanding of XML structure (in order to configure the config files).

2. Have access to the project environments' Databases (with the superuser credentials).

3. Have expertise or important know-how, about the concepts involved in a Deployment of a project in Bizagi.

For more information about the treatment for deploying objects in Bizagi, refer to deployed objects.

4. Have an understanding of the implemented Processes in the project.

This means knowing about these processes' purposes, data model, versions, integrations, security settings, environment settings management (i.e policy, alarms, parameter entity values), and general workings.

 

Take into account that for proper testing (carrying our user acceptance tests), this will include being able to tell which is the expected behavior of the Processes in the Work Portal (under the different business scenarios).