Role required: admin. |
In short, the VCS configuration pack provides version control in SimpleOne. Version control system allows:
VCS records provide a way to transfer data from one instance to another in an automatic or semi-automatic way. You can just import a configuration pack in order to avoid recreation of changes on every instance. This technology ensures easy update migration between instances.
For example, your team has created a new application on the development instance. Instead of copying scripts and recreating all elements one by one manually, they assemble a configuration pack and import it to the production instance. While importing this pack into the target instance, the system checks changes for possible collisions. This way, you can make sure that these changes work fine.
Good practice is to develop new applications and implement changes into existing ones on a separate instance. This will lessen mistakes and risks for everyday processes on the production instance. Therefore, VCS records should be collected into one local pack within the relevant application.
The configuration management involves two main processes:
To learn more about version control in SimpleOne and more, see the following articles:
Local packs allow the development of application configurations on a separate instance, exporting it as a .SOP file, and implementing changes to the production instance. This approach minimizes the risks of mistakes, errors, and conflicts, which may affect the production instance during application development.
All system configuration activities should be performed within a separate local pack. Do not use the default local pack for these needs. |
Local pack is a record in the VCS Local Pack (sys_vcs_local_pack) table compiling relevant records from the VCS Record (sys_vcs_record) table. This allows associating VCS records with a particular pack and exporting them as a complete set.
|
Every single version is an atomic state of versioned tables (those ones which have the Is VCS Enabled checkbox selected). All records in this table contain JSON formatted changes and other attributes described below.
{"value": "Report Item", "policy": "Open", "sys_id": 159653803414986194, "column_id": 156941403909472422, "record_id": 159653803414985080, "language_id": 156628684306541141, "application_id": 155931135900000002, "sys_created_at": "2020-08-04 10:47:14", "sys_created_by": 155931135900000001, "sys_updated_at": "2020-08-04 10:47:14", "sys_updated_by": 155931135900000001} |
Application configurations are stored in configuration packs represented as a .SOP file. Administrators can create their own applications if needed.
There can be more than one local pack in the system, but the changes made by a single source can be written only in one local pack selected in the Admin Preferences menu at the right. That is, if the selected local pack is Default 3, all changes will be stored in the Default 3 pack. |
All record versions in a local pack are displayed in the VCS Record related list.
In the Admin Preferences menu, select the local pack on which you are working. This local pack will be saved as preferred: if you switch between applications, this pack will be selected automatically. If the preferred local pack has a state other than In Progress, the local pack will switch to the default one. |
VCS Local Pack form fields
Field | Mandatory | Description |
---|---|---|
Name | Y | Name of the local pack. |
Is Default | N | Select this checkbox to set the local pack as default. When moving versions from other local packs, selected VCS records will be moved to this default pack. |
State | Y | Local pack state. Available options:
|
Application | N | Application to which this local pack relates and which records contains. One local pack cannot contain records belonging to different applications. |
Description | N | Local pack description. |
If there is no need in assembling a separate local pack for export, all record versions will be compiled into the default local pack. The default pack can also contain VCS records moved from developing local pack (for example, created by mistake). |
Configuration packs are also used to monitor changes in particular records.
After any transaction (create/update/delete) for the versioned table object, the record is created in the VCS Records (sys_vcs_record) table corresponding to the object state after the transaction. The record version contains the information described below.
|
Please note that removing does not mean 'deletion': removed records are stored in the default local pack. If a local pack includes unwanted VCS records, move them to the default pack by completing the following steps:
As a result:
|
VCS Record form fields
Field | Description | |
---|---|---|
Table Name | System name of the target record table. | |
Record ID | Unique ID of the source record processed by the transaction. | |
Document Record | Target table ID and target record ID for which the current record is created. For example: | |
JSON Copy | This field stores target record attributes in JSON format as an associative massive.
| |
Is Current | This checkbox is a marker for relevant version records. When selected, the version corresponds to the target record relevant for now, in other words, it is the most up-to-date version. | |
Created by | Author of the changes. | |
Created at | Date and time of record creation. | |
Local Pack | Local pack to which this record is related. | |
Retrieved Pack | Retrieved pack to which this record is related. | |
Restored by | Unique ID of the version record from which the current record was restored. | |
Action | Transaction type. Available options:
| |
Record Policy | Current record protection policy after the transaction is over. Possible options:
| |
Is Strong Overwrite | When selected, the current record will be written over the existing version with the Protected policy. |
All the record versions – both previous and current – are stored in the VCS Record table. Current versions have the Is Current checkbox selected.
If you need to restore one of the record previous versions, complete the steps below:
Another way to restore a record version is the following:
|
After that, a new VCS record is associated with the current local pack. It will be displayed in the VCS Records related list.
Some forms may not display the VCS Records related list by default. You can add it to the versioned table form as a related list. After that, all versions (previous and current) of the current record are displayed on the record form. To add the VCS Record related list, perform the following steps:
|
The Protection Policy attribute is responsible for data protection purposes. After creating a record in the versioned table, the Protection Policy for this record is Open. Once the record is updated, the Protection Policy becomes Changed. These values are transferred to the Record Policy field in the related VCS record, that is, the record version has the same Policy as the record itself.
Admin can update only the Local Pack and Is Strong Overwrite fields of records with any protection policy.
During the importing process, the records possible to overwrite can be updated. Both record policy values set in the system and in the configuration pack are taken into account. All possible policy combinations are described in the table below.
Source record Protection Policy | Target record Protection Policy | Result |
---|---|---|
Protected | Protected | Success |
Open | Success | |
Changed | Success | |
Changed | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Success | |
Open | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Failed. Use Strong Overwrite to proceed. |
/
Role required: admin. |
In brief, the VCS configuration pack provides version control in SimpleOne. Version control system allows:
VCS records provide a way to transfer data from one instance to another in an automatic or semi-automatic way. For not to recreate changes on every instance, you can just import a configuration pack. So, this technology ensures easy update migration between instances.
For example, your team has created a new application on the development instance. Instead of copying scripts and recreating all elements one by one manually, they assemble a configuration pack and import it to the production instance. While importing this pack into the target instance, the system checks changes for possible collisions. This way, you can make sure that these changes work fine.
A good practice is to develop new applications and implement changes into existing ones on a separate instance. This will lessen mistakes and risks for everyday processes on the production instance. Thus, VCS records should be collected into one local pack within the relevant application.
The configuration management involves two main processes:
To learn more about version control in SimpleOne more, see the following articles:
Local packs allow developing application configurations on a separate instance, exporting it as a .SOP file, and implementing changes to the production instance. This approach minimizes risks of mistakes, errors, and conflicts, which may affect the production instance during application development.
All system configuration activities should be performed within a separate local pack. Do not use the default local pack for these needs. |
Local pack is a record in the VCS Local Pack (sys_vcs_local_pack) table compiling relevant records from the VCS Record (sys_vcs_record) table. This allows associating VCS records with a particular pack and exporting them as a complete set. Every single version is an atomic state of versioned tables (those ones which have the Is VCS Enabled checkbox selected). Every record of this table contains JSON formatted changes and other attributes described below.
{"value": "Report Item", "policy": "Open", "sys_id": 159653803414986194, "column_id": 156941403909472422, "record_id": 159653803414985080, "language_id": 156628684306541141, "application_id": 155931135900000002, "sys_created_at": "2020-08-04 10:47:14", "sys_created_by": 155931135900000001, "sys_updated_at": "2020-08-04 10:47:14", "sys_updated_by": 155931135900000001} |
Application configurations are stored in configuration packs represented as a .SOP file. Administrators can create their own applications if needed.
There can be more than one local pack in the system, but the changes made by a single source can be written only in one local pack selected in the Admin Preferences menu at the right. That is, if the selected local pack is Default 3, then all changes will be stored in the Default 3 pack. |
All record versions in a local pack are displayed in the VCS Record related list.
In the Admin Preferences menu, select the local pack on which you are working. This local pack will be saved as preferable: if you switch between applications, this pack will be selected automatically. If the preferable local pack has a state other than In Progress, the local pack will switch to the default one. |
|
When there is no need in assembling a separate local pack for export, all record versions will be compiled into the default local pack. The default pack can also contain VCS records moved from developing local pack (for example, created by mistake). |
Configuration packs are also used for monitoring changes in particular records.
After any transaction (create/update/delete) for the versioned table object, the record is created in the VCS Record (sys_vcs_record) table corresponding to the object state after the transaction. The record version contains information described below.
VCS record cannot be created, updated, or deleted manually. These records are created automatically by the system.
Please note that removing does not mean 'deletion': removed records are stored in the default local pack. If a local pack includes unwanted VCS records, move them into the default pack by completing the following steps:
As a result:
|
|
All record versions – both previous and current – are stored in the VCS Record table. Current versions have the Is Current checkbox selected.
If you need to restore one of previous record versions, complete the steps below:
Another way to restore a record version is the following:
|
After that, a new VCS record associates with in the current local pack. It will be displayed in the VCS Records related list.
Some forms may not display the VCS Records related list by default. You can add it to a versioned table form as a related list. After that, all versions (previous and current) of the current record are displayed on the record form. To add the VCS Record related list, perform the following steps:
|
The Protection Policy attribute is responsible for the possibility of the record changing (for example, overwriting). It is used, in particular, for data protection purposes. That is, the most important elements of the system with the Protected policy cannot be changed.
How it works
After creating a record in the versioned table, the Protection Policy of this record is Open. When the record is updated, the Protection Policy becomes Changed. This values are transferred to the Record Policy field in the related VCS record, that is, the record version has the same Policy as the record itself.
Administrator can update record with the Open and Changed policies.
Administrators cannot update records with the Protected policy. The exception is records related to the ITSM application: administrators can update ITSM record with any protection policy.
During the importing process, the records possible to overwrite can be updated. Both record policy values set in the system and in configuration pack are taken into account. All possible policy combinations are described in the table below.
Source record Protection Policy | Target record Protection Policy | Result |
---|---|---|
Protected | Protected | Success |
Open | Success | |
Changed | Success | |
Changed | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Success | |
Open | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Failed. Use Strong Overwrite to proceed. |
/