Versioning in Ultima Businessware
In this article we will tell you about the mechanisms for organizing group work in our platform .
Problems common to all groups of developers, for difficult to explain reasons, are in the third place of importance in ERP systems, where, it would seem, code quality and reliability should be put at the forefront.
Which, however, allows us (from our point of view) to claim the laurels of the pioneers in this field.
In the first version of the platform versioning support was absent.
If you have not read the previous articles of this blog, then you should read the brief
Accordingly, any changes in the structure of objects or the code of scripts immediately became accessible to everyone, including users of the system.
A wonderful mechanism for instant delivery of errors to users.
Having suffered a little, and having made sure that it is impossible to write at all without mistakes, we decided to restrict ourselves to crutches.
')
In fairness, it must be said that it was a time when easily attached crutches were preferred to a complex mechanism, due to the incredibly tight deadlines.
So, the solution was to make 2 versions for scripts - for developers and for users. Quite quickly, a third version was added - for testing.
However, this did not solve the problem in principle.
Although the errors ceased to fall instantly to users, conflicts, while simultaneously being modified by several developers, did not disappear.
Being engaged in the development of a new version, we fundamentally decided to abandon the crutches and implement a fully functional mechanism.
We introduced the concept of configuration as the entire commonality of business objects, scripts and other things and introduced a distributed version control system of configurations into the platform. Accordingly, each developer makes changes in his branch, without affecting other developers or users. Accordingly, all its changes occur in a controlled and stable environment, which significantly reduces the likelihood of "unexpected" errors. Thus, all versions form a configuration version tree, each of which contains a complete (well, at least according to the developer) set of changes. The system implements all the mechanisms for tightening changes from the default (using the terminology of Mercurial) branch, pushing changes to the default branch. Not to be unsubstantiated, I will provide a screenshot of the application:
Each developer (or deployment manager, as if Kurguzo doesn’t sound in Russian), can see what, by whom and when it was done. On the next tab, you can see what changes have been made:
The last tab for conflict resolution should be familiar to those who use version control systems such as Mercurial. We also attached all the mechanisms for comparing objects of different versions:
I will not litter the text with screenshots anymore, all the necessary mechanisms are there.
We also tied all the changes to the CRM (Change Request Management) system, and now you can see what was done and why, or, conversely, move from change to the corresponding change request (any system with a web interface will do).
In general, the integration of a version control system into the platform allows you to perform many useful tricks. For example - control the availability of transfers of resources. The configuration comes with support for Russian and English, and, accordingly, it is required for all resources to have translations into Russian and English, respectively. We did such a check - when pushing a change branch to default, if not all resources are transferred, the developer will receive a message. This was not enough, so we screwed up the Roslyn project to analyze the scripts. If there are lines in the script that are not replaced by translatable resources, the developer will also receive a message.
What else - integrated unit-tests integrated, version control system and Team City.
The implementation of an integrated version control system has significantly simplified and automate internal development processes.
Nowadays, when there were no built-in UNIT-testing mechanisms, separate versions for developers, commenting and tagging of changes, linking changes to change requests were remembered as a nightmare of Chaos.
Problems common to all groups of developers, for difficult to explain reasons, are in the third place of importance in ERP systems, where, it would seem, code quality and reliability should be put at the forefront.
Which, however, allows us (from our point of view) to claim the laurels of the pioneers in this field.
Anamnesis
In the first version of the platform versioning support was absent.
If you have not read the previous articles of this blog, then you should read the brief
introductory
In principle, everything is written in the extract from the documentation for developers posted on the site .
But it can be even shorter.
The subject area is described using reference books, link tables, documents (to reflect processes or events in the subject area), totals (some analogue of an account for accountants, registers in 1C or cubes in OLAP) and scripts-handlers for various events that create, modify or delete the above business objects.
But it can be even shorter.
The subject area is described using reference books, link tables, documents (to reflect processes or events in the subject area), totals (some analogue of an account for accountants, registers in 1C or cubes in OLAP) and scripts-handlers for various events that create, modify or delete the above business objects.
Accordingly, any changes in the structure of objects or the code of scripts immediately became accessible to everyone, including users of the system.
A wonderful mechanism for instant delivery of errors to users.
Having suffered a little, and having made sure that it is impossible to write at all without mistakes, we decided to restrict ourselves to crutches.
')
In fairness, it must be said that it was a time when easily attached crutches were preferred to a complex mechanism, due to the incredibly tight deadlines.
So, the solution was to make 2 versions for scripts - for developers and for users. Quite quickly, a third version was added - for testing.
However, this did not solve the problem in principle.
Although the errors ceased to fall instantly to users, conflicts, while simultaneously being modified by several developers, did not disappear.
Being engaged in the development of a new version, we fundamentally decided to abandon the crutches and implement a fully functional mechanism.
We introduced the concept of configuration as the entire commonality of business objects, scripts and other things and introduced a distributed version control system of configurations into the platform. Accordingly, each developer makes changes in his branch, without affecting other developers or users. Accordingly, all its changes occur in a controlled and stable environment, which significantly reduces the likelihood of "unexpected" errors. Thus, all versions form a configuration version tree, each of which contains a complete (well, at least according to the developer) set of changes. The system implements all the mechanisms for tightening changes from the default (using the terminology of Mercurial) branch, pushing changes to the default branch. Not to be unsubstantiated, I will provide a screenshot of the application:
Each developer (or deployment manager, as if Kurguzo doesn’t sound in Russian), can see what, by whom and when it was done. On the next tab, you can see what changes have been made:
The last tab for conflict resolution should be familiar to those who use version control systems such as Mercurial. We also attached all the mechanisms for comparing objects of different versions:
I will not litter the text with screenshots anymore, all the necessary mechanisms are there.
We also tied all the changes to the CRM (Change Request Management) system, and now you can see what was done and why, or, conversely, move from change to the corresponding change request (any system with a web interface will do).
In general, the integration of a version control system into the platform allows you to perform many useful tricks. For example - control the availability of transfers of resources. The configuration comes with support for Russian and English, and, accordingly, it is required for all resources to have translations into Russian and English, respectively. We did such a check - when pushing a change branch to default, if not all resources are transferred, the developer will receive a message. This was not enough, so we screwed up the Roslyn project to analyze the scripts. If there are lines in the script that are not replaced by translatable resources, the developer will also receive a message.
What else - integrated unit-tests integrated, version control system and Team City.
The implementation of an integrated version control system has significantly simplified and automate internal development processes.
Total, which gives the integration of the version control system into the platform:
- The number of errors has been drastically reduced due to the simultaneous change of scripts or metadata structure.
- Increased transparency and predictability of the development and testing process (we know what functionality is implemented, who ordered the functionality, etc.)
- The number of urgent appeals has decreased.
Nowadays, when there were no built-in UNIT-testing mechanisms, separate versions for developers, commenting and tagging of changes, linking changes to change requests were remembered as a nightmare of Chaos.
Source: https://habr.com/ru/post/249069/
All Articles