Group development technologies in modern 1C industry

Oddly enough, it was then that the first group development technology was born. Later it received the name Local version control system. According to its concept, individual configuration files – versions – were laid out in a certain shared folder or directory structure, named in a certain way and periodically backed up. All this was inconvenient, difficult to control, and code versioning was very conditional.

With the release of platform 8.0, a configuration storage appeared in it, which became a typical representative Centralized version control systems. Now developing configurations as a team has become much easier. Each developer could see which object was captured by whom, and all the improvements of all participants were collected into a single history in the repository. Group development technologies began to gain momentum: in version 8.2, at the request of the community, they added the function of uploading configurations to files, making it possible to use Distributed hard currency, such as Git. And in EDT this technology is already available out of the box.

The advantages of group development technologies are difficult to overestimate:

• the ability to carry out development by several programmers, without fear of overwriting each other’s improvements;

• storing a history of all changes, with the ability to roll back from an unsuccessful version to a previous, more stable one;

• code quality control both from the manager (team lead) and the connection of static code analyzers;

• simplifying the process of reusing useful code fragments in other projects;

• exchange of experience between developers;

• ease of investigation of the sources of errors in the information base in the context of the evolution of code and metadata objects.

Today, the use of teamwork technologies is an integral part of any project. Even if a programmer is working on a configuration alone, it is useful to keep and monitor a history of all changes made.

When working in a group, version control systems ensure the joint creation, testing and support of software systems, which ultimately results in the production of high-quality products with the efficient use of resources.

When choosing a specific technology, it is important to understand the goals and objectives that need to be solved. Group development goals may include:

• improving product quality;

• acceleration of the development process;

• flexibility and scalability;

• exchange of knowledge and experience.

Possible group development tasks:

• organizing effective interaction;

• configuration and version management;

• quality assurance;

• planning and monitoring.

In this article I will consider the possibilities, pros and cons of three main technological approaches:

1. Configuration storage.

2. Configurator + Git.

3. EDT + Git.

We will also look at the tasks: when and which technology is best to use, and where each of them will be powerless.

Configuration storage

SCR type

Configuration repository is a typical example Centralized version control systems. The architecture of such systems consists of a single storage space for a centralized, consolidated configuration, into which improvements from all team members are merged as they are ready.

An object or module in a repository can only be owned by one developer at a time. In this case, access to the object of all other participants is blocked until the programmer who captured it finishes working with it and places all his changes in the central repository. The disadvantage of this approach is the impossibility of simultaneous access to one object by two or more team members. But this is also a plus, since in this case controversial conflict situations when one line of code is changed simultaneously by several participants are impossible.

Description

Centralized storage of all versions of configuration objects in a single database. The database is located on a dedicated, publicly accessible resource and exists there in a single copy. This is a minus for the security of storage data, since it is necessary to take care of backing up general data in case of force majeure situations.

Access to the storage is configured individually for each user and can be protected with a separate password. There are three levels of access: to view storage history, developer functions, and administrator rights. The administrator has the ability to forcefully reset the capture of any object, while the developer whose object has lost its binding to the storage must independently take care of the safety of the changes made in his local configurator.

Advantages

Ease of use. Once having access to the repository and having learned a couple of commands and a couple of buttons, the developer can easily join the configuration development process. It is also easy to manage access and control the capture of objects by the administrator.

Centralized management. An architect with administrative rights can keep the most critical metadata objects permanently captured, the modification of which is undesirable. These can be complex objects, such as roles or regulated reports from the vendor.

Flaws

No branching. With the classical scheme of working with storage, we are dealing with strictly linear changes over time. This can create particular difficulties on large and complex projects with a large number of programmers. For example, when you need to change the priority of two tasks, each of which involves the same objects, and you don’t want to lose the improvements already completed.

Difficulty updating a vendor's release. You have to use the same approaches as in normal local work in the configurator. To transfer changes to the repository, it is necessary to recursively capture the entire configuration, which is not recommended by 1C standards.

Limitations of partial fixation. Inability to store only part of the changes to an object or module in the repository. For example, assign two parts of one revision to different tasks.

Application

• Suitable for small and medium-sized teams with a linear development process.

• Preferred for configurations on regular forms.

Tips for use

1. Make sure that all developers in the team work on the same version of the platform, up to the latest build number. And the same version of the platform must be used to ensure the operation and maintenance of the storage base.

2. Set the short configuration root capture rule in the command. In fact, this is required only in one case – to add a new object. Let the developer grab the root, add an object, immediately release the root and continue to refine the object, leaving only it captured. At the same time, watch out for additional platform requirements for updating the database with a new object. For example, for an accumulation register, at least one registrar must be specified.

3. Provide an additional, backup, storage account with administrative rights. It may be required for emergency removal of an object from a developer who is on vacation, or for urgent access in the absence of a single administrator.

Configurator + Git

SCR type

Using Git opens the door to many benefits distributed version control systems. The key difference between such systems is the storage of a complete copy of the entire change history in a repository both on the central server and locally for each developer. Changes are made by the programmer in the local repository with subsequent synchronization with the central one. Other team members also synchronize their repositories with the central one. This creates a unified development ecosystem in which each participant works asynchronously and independently in time.

However, this procedure also gives certain disadvantages and imposes additional responsibility on the group members. There is no object locking here: the same object and even one line of code can be modified simultaneously by several participants. But in the process of fixing such changes (their merging), it is necessary to resolve conflicts that inevitably arise during such changes.

Description

