Configuration branched development technology

See more

Scope: managed applications, mobile applications, and ordinary applications.

Best practices

Technology purposes:

  • To improve quality of configurations under development
  • To improve development and testing
  • To ensure continuous configuration development under tight deadlines

1. Definitions

Planned configuration version is a version that contains major functionality developments, whose release date is set in advance.

Corrective version is a version released when critical error correction is urgent. In exceptional cases, corrective versions can contain some new functionality (for example, upgrades due to legislation changes). The term of release is defined when analyzing the amount and severity of errors found in a planned version.

Technical project is a job for configuration upgrade. Every technical project has a clear goal and final list of changes to be made in order to achieve this goal.

To manage development and maintenance of configurations (including maintenance of information on technical projects and an error list), we recommend that you use Application design system (ADS).

2. Developing corrective versions

2.1. To release each corrective version, create a new storage based on a configuration of the latest released version.

Important: do not copy main storage; create a new one.

2.2. Corrected versions must not contain significant configuration upgrades. Otherwise, it would be necessary to review the terms of planned version release.

2.3. All bookmarks in the corrective version storage must include comments.

The requirements for comments are the same as the requirements for bookmarks in the planned version storage (see cl. 3.4).

2.4. All changes made to a corrective release must be made to main storage as well. If a corrective release has new objects (object attributes) added, migrate the changes only by comparing or merging configurations to avoid differences in internal IDs of configuration objects.

2.5. When building corrective versions, set a label with information on the build number in the bookmark of the storage version, whose configuration is to be built. Usually, it is the last bookmark upon build.

3. Developing planned versions

3.1. Develop planned versions in the main configuration repository.

3.2. Embedding in the main storage must be performed in a way that each embedding switches a storage configuration from one working condition (ready for release) to another.
Cannot embed functionality that is not fully debugged. The main storage must always be in working condition in order to start building a planned version at any time.

3.3. In the main storage, you can do the following:

  • Correct errors that do not require re-designing, significant coding, and testing. If an error requires significant revisions and/or review of project solutions, correct this error under the technical project. Work with the main storage the same way as with other technical projects.
  • Embed new library versions.
  • Embed completely debugged and tested projects.
  • In exceptional cases, the main storage allows development of multiple projects (for example, bulk refactoring projects).

We recommend that you use ADS features to automatically generate comment texts for bookmarks related to error correction and technical project embedding.

3.4. All main storage bookmarks must include comments.

The comment contents depend on the type of the work performed:

  • When correcting an error, specify its number and brief description in the bug tracking system.
  • When embedding a new library version, specify the library name and the exact library version number.
  • When embedding technical projects, specify the project number in the project documentation management system and its brief description.
  • When working on the technical project in the main storage, a comment must contain a summary of the changes made to this bookmark in addition to the project number and its brief description.

3.5. All changes in the technical project must be transferred to the main storage at once. If you need to transfer changes several times, open multiple projects.

3.6. Once the changes are moved to the main storage, you can start correcting errors made by the technical project. To review project solutions, open a new project.

3.7. When building planned versions, set a label with information on the build number in the bookmark of the storage version, whose configuration is to be built. Usually, it is the last bookmark upon build.

4. Developing technical projects

4.1. Develop each technical project in a separate storage.

If ADS is used, a technical project storage can be created automatically. If ADS is not used, create a technical project storage manually in accordance with the procedure described in Annex 1.

4.2. When making the technical project storage supported from the main storage, the platform sets the "Vendor object not editable" rule for all objects. To work on the technical project, change this rule to "Vendor object editable, support enabled".

Set the "Vendor object editable, support enabled" rule only for objects that are changed upon technical project implementation. Change rules as accurately as possible. For example, if project changes affect a form only, change a rule only for this form and leave the "Vendor object not editable" rule for an object to which this form belongs.

To change support rules, lock a configuration root only. Do not lock objects.

Achieving these recommendations will simplify the process of transferring changes between the main storage and the technical project storage.

4.3. The person responsible for the technical project can periodically update the project storage configuration. The update frequency is defined by developers.

The following factors can influence the update frequency:

  • The technical project covers objects of other responsible persons.
  • Core mechanisms are being refactored.
  • Bulk error correction is in progress in the main storage.

For the order of technical storage update, see Annex 2.

4.4. Upon development completion, the person responsible agree on the debugging testing deadline and the date the technical project is added to the main storage. We recommend that you add projects that cover a lot of objects to the main storage closer to the date of development completion to minimize the impact on other projects.

Persons responsible for other technical projects can ask to review the timing for adding projects to the main storage.

In ADS, you can agree on the terms of embedding technical projects using technical project checkpoints.

4.5. Add projects to the main storage upon debugging testing completion. We recommend that you generate a file comparing the project configuration and the main storage configuration upon completing the correction of errors detected during debugging technical project testing.

