Overview
As part of continuous process improvement, Bizagi supports flexibility and evolution of your processes as your business evolves.
Sometimes this involves making changes to business data, business rules, interfaces or even the flow of the processes themselves.
Important
Objects that have been deployed to the Development environment should not be deleted or renamed (the object name, not the display name). If you delete or rename existing Development environment objects, your next deployment to production may fail. Bizagi may indicate that the deployment package is not adequate (to guarantee data integrity in the Production environment).
|
If you wish to stop using a certain object, such as a process, in a Production environment, just disable the object. And, of course, deleting an object in the Development environment does not remove it from any Production environment to which it has been imported. If you want to deprecate an entity or attribute, you need to create a new process version which references different entity or attribute than the one you want to deprecate. |
When to create versions for processes?
Depending changes you need to make, we recommend that you generate new versions of processes that have already been deployed to a Production environment.
This is a safe way to make changes without compromising the information of the current cases being executed in the Production environment.
When you deploy a new process version, live existing cases continue to be worked on by the process version for which they were originally created.
However, publishing minor modifications to existing processes is also possible. You can perform improvements right in the same deployed process version, as long as current cases do not conflict with those changes and adjustments. Testing in a Staging environment, with data created using the earlier version of the processes, is very important to make sure that small changes do not have large consequences.
Creating new versions
As a good practice, make sure to version your processes when you are about to make changes.
To do so, go into the Processes module and right-click a specific process version. From the options that appear, select New Version:
To view a detailed guide about the best conditions for creating new process versions, refer to Guidelines for new version
Incremental deployments
When you consider incremental deployments, remember that when you deploy new processes or new process versions, existing cases continue to follow their workflow, using the existing process for which they were created in the target environment.
Depending on the nature of your changes, you need to decide if you want to employ a Staging environment to validate how these existing cases will behave after the changes are in place.
To perform incremental deployments, in general you follow the same procedure as when deploying processes for the first time, though there are some differences (mainly about certain objects which are only deployed from the Development environment for a first deployment).
For information about the steps involved in a deployment, refer back to this chapter's main section: From Studio to the cloud.
Synchronizing data from another environment
It is a common and recommended practice to create users and use cases in your authoring environment. If you have done so, and the information you have used in the Development environment is real data that you need to have in your target environment, the easiest way to transfer that information without having to create it once again is to perform a Data Synchronization. In such procedure, you can handpick which data elements to export into a .bdex file which can then be imported into your target environment.
The data elements that can be considered are Parameter entities managed in production, and Users with their associations.
Last Updated 3/9/2022 12:01:17 PM