Overview
Bizagi presents a user-friendly Deployment Wizard to publish process versions to the Production environment, through a quick online procedure.
In this section we explain how to perform a deployment to the Production environment by using the One-Click Deployment feature in Bizagi.
Prerequisites
Before reading this section and launching a deployment to the Production environment, make sure you have read both:
1. The prerequisites for a deployment.
Click for more information about the Previous considerations and requirements of a deployment.
2. About Deploying to Test and its Release Candidate option specification.
Click for more information about Deploying to Test.
In addition to this, make sure you:
1. Have available the proper license for your production server and the number of supported end users.
Click for more information about Licensing.
2. Make backups of both your Development and Production environments before launching Deployment.
This is important because Deployment to Production is a procedure that cannot be undone from Bizagi.
|
We also strongly recommend you to schedule the Deployment and make your team aware of it. Bizagi's One-Click Deployment will temporarily stop Bizagi services, and therefore it should be done during non-working or off-peak hours. |
Deployment to Production
Deploying process versions to Production should only be done after you have deployed them to and tested them in the Test environment, using of the Release Candidate feature.
You can deploy directly from Development to the Production environment (without having a Test environment) 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)
As discussed in the previous section, a deployment to Production is done through the Release Candidate option. Here are the steps:
1. Launch the One-Click Deployment Wizard
Once you have done a deployment to the Test environment and had the Release Candidate tested and approved, go to the seventh step of the Wizard (Execute) and click Deploy Process.
.
2. Use the Apply Release Candidate option
Since the most recent deployment was made to Test with process versions marked as Release Candidate, Bizagi prompts you to select an action for that Release Candidate.
Select the Apply option for the Release Candidate.
3. Select the target server
If you are performing a first deployment to the Production environment, Bizagi lets you select and define which servers to use for your production environment (for the Bizagi server and for the database server).
The list of available servers (visible to the Development server's network) with Automation Server installed appears as icons.
Select a target server for the production environment and click Next.
You can provide the name of the server you want in the first server icon if it does not appear in the list.
You can also choose the path to where the production environment project files will be stored.
|
Inputting an IP address instead of a server name is supported, but make sure the IP address is not dynamic. IP addresses for servers involved in the configuration of a deployment must not change. |
Make sure that you have authorized credentials to create a new environment in that server.
Either the Windows user performing the deployment must be a member of the Bizagi and Administrators group 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, you choose the server, Bizagi will search for installed database instances.
Select the target Database Server for your Production project's database.
You may select the Database instance from the drop-down list, or provide database instance's name.
For the Production environment, the project's database name is "[myProject]" by default, but you can edit this name. We do not recommend that you use the name of the development environment's project.
Provide the database login information and click Next.
5. Configure advanced options.
|
Only the domain\admon user will be automatically created in the Production environment. Make sure that the domain\admon user has the 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), select the items you need to be included in the deployment. Experience components are independent from the process items, and need to be selected individually.
As an example, the Help Desk process in this deployment uses Experience items that are shown when you select Add deployment components:
The following window displays a list of all the experience components defined in the project, grouped by entities.
In this case, we only want to deploy experience components for the Stakeholder called Call Center Agent and the actions associated to the Ticket Activities entity.
As we have explained, 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 in the deployment.
.
|
Processes that are not explicitly selected will not be deployed, even when they are related to elements that are deployed. |
Since the shortcut depends on a context, make sure it is selected for deployment as well.
•Search: Cases
This is a search, so 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 included 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 selecting the action, this will automatically deploy the associated entity.
oEvery related context. In this case, the action Register Activity / Solve ticket is always available for the Help Desk Agent stakeholder, under the Not Last Service Level context.
oAny of the actions use a visibility expression, thus it does not relate any entity nor attribute through an expression.
oThe processes from which the action can be launched.
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 Related Objects.
6. Confirm your deployment configuration.
A summary window shows the configured information related to this deployment.
You may not: add more Process versions at this point, since the deployment is applying an already tested/accepted Release Candidate, or change the Production environment server while in the deployment procedure.
To start the deployment click Finish.
The wizard prompts you to close any Bizagi Studio or Management Console that has this same project loaded before you begin the deployment.
7. Finish the deployment.
The One-Click Deployment automatically runs validations and creates the target environment's project (if you are deploying to Production for the first time).
It will notify you once the deployment procedure is completed.
When this Deployment finished window appears, click Close.
Once the Deployment has been completed, you can 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:
Click the published environment's label to launch the Work Portal:
Subsequent (incremental) deployments to Production
The concept of subsequent deployments to the Production environment applies to all deployments after the first one to that same environment.
Options to deploy a Release Candidate as a subsequent deployment to an existing Production environment will slightly vary from what you saw in the first deployment.
During subsequent deployments, the existing Production servers (as configured in the first deployment) are updated with the selected Process versions, and no new project is created (so you do not need to provide information regarding the location of your production servers).
The main differences in a subsequent deployment to Production involve:
•Backups of the current Production environment database are created.
Before Bizagi starts the deployment, it creates a backup and store it at the database's backup path.
For Oracle databases, this path is defined by the Store database backups property 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 usually be C:\Program Files\Microsoft SQL Server\[MSSQL_instance]\MSSQL\Backup\.
•While you execute a subsequent deployment, there is no direct option to change the current production server or the database server.
You can move an existing Bizagi server to a new one 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 One-Click Deployment is not able to locate your existing production environment's database, it offers you the option to specify the location of the current production database location. This is useful if the environment was moved.
|
The entered location for the database must correspond to the actual Production database location (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 take 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, refer to 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 subsequent deployments, refer to Continuous improvement and development after a deployment.