4.6. Moving technical projects upgrades to the main storage must not lock main storage objects for a long time. This is achieved by the fact that the technical project storage is updated to a main storage state first (based on the method described in Annex 2). If there are a lot of changes, such update might take a long time (up to several days). During this period, the main storage configuration might change. That is why the update process can be iterative. Upon each update iteration, differences in configurations will get closer to the value of changes made by the technical project.

After each update iteration, we recommend that you quickly check the performance of the functionality being developed under the project.

Start transferring changes to the main storage (locking objects in the main storage) only when the technical project configuration differs from the main storage configuration only in the changes made by the project.

4.7. The person responsible for the technical project must be attentive to changes made to the main storage. Keep in mind that the main storage must be ready for planned version release at any time.

Once changes are made to the main storage, technical project developers and testers check whether the changes were transferred correctly and did not affect the related functionality performance. The amount of checks and their order are defined by the person responsible for the project.

4.8. After checking whether the changes are moved and before making the changes to the main storage, the person responsible must start configuration verification. Carry out the verification with maximum settings.
Changes can be added to the main storage only once all errors that were made by the project and detected during the configuration check are corrected.

4.9. Once changes are moved to the main storage, the person responsible for the technical project deletes the project storage.

5. Numbering builds

Version number changes are regulated by the Numbering versions and revisions standard.
It will clarify the rules for build number changes (the fourth number in the version number).

5.1. Increase the build number both in the main storage and in the corrective release storage in two cases:

  • Right before a release build. It is necessary so that the full release number differ from the full number of the previous release.
  • When adding an infobase update handler to the storage. It is necessary so that all development participants have the added update handler started automatically after update from the storage (only for configurations based on Standard Subsystems Library).

5.2.1. When adding infobase update handlers to the storage, increase the build number within the same bookmark. There are two possible scenarios:

  • An update handler is added to the technical project storage upon technical project development. In this case, increase the main storage build number when moving changes to the main storage. 
  • An update handler is added to correct errors. If errors are corrected in a single storage only (a main or corrective one), the build number is increased in this storage only. If errors are corrected in two storages, increase the build number in both storages. 

5.2.2. Place the handler and the changed build number in the storage within a single bookmark. The update handler must be bound to the build number it is placed in the storage with.

5.2.3. If update handlers are distributed by technological subsystems within a single configuration (for example, the 1С:ERP configuration handlers are distributed by the EnterpriseManagement and TradeManagement subsystems), increase the build number in both the subsystem to which the handler belongs and the configuration.

5.3. Change the build number:

  1. In configuration properties.
  2. In the InfobaseUpdate<LibraryName>.OnAddSubsystem procedure (only for configurations based on Standard Subsystems Library).

Annex 1. Creating technical project storages

  1. Update an infobase configuration, which is bound to the main storage, from the storage.
  2. Create a delivery file of the main storage configuration (*.cf).
  3. Load a configuration from the delivery file to the infobase to be used to work on the technical project. Once the configuration is loaded from the delivery file, the configuration will be supported, but changes will not be allowed.
  4. Create a configuration storage in the shared folder (when creating a storage, the platform will enable configuration changes).
  5. Add the ReadOnly user (without a password and without the right to lock objects). Do not use this user to bind the infobase to the storage. Use them only for update from the storage (to get a storage configuration).
  6. Add users mentioned in the project to the storage (a username is an employee's last name, without a password, with the right to lock objects). Do not use the ReadOnly username for project participants.

Appendix 2. Updating technical project storages to main storage state

Before moving changes from the technical project storage (hereinafter referred to as "TPS") to the main storage (hereinafter referred to as "MS"), TPS is updated to a MS state.

To update TPS to a MS state, do the following:

  1. Update an infobase bound to MS.
  2. Create a delivery file of a MS сonfiguration.
  3. Lock all objects in TPS.
  4. Start comparing the main configuration and the vendor configuration (Configuration–Compare configurations). Save the comparison results to a file. They are changes made to the configuration when working on the technical project. In the "Actions" menu, select "Configuration comparison report". We recommend that you display and save a comparison report both in text format and spreadsheet document format for future use.

  5. Update configuration (Configuration – Support – Update configuration – Select update file – specify a configuration delivery file created in step 2).

    Click "Filter" and select the "Show only properties that were changed twice" check box.



    Pay attention to these objects while merging. Other changes can be merged without verification.

  6. In the dialog box that appears when you click "Execute" in the configuration comparison and merge window, set the "Object not available for editing" rule for new vendor objects, objects with the "Changes allowed" rule, and objects with the "Changes not recommended" rule. For other objects, select the "Keep current rule" check box (it is selected by default).

  7. Once merging is completed, correct objects that are covered by the technical project and whose changes were removed during update. This means that it is necessary to make upgrades implemented under the technical project to configuration objects again.
  8. Start comparing the updated main configuration of the technical project and the updated vendor configuration (Configuration – Compare configurations).

  9. Save the comparison results to a file. The file name must differ from the file name generated in step 6. In the "Actions" menu, select "Configuration comparison report". We recommend that you save and display a comparison report in text format for future use.
  10. Compare files created in steps 4 and 9. If the update is correct, the compared files do not differ.