Bizagi presents an Advanced Deployment as an alternative to the One-click Deployment in Bizagi Studio, to perform Deployments of Processes in specific scenarios having sophisticated requirements.
For more information about the One-click Deployment which assists this process (automatically deploying process packages in an online manner), refer to Deploying your processes.
When to use the Advanced Deployment?
Deployments of Processes is done once the automation stage is completed and when you wish to publish your processes into a Test or Production environment.
The Advanced Deployment will offer further possibilities for the following specific scenarios:
1. Projects requiring an Offline Deployment.
Offline Deployment is needed when there is no network connectivity between the development environment (where the Studio is) and the final production environment (i.e, located in the cloud, a data center on a different network, etc).
2. Projects having automation of processes in a parallel schedule.
Applies for large scale projects in which a large number of users are working in a collaborative environment, and some processes are ready to go live, but others are still being automated.
In that case, you may choose to use the Advanced Deployment if you want to quickly publish those ready processes without holding the progress of the other processes (in other words, you can publish processes while others are being worked on).
3. Projects with more than the three default environments.
Some mission-critical processes or some corporate policies may demand the use of additional environments to those three default ones presented in the One-click Deployment in Bizagi.
The One-click Deployment will consider its main Development environment, alongside a Test and Production environment.
When using additional environments such as a Staging or Production replica environment, you will need to use the Advanced Deployment.
4. Projects in which you want to keep certain previous information
The Advanced Deployment offers a more flexible procedure than the traditional deployment, mainly because it enables revision and modification of each change in the Development environment which will be published into the Test or Production environment.
This comes in handy for advanced users which are certain of changes they don't want to publish.
In this way, all of the objects in Bizagi (Entities, rules, forms, etc) from one or more processes, can be explicitly selected or unselected (to disregard them) for the deployment to the target environment.
This includes the possibility of preserving cases in the Test environment as well.
How does the Advanced Deployment work?
Briefly, the Advanced Deployment will allow you to select the Processes and Sub-Processes (their versions) which will be published to Test or Production, through a set of 4 executable files. This procedure ensures that the metadata from the development environment gets deployed into the target environment. This means that the Advanced Deployment sets up your target environment with everything it needs to execute your application, but it does not introduce any data into that environment.
You can optionally:
•Include objects which are not necessarily attached to the selected Processes, in order to force-include them in the deployment.
•Exclude objects which you do not want to deploy because your are certain you don't want/need them in your production environment.
This information is exported into a Deployment package file (in Bizagi, this file will be using the .bex extension).
The .bex file is taken to the Production server, and this file becomes an input to analyze and preview the importing actions (those carried when publishing into an existing Test or Production environment), in order to make sure that the objects will be taken as planned.
The analysis in this point, launches a comparison against the target environment involved in the Deployment applying.
In order to move data from one environment to another, Bizagi features the Export and Import data procedures that can be launched from the management console. For more information regarding the deployment of data refer to Data Synchronization.
Before you continue, 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.
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:
If you use attributes in complex or dynamic expressions and those attributes are not used anywhere else, you need to force them to deploy.
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).
Performing an Advanced Deployment
There are several ways to conduct the Advanced Deployment procedure:
•By relying on the dedicated user interface.
Bizagi comes out of the box with a set of tools to deploy a project. Those tools are specific programs that guide you step by step through a user interface where you provide all the required information and options to tailor your deployment.
For detailed information on how to deploy a project by relying on the user interface refer to Advanced Deployment executables.
•By using the Command Line utilities.
Bizagi provides a set of Command Line tools to fully deploy a project from a command prompt. This is especially useful if you don't have access to the machine hosting the target environment and you will remotely perform a deployment, and this also allows the creation of scripts to automate your deployment workflow.
For detailed information about deploying your projects through the Command Line deployment, refer to Command Line for Advanced Deployment.