Episode 3. Scaling up
1C Engineer training course Start learning now for free 👉 https://academy.1ci.com/ Telegram chat: https://t.me/joinchat/DRc2iRL1O5OcAJYpX6RCIA Blog on Medium: https://medium.com/yellow-universe #1CiAcademy #1CEnterprise #LowCode Link to the training course: https://support.1ci.com/hc/en-us/categories/360001634200-1C-Enterprise-Platform-Training-Course-1C-Engineer-level 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.
1C Engineer training course Start learning now for free 👉 https://academy.1ci.com/ Telegram chat: https://t.me/joinchat/DRc2iRL1O5OcAJYpX6RCIA Blog on Medium: https://medium.com/yellow-universe #1CiAcademy #1CEnterprise #LowCode Link to the training course: https://support.1ci.com/hc/en-us/categories/360001634200-1C-Enterprise-Platform-Training-Course-1C-Engineer-level 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.