To take advantage of versioning, Git uses a tool for uploading configuration to XML files, available from the configurator. By the way, this operation is also available for extensions and external reports and processing.

Because Git is a third-party file versioning service, it gives you freedom and flexibility when planning your project's file storage structure. In such a storage or repository, you can store not only configuration files and its extensions, but also absolutely any data related to the project: test script files, documentation, exchange rules, etc.

Access control to the repository is available at the central server level. For example, GitHub allows you to configure rights both for the repository itself as a whole and for individual history branches within it. However, the developer's local copy of the repository is available to him without restrictions. And this imposes additional responsibility on the team member. So, if a programmer accidentally made a series of commits to a branch master local repository, then it may not be possible to push these changes to the server if commits to this branch are prohibited in the remote repository. Such changes will need to be moved to the appropriate task branch.

Advantages

Possibility of branching. One object is available for changes to the entire team at once, which allows you not to stop the process of working on the project if two or more tasks require access to one common module or reference book. In addition, the history of improvements for each task can exist independently, and changes for different tasks can be merged into the main branch asynchronously, depending on current priorities and when ready.

Convenient work with changes and version history. Another advantage of Git is its high speed. You can switch to any configuration version in a matter of seconds. The tools for viewing the history of changes and analyzing them are quite broad and flexible.

Partial commit of changes. If you have made changes in one module for several tasks at once in a thread, then these changes can be separately recorded in those branches in which they are needed, down to a separate line of code.

Flaws

The need to master Git as a separate tool.

Initial system setup. Initial system setup is necessary for Git to work correctly with 1C files. These are also typical Git settings for authorization, SSH keys, initial deployment of repositories, and branching settings.

Application

Suitable for teams of any size who prefer flexibility and enhanced control. Recommended for complex projects in which not only the configuration itself is actively being developed, but also additional external files and components accompanying the project.

Tips for use

1. As when working with storage, all team members should use the same version of the 1C platform, since the content and format of uploaded files may differ from version to version.

2. Agree with the team in advance:

   • What will be the structure of your repository, in which folders which files will be stored. And perhaps it would be reasonable to version individual extensions and external processing that are applicable to many projects in a separate repository;

   • Naming branches. Just as when writing code it is important to adhere to common standards, when using Git it is necessary to follow uniform rules in branch names, for example, so that an issue number must be present. Some task trackers allow you to automate these processes;

   • Branching system. The name of the main development branch, the presence and procedure for working with the testing branch, the procedure for creating and merging branches of individual tasks and bugfixes – it is better to agree on all this on the shore; it will be much more difficult to fix it later.

3. Recommended command line consoles: Cmder And Conemu.

4. For ease and clarity when working with Git, it is better to use a graphical IDE. You can choose any one at your discretion. Here I will list the most popular ones: Git Extensions, SourceTree, GitHub Desktop, GitKraken, VSCode.

EDT + Git

The approach using 1C:EDT (1C:Enterprise Development Tools) is in many ways reminiscent of the work on the previous stack, and the same recommendations apply to it. With the exception that EDT initially includes both an arsenal of tools for developing 1C configurations, as well as a Git system built out of the box and a graphical interface for working with it. There are some differences, let's talk about them.

SCR type

Distributedbecause it's also Git.

Description

Using the Eclipse Development Environment (EDT) with Git integration. The EDT platform allows you to conveniently configure the development environment for any project. For this purpose, the interface provides separate Prospects for working with configurations and the Git control system.

Advantages

Convenient Git integration. There is no longer any need to switch between different applications to solve different development tasks. Everything is in one place, which is very convenient.

Advanced Features of the Eclipse IDE. The IDE toolkit provides convenient wizards and designers for various sections and configuration blocks, extended contextual help, convenient search and navigation tools, and all the necessary tools can be placed in separate windows and tabs, customizing the interface completely for yourself.

Workspaces. The EDT concept includes the concept of a “Workspace”, within which multiple configurations can be developed simultaneously in one place. You can also distribute configurations across Git repositories in a variety of combinations, and you can connect several infobases to one configuration project. This can be convenient if the databases differ in data content, role in the project, or are configured for the specifics of accounting for different clients.

Flaws

High entry threshold, requires a change in the usual workflow. EDT is another tool in the developer’s arsenal that also needs to be mastered along with the configurator. Working in the EDT environment seems inconvenient at first, since all the tools here are used, look and work a little differently than in the configurator.

Performance. Yes, gone are the days when contextual help appeared a minute after typing a period. But still, the speed and performance of the environment is still far from ideal. And for more or less comfortable work, it is necessary to significantly increase the hardware performance of the workstation.

Application

Suitable for teams using advanced development and integration capabilities.

Tips for use

1. Install the latest version of EDT. From version to version, the functionality of individual tools and subsystems is significantly improved. Each release also provides new performance improvements. Not by much, but still.

2. Take care of productive hardware. Particular attention should be paid to the speed of the hard drive (an SSD with the maximum available speed is required), as well as the volume and speed of RAM (from 16 GB DDR5).

3. Customize your environment. You can change quite a lot in the interface and the list of options, including redefining hot keys, if you want to maintain the approach that you are used to in the configurator. A user-friendly interface will significantly increase the efficiency of your work.

Comparison of capabilities of group technologies

In the table below I provide a comparative description of the key indicators of the process of developing 1C configurations in the team. This will help you choose the most suitable tool for your needs.

Each approach to organizing group work has its pros and cons. Key selection criteria are the complexity and scope of the project and preferred methods of communication and code sharing.

Which technology do you use in your team (or in single combat)?