Delivery management process
The process of new functionality development and delivering involves the following environments:
- development environment
- pre-production environment
- production environment
Learn more: Environments overview.
Steps to develop custom functionality
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, for example, Git, to store source code of functionality.
Do not use any version control system to transfer changes to the production environment. Transfer changes using version control system only to the development environment.
2. Export the functionality to a *.zip archive
You can export the functionality to a *.zip archive using the following tools:
- Application Hub. Instructions: Download an app (user documentation).
- Clio utility
- WorkspaceConsole utility. Instructions: Delivery using the WorkspaceConsole utility.
- Configuration section. Instructions: Transfer packages.
3. Import the functionality into the pre-production environment
You can import the functionality into Creatio using the following tools:
- Application Hub. Instructions: Install an app from a file (user documentation).
- Clio utility
- WorkspaceConsole utility. This is particularly convenient if your pre-production environment is on-site and you use a continuous integration pipeline. Instructions: Delivery using the WorkspaceConsole utility.
- Configuration section. This is particularly convenient if your pre-production environment is in the cloud. Instructions: Transfer the package.
We recommend using the capabilities of Creatio UI and Clio utility 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 functionality import procedure is different for the environment that uses a load balancer. Instructions: Install an app into an environment that uses a balancer (user documentation).
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. Instructions: Update guide. This is a required step since the functionality developed by third parties can affect the general operability of Creatio.
To back up cloud Creatio database, contact support. Back up on-site Creatio database on your own.
5. Import the functionality into the production environment
Import the functionality into the production environment similarly to the pre-production environment. Read more >>>
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 | Apps | 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. | Instructions: Restore the configuration from the package backups. |
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. | Instructions: official vendor documentation (GitHub). |
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.
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 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: Usage recommendations for 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. Read more >>>
See also
Delivery using the Configuration section
Delivery using the WorkspaceConsole utility
Manage apps (user documentation)
Backward compatible SQL scripts
Resources
Continuous integration (Wikipedia)