We create our own CD container with blackjack and 1C or How we update microservices

Pain

Everyone who develops and supports microservices in 1C (extensions, additional processing reports) sooner or later faces the need for a mechanism for automatic delivery and updating of these same microservices. In the official 1sfresh cloud, this is implemented in the form of an extension store, where users can install an add-on to their application at any time, update it (updates are even automatic) and this is quite convenient. And for local versions there are no such extension stores yet (more precisely, it appears 1C Plus and 1СStore from Infostart, but it’s difficult to get there, not everyone is accepted, and not everyone needs it).

“The one who walks will master the road.” Seneca. Brezhnev. Loskutov.

Statement of the problem

So we have an extension, for example Easy Document Flow. For each configuration there is a separate extension file. And for each edition there will most likely be different extensions, for example for UNF 1.6 and for UNF 3.0. And even one edition of UNF 3.0 may have different extensions for different versions. We need the user to be able to update the extension in his local database without thinking about versions, and preferably with one button, roll back to the previous version if necessary. And it’s really fat: the user agrees to auto-update and it updates itself according to a schedule. And I would also like to limit the update period for one user, since we sell a subscription to updates with a limited period. And, of course, since the extension is paid, we should not make it publicly available.

Add. processing-installer

In order for the user to be able to work with microservices directly in the 1C interface, some kind of installer will be needed – additional. processing or extension that can:

1. Find out the current configuration version

2. Go to the “right place” and check the available extension versions for the current configuration

3. Select the latest and most suitable version from the available versions

4. Store a secret key (Token) with which we can download the version (with a limited validity period)

5. Download it from the “right place”

6. Install into the information base (IS)

“The right place” for a smoker

The first thing that came to mind was to make the “right place” in the cloud. + you will need to keep a file (ini) there with a description of which version of the extension is suitable for which configuration. This crutch the decision as a whole has the right to life. But it has many inconveniences and limitations:

1. It takes a lot of time to correctly store versions and reflect this in a text file

2. Make a separate folder for each microservice with its own password?!

3. How to restrict access by period?!

and we went the other way.

“The right place” for a healthy person

So, we need some kind of server to store versions of microservices. And so that it can provide files upon request (has a REST API). And so that it can be easily and habitually administered. And so that it can be easily modified (preferably in the familiar 1C language). And so that he makes backups himself. Well, since we are 1Sniki, the decision came on its own: let it be the usual 1C information base (IB) in the cloud. There were no questions with the cloud – we chose the timing belt. I had to think a little about the configuration: at first there was a desire to do it on a “bare” configuration from scratch. But then they decided to use one of the advanced UNF configurations – and rightly so.

This is roughly what it looks like now

Results

• The system has been working quite stably for several months now.

• You can simply sell Tokens (either on Infostart or on other resources) and send a free installer

• The installer can determine whether there is a solution for the user's configuration at all

• The installer can automatically update the extension on a schedule

And then we thought that this might be useful to other solution developers, and began to gain access to the “right place” for developers, but that’s in the next story.

Alexander Mangela

Developer, Mangela LLC