Version: 8.0

Delivery management process

Level: beginner

The process of new functionality development and delivering involves the following environments:

development environment
pre-production environment
production environment

Learn more about environments in a separate article: Environments.

Custom functionality development steps

To avoid irregularities in Creatio and critical errors in the production environment, follow a particular action sequence when transferring the functionality between environments. View the sequence in the figure below.

1. Develop new functionality

We recommend developing new functionality in the development environment that has a personal database for each developer. We recommend using a version control system (Subversion, Git, etc.) to transfer changes between environments.

Important

Do not use SVN to transfer changes to the production environment. Transfer changes using SVN only to the development environment.

2. Export the package to a *.zip archive

You can export the package to a *.zip archive in the following ways:

Using the Configuration section. To do this, follow the guide in a separate article: Transfer packages.
Using the WorkspaceConsole utility. To do this, follow the guide in a separate article: Delivery in WorkspaceConsole.

3. Import the package into the pre-production environment

You can import the package into Creatio in the following ways:

Using the Creatio UI. This is particularly convenient if your pre-production environment is in the cloud. To do this, follow the guide in a separate article: Delivery in Creatio IDE.
Using the WorkspaceConsole utility. This is particularly convenient if your pre-production environment is on-site and you use a continuous integration pipeline. To do this, follow the guide in a separate article: Delivery in WorkspaceConsole.

Important

We recommend using the capabilities of Creatio UI to transfer changes to Creatio in the cloud. Using WorkspaceConsole is not possible because the user does not have direct access to the cloud Creatio database.

The package import procedure is different for the environment that uses a load balancer. To import the package into the environment that uses a load balancer, follow the instructions in the user documentation: Manage apps.

If you find errors during the testing step, improve the functionality by eliminating them. Repeat steps 1-3 after that.

4. Back up the production environment database

Before you start the delivery process to a production Creatio environment for packages that contain the developed functionality, back up the database. To do this, follow the instructions in a separate article: Update guide. This is a required step since the functionality developed by third parties can affect the general operability of Creatio.

Important

To back up cloud Creatio database, contact support. Back up on-site Creatio database on your own.

5. Import the package into the production environment

Import the package into the production environment similarly to the pre-production environment (step 3).

Roll back to the previous configuration state from package backups

Creatio lets you roll back to the previous configuration state from package backups in case of package installation failures or errors after installation. The previous state refers to the configuration state before the packages were last installed in the production environment. Restoring from a package backup is faster and more convenient for configuration restoration than restoring from a database backup.

Packages are backed up when they are installed.

The following tools let you use Creatio to back up packages and roll back to the previous state of the configuration:

App installation error page in the Application Hub (referred to as the error page below).
WorkspaceConsole utility.
Clio utility.

Creatio rolls back the following app elements to a previous state from a package backup:

Schemas of configuration elements.
Data that is added or changed when the package is installed into the environment.

Rollback to a previous configuration state from a database backup will result in the loss of any data that was added since the package was installed in the environment. Rollback to a previous configuration state from a package backup only affects the configuration and does not affect any business data stored in the objects.

The methods to roll back to a previous configuration state from a package backup are available in the table below.

Methods to roll back to a previous configuration state from a package backup

Method	Applications	Launch method
Error page	The package was installed via the Application Hub. The installation ended with an error.	Click the Restore from backup button that will be displayed after the installation failure.
WorkspaceConsole utility	The package was installed via the WorkspaceConsole utility. The installation ended with an error.	Follow the guide in a separate article: Delivery in WorkspaceConsole.
WorkspaceConsole utility	The package was installed via the Application Hub. The installation was successful. The app does not work as expected upon completion of the installation.
Clio utility	The package was installed via the Clio utility. The installation ended with an error.	Follow the instructions provided in the utility documentation on GitHub.
Clio utility	The package was installed via the Application Hub. The installation was successful. The app does not work as expected upon completion of the installation.

You can roll back to a previous configuration state from a package backup using any of the methods, regardless of the tool that was used to install the package. For example, if the package was installed via the Application Hub, you can roll back to a previous configuration both via the error page and the WorkspaceConsole or Clio utility.

Important

We recommend that you roll back to the previous configuration state upon a package installation error or before users start working in the production environment. Rolling back to to a previous configuration state after users start working in the production environment might render a graceful shutdown impossible.

To successfully roll back to a previous configuration state, packages that contain SQL script type configuration elements must comply with the recommendations described in the following article: Backward compatible SQL scripts.

Upon an installation failure of a package that includes at least a single configuration element of the SQL script type without the Backward compatible checkbox set, Creatio suspends rollback to the previous configuration state from the package backup via the WorkspaceConsole utility.

If rollback to a previous configuration state from a package backup fails, you can restore from a database backup as described in step 4.