Since the last episode aired, I’ve been very busy implementing an application for a retail store owned by my client. I added a whole bunch of catalogs, documents, registers and even reports. So, now the first version of the app is fully-functional, and the client can now trace purchases, sales, and inventory using it. The next step is to add more people to the picture: another developer and a whole bunch of users. This is what I want us to discuss today.
So, this is my computer with Designer, Client, File-based DB support components and the single-user license installed. And this is another developer who has joined the party just now. Setting up his computer I installed all the same components, except I need another single-user license for this computer. Now, here is the question. What database are we to use for development?
This is where my development database lives. Should I just share this folder over the network for the second developer to connect? Will it even work? Let’s check. I’m opening my infobase with Designer and then trying to open it with another one. And then this happens.
The message says that the infobase is locked by the first Designer, and the sec ond one cannot be opened. It means that Designer does not support co-development in a single infobase, and each developer has to have their own DEV infobase. So, developers work with their personal copies of the application, each working on some part of its functionality. But at some point, they will have to combine their versions into a single app somehow, right? How does this work? Well, of course, nobody merges two versions manually.
Instead, we use Designer’s built-in version control system called Repository. First, I need to create the Repository from the current version sitting on my computer. But where should the repository live? Wherever you want it to. You can set it up on a separate computer and share its folder over the local network. Or, you can unroll it to one of the developers’ computers, like this. I’m going to the Configuration repository menu, and creating a new Repository in this folder that I’m going to share with other developers later.Here I can set up the Repository administrator password or just leave it empty like this. And now the Platform asks me if I want to bind my infobase with the Repository I just created. If I do so, my development database gets interlocked with the Repository and any changes in the database need to be run by the Repository. Which is exactly what I need, so, I’m answering yes. And now my application is under full version control by the Repository. How about the second developer?
Well, he already has his development database created. The only thing left to do is to bind it with the same Repository. OK, let’s do it. So, we are on my computer now, and first of all, I need to tell the Repository there is another user. So, I’m going to the Repository administration and adding the user just like this. OK. Now to the second developer’s computer. This infobase has been just created and is completely empty so far. The second developer is telling the Platform
to bind it to the Repository, pasting Repository’s network path, and telling it who he is. And here we go. The second developer’s infobase is now under version control by the same Repository, and he has the same version of the application. Now. See these locks all over the application? They mean these metadata objects are in the read-only mode until the developer tells the Repository, I need to edit one of them. Now these metadata objects is locked by the developer, so nobody but him can now change it. But the lock owner can now do whatever he likes - add a new attribute, for example. After the developer finishes working with the object, he uploads it to the Repository, and now the new object’s version is available to others. Let’s take a look at my development database, for example.
I’m working with my infobase and my version of the application, so there is no SerialNumber attribute in the Products catalog. But as soon as I try to lock this object in the Repository or retrieve its latest version Here is my new attribute right here. So, these were developers.
Now let’s add some users to the picture, shall we? The very first user - the company’s owner - uses Windows desktop and sits right here in the office. He needs the 1C client and 1C file-based format support, so this is what I installed first. As soon as I run the 1C client on his computer the first time, the Platform requests for the license, so this is my second move. Now. Which infobase should I connect him to? Not the developers’ ones, right? The infobases applications are under construction, they can be inconsistent or broken, and the data is used by developers for testing purposes.
So, we definitely need a separate production database which can live anywhere in our local network. But my computer is the most powerful one, so here it goes.
This database also needs a network share, so the user could connect to it. I also want to bind this infobase to the Repository, so that I could upgrade the application version as soon as developers decide it’s good to go. OK. Moving on.
Here goes our second user. This one uses a MacBook and works remotely over a regular Internet connection. So, the only feasible way for him to work with the production database is to use an HTTP connection. It can be done with a native 1C client for macOS or just a web browser.
From the infobase side it requires three things: a web server, the 1C web server extension and the infobase publication on the web server. Again. I could rig this up on a separate computer, but I don’t have a spare one.
I also don’t expect any noticeable workload from one HTTP user. So, this entire affair also goes to my workstation. And this is how I set this up. So, this is my computer I’m now on, and the first thing I need to do is to install the 1C web server extension.
So, I’m running Programs and Features. This is the latest Platform version. Modify. Adding the web server extension. Install. Done.
Next up: publishing the infobase to the web server. To publish the infobase,I need to run the Platform as an administrator, like this. This is my development infobase, and this is the production one I created behind the scene. Opening it with Designer. Connecting to the Repository. And this is where the publication is done.
Let’s change the publication name to Convenience, like this. And boom. The publication is successful. Now. The Platform warns me that I need to provide the web server user with access rights to the database catalog. All right, let’s do it. So, this is my production infobase catalog. Properties. Security. Adding the web server user to the list. Allowing full control. Done. OK. Now the Platform recommends restarting the web server. Sure thing. And done. So, this was my workstation.
Now, to our second user’s MacBook. I don’t even need to install anything here. The user just runs a web browser, enters the HTTP address, and here is my application running in the browser just like this. The address format is pretty straightforward. This is my server’s DNS name. This is the name I gave to the publication. And this is just a language code. So, these were our developers and the very first users.