Bizagi presents a user-friendly Deployment Wizard to publish Processes for their execution to the Production environment, through a quick online procedure.
In this section we will illustrate how to perform a deployment to the Production environment by means of the One-click Deployment featured in Bizagi.
Before reading this document and launching a deployment to the Production environment, make sure you have read both:
1. The prerequisites for a deployment.
2. About Deploying to Test and its Release Candidate option specification.
In addition to this, make sure you:
1. Have at hand the proper license for your production server and the purchased number of supported end users.
2. Take backups for both your Development and Production environment before launching the Deployment.
This is so because Deployment to Production is a procedure that cannot be undone from Bizagi.
It is also strongly recommended to schedule the Deployment and notify about this task plans.
Bizagi's One-Click Deployment will temporarily stop the services, and therefore it should be done in non-working hours.
Deployment to Production
Deploying Processes versions to Production should be done always after having deployed them (and tested them) in the Test environment, with the use of the Release Candidate feature.
Deployments done directly from Development to the Production environment (without having a Test environment) are supported and can be carried out in the same manner as performing deployments to Test (with some slight differences in the configuration); however this is not the recommended procedure.
First deployment to Production (initial deployment)
According to the idea presented in the previous section, a deployment to Production is done through the Release Candidate option as described below.
1. Launch the One-click Deployment Wizard.
Once you have done a deployment to the Test environment and had the Release Candidate test approvals, go to the seventh step of the Wizard (Execute) and click on the Deploy Process option.
2. Use the Apply Release Candidate option.
Given that the most recent deployment was made to Test with Processes marked as Release Candidate, you will be immediately prompted with a window requesting an action for that Release Candidate.
Click on the Apply option for that release candidate.
3. Select the target server
If you are performing a first deployment to the production environment, then you will be presented with the options to select and define which servers will be used for your production environment (both for the Bizagi server and for the database server).
If this is the first deployment, a list of available servers with Automation Server installed will appear as icons (those which are visible to the Development server's network).
Select the target server for the production environment and click on Next.
Notice you may choose to input directly the name of the server in the first server icon if the server's name does not appear within the listed icons.
You may also choose the path where the production environment project files will be stored.
Inputting IP addresses instead of a Server name is supported, but take into account that this while using IP addresses it is necessary to ensure that the IP addresses are not dynamic.
In other words, IP address for servers involved in the configuration of a deployment must not change.
Ensure that you have authorized credentials to create a new environment in that server.
This means that: either the Windows user performing the deployment must be a member of the Administrators and Bizagi groups of the selected server, or you have at hand an authorized account for that server (belonging to those groups, as described at Deployment's previous considerations and requirements).
4. Select the Database Server.
If this is the first deployment, after choosing the server, Bizagi will search for installed databases instances.
Select the target Database Server that will be used for your Production project's database.
You may select the Database instance from the drop-down list, or type directly the database instance's name.
For the Production environment, the project's database name is defaulted as "[myProject]" but you may edit this name as well though it is not recommended that you use the same name of the development environment's project.
Input the database login information and then click Next.
5. Configure advanced options.
•Include users in target environment:
You may choose to initially include the users from the Development environment into your target environment. This option is only available for a first deployment.
•Include records of parameter entities managed in Production
You may choose to take to the target environment the values of those parameter entities which are defined to be managed in Production.
When users are not included for the deployment to Production (the Include users in target environment option is left unmarked), then only the domain\admon user will be automatically created in the Production environment.
This being the case, it is necessary to ensure that the domain\admon user has proper privileges to create other users.
•Add deployment components:
When using Experience components (such as Stakeholders, Contexts, Actions, Searches, Relevant to me, Triggers and My Stuff), make sure you select the items you need to be taken in the deployment. Experience components are independent from the process items, and thus, should be marked individually.
As an example, the Help Desk process in this deployment uses Experience items and are shown when selecting Add deployment components:
This following window displays with a list of all the experience components defined in the project, grouped by entities.
In this case, consider we only want to deploy all experience components for the Stakeholder called Call Center Agent and the actions associated to the Ticket Activities entity.
Following the previous considerations article indications, each item listed will require the following components to be deployed:
•Relevant to me options: Update Customer information and Register New Ticket.
Relevant to me options are process shortcuts. Therefore the process it launches must be related individually when deploying.
Processes that are not explicitly selected will not be deployed, even when they are related anywhere else.
Since the shortcut is dependent from a context, make sure it is selected for deployment as well.
This is a search, thus we need to take into account the stakeholder entity from which the search is available, the entity to perform the search and the contexts where it is available.
If the entity marked does not have attributes, it will not be included in the deployment.
oThe search form is automatically deployed along with the searched entity.
oThe stakeholder from which the search is available is automatically considered when the search is selected.
oThe context related had been selected previously.
•Actions: Register Activity / Solve ticket and Escalate Ticket
Depending on the sort of action different components and objects are related, in this case Register Activity / Solve ticket and Escalate Ticket are form actions. Therefore, the related objects are:
oThe entity where the action is defined, this will also deploy the related form. Since we are ticking the action, this will automatically deploy the entity associated.
oEvery related context. In this case, the action Register Activity / Solve ticket is always available for the Help Desk Agent stakeholder, and is only available under the Not Last Service Level context of the Help Desk Agent stakeholder.
oAny of the actions use a visibility expression, thus it does not relate any entity nor attribute through an expression.
oThe processes where the action can be launched from.
This way all experience components of the Call Center Agent are now ready to be deployed. For further information about relating objects and experience components, please review Relate Objects article.
6. Confirm your deployment configuration.
A summary window will appear showing the configured information related to this deployment.
You may not: add more Processes versions at this point, since the deployment is applying an already tested/accepted Release Candidate, nor change the Production environment server while in the deployment procedure.
To start the deployment click on Finish.
Notice that the wizard will prompt you to close any Bizagi Studio or Management Console that has this same project loaded in order to begin the deployment.
7. Finish the deployment.
The One-Click Deployment will automatically run validations and create the target environment's project (if deploying for the first time to Production).
It will then notify you once the deployment procedure is completed.
When this Deployment finished window is shown, click on Close.
Once the Deployment has been completed, it is possible to run the Production environment Work Portal by using the Run Process option of the Process Wizard´s step 7 (Execute), in which a published URL will be available:
Clicking in the published environment's label will launch the Work Portal:
Subsequent deployments to Production (incremental deployments)
The concept of Subsequent deployments to the Production environment apply to all those deployments done after the first one to that same environment.
In other words, options to deploy a Release Candidate in an existing Production environment will slightly vary from the first deployment.
During subsequent deployments, the existing Production servers (as configured in the first deployment) are updated with the selected Processes versions, and no new project is created (and in other words, you do not need to input again information regarding the location of your production servers).
Main differences in a subsequent deployment to Production involve:
•Backups of the current Production environment database are created.
Before Bizagi starts the deployment, a backup is created and stored at the Database's backup path.
For Oracle databases, this path is defined by the Store database backups path set when configuring an Oracle instance to work with Bizagi.
For SQL Server and in a local setup, this would be at C:\Bizagi\Projects\[your_project]\Backups).
For SQL Server and when using a remote database, this path will be usually set at C:\Program Files\Microsoft SQL Server\[MSSQL_instance]\MSSQL\Backup\.
•While executing a subsequent deployment, there is no direct option to change the current production server or the database server.
Moving an existing Bizagi server to a new one is done through the Server Management options in the Management Console.
If the database server needs to be moved to a different location, this has to be done manually.
Whenever the One-click deployment is not able to locate your existing production environment's database, then it will prompt you for the option to specify the location of the current production database location (if the environment was moved).
It is still required that the entered location to the database corresponds to the actual Production database (Bizagi will validate that this target database is consistent to the expected environment and current state).
•Existing cases in the Production environment are kept consistently in that environment, and will take the changes as defined in the Development version, either through new Process versions or changes in the current Process version.
For further information about handling Process versions for major and minor changes, please refer to the Continuous improvement and development after a deployment.
•There is no option to include users (as an initial load of users from the Development environment).
For further information about the Deployment's treatment and considerations in subsequent deployments, please refer to the Continuous improvement and development after a deployment.