In this article, we will tell you how to organize developments in Bitrix24 in such a way that you can control them, and updates go smoothly.

Information about what exactly can be improved in Bitrix24,can be viewed here.

cloud portal

For those who work with the cloud portal, the organization of development will be as simple as possible. There is no need to control anything on the part of the customer, since the cloud portal cannot be broken.

Development for the "cloud" is carried out only in the form of applications that do not change the current capabilities, but add new features. An app either works or it doesn't.

And the portal itself will work in any case.

box portal

If you use the boxed version of Bitrix24 and need to improve it, then in this case you should follow the methodology. You can't let a developer into the productivity portal right away, even though it might seem like a good idea at first. A developer with direct access will complete the task faster, but sooner or later there will be a problem with development control and updating the portal.

The methodology presented below was invented long ago and is the standard in commercial development. But unfortunately, it is rarely used in the Bitrix24 implementation market. Most often, programmers immediately make changes on the productive portal.

Methodology for developing a boxed version of Bitrix24

What problems does this methodology solve:

• Uncontrolled code change on a production server. After a long time and when changing programmers, it's hard to remember the essence of improvements. As a result, technical debt appears, that is, a decrease in the pace of development due to the fact that the programmer is forced to spend time searching for the code of the previous developer and understanding it. Technical debt is especially dangerous if a significant upgrade of the portal is planned.

• Lack of development registry. It is needed in order to find out what was done in the process of finalization and how.

• Update problems. If the methodology is not followed, the update may overwrite the development or lead to errors in the work of the current development. The update is done according to a special regulation.

The methodology itself looks like this:

1. The code is stored in the Git version control system.

2. All developments are listed under certain numbers in the registry.

3. A three-tier development architecture is used: local portal - test portal - productive portal.

4. Updates are made according to a special regulation that allows you to control them.

Let us dwell in more detail on the three-tier architecture. In this case, work is carried out on three portals:

• Productive - all users of the customer work on it. It should work as stable as possible.

• Testing - developments are made on it, their performance is checked, it is updated before the productive portal. The test and production portal codes must match. This is controlled using Git.

• Local is a copy of a test or production portal (it is possible without a database), which is convenient for development. After testing the development, the changes are sent to the test service.

Let's get back to the methodology. After copying the production portal to the test portal and connecting to the Git version control system, you need to prevent developers from directly accessing the production portal. This will eliminate the possibility of editing files in the productive portal, bypassing Git.

It is also recommended that developers not be given administrative access to the Productivity Portal. However, this issue is decided on a case-by-case basis. If a developer makes settings in the administrative part of the productive portal, he can make changes himself and not notify the customer about it. It is recommended that the customer's employee independently make the settings according to the instructions that the developer fills out. This is called the "administrator's guide".

Updating the portal is done first on a test version. After checking the performance of all improvements, the productive portal is updated.

Developers do not always want to use the described methodology. However, it allows you to systematize the development process and avoid "falls" of the productive portal. Developers may also be frustrated by the lack of administrative access to the server and ftp, but a local copy and a test portal are sufficient for development.

In this case, an experienced employee is responsible for updating the productive portal.