В этой статье мы расскажем как организовать разработки в Битрикс24 таким образом, чтобы можно было их контролировать, а обновления проходили без сбоев.

Информацию о том, что именно можно дорабатывать в Битрикс24, можно посмотреть здесь.

Облачный портал

Для тех, кто работает с облачным порталом, организация разработки будет максимально простой. Со стороны заказчика не требуется ничего контролировать, так как облачный портал невозможно сломать.

Разработка для «облака» ведется только в виде приложений, которые не меняют текущие возможности, но добавляют новые функции. Приложение либо работает, либо не работает.

А сам портал будет работать в любом случае.

Коробочный портал

Если вы пользуетесь коробочной версией Битрикс24 и нужно ее доработать, то в этом случае следует придерживаться методологии. Нельзя пускать разработчика сразу на продуктивный портал, несмотря на то, что вначале это кажется хорошей идеей. Разработчик при прямом доступе быстрее выполнит поставленную задачу, но рано или поздно возникнет проблема с контролем разработки и обновлением портала.

Представленная далее методология придумана давно и является стандартом в коммерческой разработке. Но к сожалению на рынке внедрения Битрикс24 ее применяют мало. Чаще всего программисты сразу вносят изменения на продуктивном портале.

Методология разработки коробочной версии Битрикс24

Какие проблемы решает использование этой методологии:

• Неконтролируемое изменение кода на продуктивном сервере. По прошествии длительного времени и при смене программистов тяжело вспомнить суть доработок. В результате появляется технический долг, то есть снижение темпов разработки из-за того, что программист вынужден тратить время на поиск кода предыдущего разработчика и его понимание. Технический долг особенно опасен, если планируется значительное обновление портала.

• Отсутствие реестра разработок. Он нужен для того, чтобы узнать, что было сделано в процессе доработки и каким образом.

• Проблемы с обновлениями. Если не придерживаться методологии, обновление может затереть разработку или привести к возникновению ошибок в работе текущей разработки. Обновление делается по особому регламенту.

Сама методология выглядит следующим образом:

1. Код хранится в системе контроля версий Git.

2. Все разработки числятся под определенными номерами в реестре.

3. Используется трехзвенная архитектура разработки: локальный портал — тестовый портал — продуктивный портал.

4. Обновления делаются по особому регламенту, который позволяет контролировать их.

Остановимся подробнее на трехзвенной архитектуре. В этом случае работа ведется на трех порталах:

• Продуктивный – на нем работают все пользователи заказчика. Он должен работать максимально стабильно.

• Тестовый – на нем делаются разработки, проверяется их работоспособность, он обновляется перед продуктивным порталом. Коды тестового и продуктивного портала должны совпадать. Это контролируется с помощью Git.

• Локальный – это копия тестового или продуктивного портала (можно без базы данных), на котором удобно вести разработку. После тестирования разработки изменения отправляются на тестовый сервис.

Вернемся к методологии. После копирования продуктивного портала в тестовый и подключения к системе контроля версий Git необходимо запретить прямой доступ разработчиков к продуктивному порталу. Это исключит возможность правки файлов на продуктивном портале в обход Git.

Рекомендуется также не давать административный доступ к продуктивному порталу разработчикам. Однако этот вопрос решается в каждом конкретном случае индивидуально. Если разработчик делает настройки в административной части на продуктивном портале, он может сам внести изменения и не сообщить об этом заказчику. Рекомендуется, чтобы сотрудник заказчика самостоятельно делал настройки согласно инструкции, которую заполняет разработчик. Это называется «инструкция администратора».

Обновление портала делается сначала на тестовой версии. После проверки работоспособности всех доработок обновляется продуктивный портал.

Разработчики не всегда хотят использовать описанную методологию. Однако она позволяет систематизировать процесс разработки и избежать «падений» продуктивного портала. Разработчиков может также расстроить отсутствие административного доступа к серверу и ftp, однако локальной копии и тестового портала достаточно для разработки.

Обновлением продуктивного портала в этом случае занимается опытный сотрудник.