Production environment deployment

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions > One-click Deployment >

Production environment deployment

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.

 

note_pin

We also strongly recommend that 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.

 

Deployment01_ReleaseCandidate

 

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.

 

Deployment01_Step7

 

2. Use the Apply Release Candidate option

Since the most recent deployment was made to Test with process versions marked as Release Candidate, Bizagi promts you to select an action for that Release Candidate.

 

Deployment_W11_Apply

 

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.

 

Deployment00_ProdServer

 

You can also choose the path to where the production environment project files will be stored.

 

note_pin

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).

 

deploytest_authentication

 

 

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.

 

Deployment01_Proddb

 

Provide the database login information and click Next.

 

5. Configure advanced options.

 

Deployment02_ProdAdvancedoptions

 

Include users in target environment:

You can choose to include users from the Development environment into your target environment. This option is only available for the first deployment.

Include records of parameter entities managed in Production

You can choose to copy to the target environment the values of parameter entities which are managed in Production.

 

note_pin

When users are not included for deployment to Production (the Include users in target environment option is left unselected), 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:

 

advanced_components_2

 

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.

 

experience_components1

 

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.

 

advanced_components_3

 

Relevant to me options are process shortcuts. Therefore the process it launches must be related individually in the deployment.

 

experience_components2

 

experience_components3

 

note_pin

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.

 

experience_components4

 

Search: Cases

 

advanced_components_4

 

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.

 

experience_components5

 

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.

 

experience_components4

 

Actions: Register Activity / Solve ticket and Escalate Ticket

 

advanced_components_5

 

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.

 

advanced_components_6

 

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.

 

advanced_components_7

 

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.

 

advanced_components_8

 

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.

 

Deployment03_ProdSummary

 

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.

 

Deployment11_Gowarning

 

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).

 

Deployment04_ProdCreateproject

 

It will notify you once the deployment procedure is completed.

 

Deployment05_ProdFinished

 

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:

 

Deployment_After

 

 

 

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 will offers you the option to specify the location of the current production database location. This is useful if the environment was moved.

 

Prod_MigratedDB

 

note_pin

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.