>

Документация по коробочной версии «Битрикс24. Версия API клиента

Интеграцию интернет-магазина на 1С-Битрикс с системой можно произвести с помощью модуля системы в Bitrix.Marketplace.

При установке модуль поможет выгрузить существующие заказы в систему.

После установки модуль будет:

  • производить выгрузку новых заказов из 1С-Битрикс в систему;
  • производить обновление данных по существующим заказам с учетом изменений, внесенных в 1С-Битрикс;
  • производить выгрузку новых заказов и клиентов из системы в 1С-Битрикс;
  • производить обновление данных по существующим заказам с учетом изменений, внесенных в систему (например, в системе был изменен статус заказа, количество товаров в заказе и др., в 1С-Битрикс эти изменения также будут отражены);
  • отправлять в систему информацию об онлайн-оплате заказа пользователем.

Также существует возможность кастомизации классов плагина, без потери модифицированного кода при обновлении. Для того, чтобы внедрить модифицированный код, необходимо расположить копию файла с нужным классом в директории bitrix/php_interface/retailcrm .

В плагине имеется возможность кастомизации следующих файлов:

RestNormalizer.php
Logger.php
Client.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventories.php
RetailCrmPrices.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
ApiClient_v4.php
ApiClient_v5.php

Для кастомизации файлов, в названии которых есть используемая версия API, создаются файлы с названием без указания версии, например - RetailCrmHistory.php .

После создания копии файла с классом в директории bitrix/php_interface/retailcrm модуль будет использовать кастомизированный класс, можете вносить изменения в его методы.

Регистрация интернет-магазина в системе

Перед установкой зарегистрируйте Ваш интернет-магазин в Вашем экземпляре системы (раздел Администрирование > Магазины, например, в демо-версии):

Установка решения в 1С-Битрикс

  • Нажмите «Установить» на странице решения в Marketplace и укажите адрес Вашего интернет-магазина:

  • Загрузите модуль через Систему обновлений 1С-Битрикс:

  • Начните установку модуля:

Запустится мастер установки.

Мастер установки. Шаг 1

На шаге 1.1 Вам необходимо указать адрес Вашей системы (например, https://test.retailcrm.ru) и API-ключ, который Вы сгенерировали ранее в системе:

Важно! Если в битриксе существует только один магазин, шаг 1.Сайты пропускается.

Мастер установки. Шаг 1.Сайты

На шаге 1.Сайты необходимо задать соответствие между Вашими магазинами в 1С-Битрикс и системой.

Важно! У всех Ваших магазинов в системе должен быть общий API-ключ.

Мастер установки. Шаг 2

На втором шаге необходимо указать соответствие значений справочников интернет-магазина и системы. Модуль сам пытается установить соответствие для типовых статусов. Там, где это не удалось сделать модулю, вам нужно указать соответствие самостоятельно:

Проверьте, есть ли в системе необходимые значения справочников, соответствующие справочникам интернет-магазина. Если их недостаточно, добавьте их в разделе Администрирование, не закрывая страницу мастера установки:

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

Мастер установки. Шаг 3

На третьем шаге модуль позволяет задать соответствие между полями 1С-Битрикс и системы.

Важно! Если есть форма «обратной связи» или заказы «в 1 клик», и эти данные не попадают в стандартные заказы битрикс, то в систему они не подтягиваются.

Также, если ведется работа с юридическими лицами, необходимо заполнить все поля, как указано на скриншоте ниже.

Мастер установки. Шаг 4

На четвертом шаге модуль позволяет Вам выгрузить оформленные ранее заказы в систему. Выгрузка может занимать некоторое время (1000 заказов выгружаются около 5 минут). Ход процесса выгрузки будет показывать прогресс-бар.

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

Выгрузив оформленные ранее заказы, Вы сможете увидеть аналитические отчеты в Панели KPI. Мы рекомендуем выполнять этот шаг.

Мастер установки. Шаг 5

На пятом шаге настраивается выгрузка каталога товаров. Для этого необходимо выполнить следующие пункты.

1. Выбор инфоблоков и свойств

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

2. Путь к файлу

По указанному пути будет сгенерирован файл в формате , в котором будет находиться структура каталога. По умолчанию установлен путь - "/bitrix/catalog_export/retailcrm.xml" . В случае смены пути, потребуется выполнение аналогичной настройки в системе.

3. Настройка количества офферов в экспорте

В настройках экспорта каталога присутствует поле «Максимальное количество торговых предложений у товара», где необходимо вводить максимальное число торговых предложений, которые могут быть у одного товара (если их больше 50). По умолчанию модуль рассчитывает максимум на 50 торговых предложений у товара. Если торговых предложений в магазине меньше 50 на товар, эту настройку можно игнорировать. Если торговых предложений больше и настройка указывается, рекомендуется переводить агент на крон, если он работает на хитах.

4. Выбор периодичности выгрузки

На выбор будут даны три варианта:

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

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

2. Cron - выбор данного пункта приведет к автоматическому созданию специального профиля, который будет привязан к службе Cron сервера, на котором функционирует сайт интернет-магазина.

Утилита cron работает в фоновом режиме и выполняет указанные задачи в указанное время.

Выбор данного пункта может быть полезен, если каталог содержит очень большую номенклатуру (более 10 000 товаров ). Для этого пункта необходимо указать имя специального профиля экспорта.

3. Агент . В данном случае, также будет создан специальный профиль, который подключится к технологии «Агенты» в 1С-Битрикс, и выгрузка будет происходить автоматически раз в сутки .

Агент - это php-функции, которые запускаются с определенной периодичностью. В начале загрузки каждой страницы система автоматически проверяет, есть ли агент, который нуждается в запуске, и в случае необходимости исполняет его. Не рекомендуется создавать агентов для длительных по времени выгрузок - лучше использовать cron.

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

В случае большой номенклатуры (более 10 000 товаров ), необходима дополнительная настройка Агента на Cron. Для этого пункта также необходимо указать имя специального профиля экспорта.

4. Указание моментальной выгрузки

В результате установки флага «Выгрузить сейчас», произойдет выгрузка структуры каталога в указанный выше файл, сразу после установки модуля.

После выгрузки каталога в файл в системе необходимо зайти в раздел Администрирование -> Магазин -> Название магазина -> Вкладка "Каталог" и поставить галочку в поле «Загрузить каталог из ICML сейчас». В этом случае скачивание файла и его обработка начинаются практически моментально.

5. Указание имя профиля

После корректной настройки выгрузки каталога товаров, в разделе Магазин > Настройки > Экспорт данных появится новый вид экспорта системы, в случае указания периодической выгрузки при установке, также появится профиль экспорта.

Примечание:
Для самостоятельной настройки выгрузки есть возможность создания собственного профиля экспорта.

Завершение мастера установки

В конце установки будут созданы 2 агента: один агент выгружает историю заказов из Битрикс в систему, второй агент генерирует каталог. Если выгрузка заказов настроена на агент, то заказы выгружаются в систему в момент вызова истории. В остальных случаях заказы выгружаются по событию.

Выгрузка службы доставки при обмене 1С-Битрикс – система

Если у вас к 1С-Битрикс подключены автоматизированные службы доставки, такие как eDost, у которых много профилей: Почта России, EMS, DHL и многие другие, то в системе Вы можете воспользоваться возможностью выгрузки такого рода службы доставки.

На стороне системы должны быть настроены способы доставки. Если модуль системы был установлен до подключения службы доставки к Битриксу, то недостающие способы доставки нужно будет завести в систему вручную. Если модуль был установлен после подключения службы доставки, то способы доставки установятся автоматически, как и сама выгрузка службы. То есть для каждого заказа будет выгружаться стоимость доставки.

На стороне 1С-Битрикс необходимо сделать следующие настройки, если модуль системы был установлен после подключения службы доставки к системе 1С-Битрикс:

Перейдите в Администрирование > Настройки , перейдите на вкладку "Настройки справочников".

Настройте соответствие способов доставки (предварительно настроив на стороне системы). Далее нажмите кнопку "Выгрузка служб доставок".

Настройка периодичности выгрузки 1С-Битрикс – система

При обновлении каталога товаров можно выделить два момента:

Генерация каталога (в формате yml/icml) на стороне клиента и

Система загружает каталог раз в три часа. Путь к файлу, который необходимо выгрузить, задается в настройках магазина - нужно зайти в раздел Администрирование > Магазины > Выбрать магазин > Вкладка Каталог .

После установки модуля системы в 1С-Битрикс создается профиль для выгрузки. Чтобы посмотреть, нужно зайти в Рабочий стол > Магазин > Настройки > Экспорт данных . На скриншоте представлено два варианта:

По умолчанию,

Выгрузка каталога системы.

Если выбрать второй вариант, нажав на него, можно открыть параметры выгрузки.

В случае, если вариантом периодичности выбран Агент, чтобы посмотреть список Агентов, нужно зайти в Рабочий стол > Настройки > Настройки продукта > Агенты .

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

Периодичность синхронизации данных при обмене 1С-Битрикс – система

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

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

Обмен заказами - это процесс синхронизации данных, когда заказы выгружаются в обе стороны:

Из 1С-Битрикс в систему:

  • Если включена выгрузка по событиям, при создании или изменении заказа в системе 1С-Битрикс, он сразу же выгрузится в систему. Если выбран агент выгрузки, то заказ выгрузится в систему в течение 15 минут (не рекомендуется использовать этот механизм без веских причин, так как в этом случае заказы приходят с задержкой и обновления этих заказов в систему переданы не будут).
  • При изменении пользователя, основные данные также сразу выгрузятся в систему.

Из системы в 1С-Битрикс:

  • Если в системе создать заказ для нового пользователя, то в 1С-Битрикс выгрузится заказ и создастся новый пользователь в интервале от 1 до 15 минут.
  • Если в системе на странице заказа изменить адрес, стоимость доставки или статус, то все эти изменения выгрузятся в 1С-Битрикс в течение 15 минут.
  • Если в системе изменить скидки у товаров и изменить количество товаров - это изменится и в 1С-Битрикс в промежутке от 1 до 15 минут.

Изменения в модуле интеграции

Версия 2.0

  • Модуль интеграции версии V2.0 предназначен для интеграции 1C-Битрикс с установленным в нем модуле "Интернет-магазин (sale)" версии > 16.
  • Теперь работа модуля осуществляется посредством API V4.
  • В модуле интеграции теперь используется новое ядро 1С-Битрикс D7.
  • Теперь из системы на сайт также приходят изменения по клиенту (Ф.И.О., email, телефон).
  • В настройках модуля интеграции в разделе "Прочие настройки", появилась возможность транслировать номера заказов из системы в 1C-Битрикс. То есть, если в системе создать в ручном режиме заказ с номером, к примеру, 12345R, то в 1С-Битрикс создастся заказ с таким же номером.
  • Так как в модуле "Интернет магазин(sale)" версии > 16 разработчики Битрикс ушли от применения скидок ко всему заказу и оставили скидки только у товаров, то в системе, пока что, также нет возможности использовать скидки ко всему заказу. Можно задавать скидки только к конкретным позициям заказа.

Версия 2.1

  • Добавлены единицы измерения в экспорте каталога.

Версия 2.2

  • Теперь модуль поддерживает несколько версий API с возможностью выбора.
  • Поддержка API V5.
  • Добавлена возможность выгрузки остатков в разрезе складов.
  • Добавлена возможность выгрузки типов цен.
  • Добавлена базовая интеграция Daemon Collector.
  • Добавлена интеграция с Universal Analytics.
  • Доработана логика работы встроенных функций для модификации данных.
  • Добавлена встроенная функция retailCrmApiResult.
  • Добавлен триггерный вариант истории изменений.

Версия 2.4

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

Прочие настройки

Настройки заказов

Транслировать номера заказов созданных в црм в магазин

При создании заказа в системе, у него формируется свой уникальный номер по заданным правилам. При выставлении этой настройки в модуле номер такого заказа будет передан в магазин при обратной синхронизации.

Выгрузка заказов

  • По событию - при сохранении заказа данные уходят в систему;
  • Агентом - выполняется отправка новых заказов перед запросом истории изменений из системы.

Версия API клиента

Теперь можно выбирать верисю API, с которой будет работать модуль. Возможность выбора зависит от версии системы. Рекомендуется выбирать самую новую версию.

Включить выгрузку остатков в разрезе складов (доступно при наличии складов)

Теперь можно осуществлять периодическую выгрузку остатков со складов сайта в склады системы. Для этого нужно:

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

Выгрузка осуществляется агентом с периодичностью в 1 час (по умолчанию).

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

Включить выгрузку типов цен для товаров (доступно только при наличии нескольких типов цен)

Теперь можно осуществлять периодическую выгрузку дополнительных типов цен из магазина в систему. Для этого нужно:

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

Выгрузка осуществляется агентом с периодичностью в 24 часа (по умолчанию).

Активировать Демон Collector

Теперь из интерфейса настроек можно добавить на сайт Демон Collector. Для этого нужно указать соответствующий ключ для нужного сайта. Ключ можно найти в системе.

Включить интеграцию с UA

Теперь из интерфейса настроек можно включить интеграцию с Universal Analytics (корректно работает со стандартным компонентом оформления заказов). Для каждого сайта, на который Вы хотите добавить отслеживание, нужно заполнить Идентификатор отслеживания и Индекс пользовательского параметра.

Где $order - сформированный массив данных заказа для отправки в систему, а $arFields - массив полей заказа на сайте. function retailCrmBeforeOrderSave($order) { //Ваши изменения return $order; //либо return false; и тогда изменения из системы по этому заказу будут проигнорированы }

Где $order - массив с измененными данными заказа, пришедший из системы.

Функция retailCrmAfterOrderSave

retailCrmAfterOrderSave - функция выполняющаяся сразу после сохранения на сайте изменений данных заказа, пришедших по истории из системы.

function retailCrmAfterOrderSave($order) { //Ваши изменения return; }

Где $order - массив с измененными данными заказа, пришедшими из системы.

Функция retailCrmApiResult

retailCrmApiResult - функция выполняющаяся сразу после получения ответа от API системы.

function retailCrmApiResult($methodApi, $res, $code) { //Ваши изменения return; }

Где $methodApi - название API метода, $res - результат запроса true / false (удачный или не удачный запрос), $code - код статуса ответа API.

Обратите внимание, что ошибки в коде при использовании данной функции могут нарушить работу синхронизации сайта и системы.

Если перечисленных выше инструментов по какой-то причине недостаточно, то можно внести требуемые изменения непосредственно в код модуля без риска потери этих изменений при обновлении модуля. Для этого требуется скопировать файл с нужным классом в директорию /bitrix/php_interface/retailcrm/ и уже в нем производить модификацию. Данный механизм поддерживает изменение классов для работы с клиентами, заказами, событиями, экспортом каталога и другими вспомогательными механизмами.


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

Закладка Администраторские задачи предназначена тем, кто будет администрировать коробочную версию «Битрикс24» .

Закладка Документация предназначена предназначена для разработчиков проектов на основе коробочной версии «Битрикс24» .

Пользовательские задачи

Администраторские задачи

Разработчикам

Документация для разработчиков - это описание API системы. Документация для пользователей - это описание компонентов и настроек системы.

Документация доступна как в он-лайн, так и в виде файла в формате chm. Рекомендуется пользоваться он-лайн версией, как более актуальной. Файлы формата chm обновляются периодически, в них может отсутствовать информация по последним версиям.

Внимание! Если вы не видите содержимое файла формата .chm , то причина - настройки безопасности операционной системы. В свойствах файла нужно снять блокировку файла от просмотра. Подробнее читайте в FAQ .

Документация - это справочная информация. Начинающему разработчику её не достаточно для работы с системой. В освоении принципов программирования в Bitrix Framework вам поможет специальный курс:

Информацию по работе с можно найти в учебных курсах и в документации. Учебные курсы предназначены для освоения методов работы в программном продукте, а документация - для освоения принципов кастомизации CMS.

При работе с «1С-Битрикс: Управление сайтом» проблемы возникают в виде конкретных практических задач. Мы собрали в профильные темы разные страницы учебных курсов, что бы облегчить вам поиск ответов на вопросы.



Учебные центры Задать вопрос Форум



Закладка Контент-менеджерам предназначена для тех, кто будет непосредственно работать с продуктом, то есть для контент-менеджеров, ведущих проекты, созданные на нашем программном продукте.

Закладка Администраторам предназначена для тех, кто будет администрировать «1С-Битрикс: Управление сайтом» .

Закладка Разработчикам предназначена для разработчиков проектов на основе «1С-Битрикс: Управление сайтом» .

Контент-менеджерам

Вы можете импортировать на свой сайт курс Контент-менеджер из этого архива . Курс без вопросов для тестов.
Версия курса от 5.06.2015 года.

Администраторам

Разработчикам

Документация для разработчиков - это описание API системы. Документация для пользователей - это описание компонентов и настроек системы.

Документация доступна как в он-лайн, так и в виде файла в формате chm. Рекомендуется пользоваться он-лайн версией, как более актуальной. Файлы формата chm обновляются периодически, в них может отсутствовать информация по последним изменениям в справочной системе.

Внимание! Если вы не видите содержимое файла формата .chm , то причина - настройки безопасности операционной системы. В свойствах файла нужно снять блокировку файла от просмотра. Подробнее читайте в FAQ .

Документация - это справочная информация. Начинающему разработчику её не достаточно для работы с системой. В освоении принципов программирования в Bitrix Framework вам поможет специальный курс:

Не так давно наша компания получила на сопровождение и доработку достаточно большой интернет-магазин на 1С-Битрикс. Проект пару месяцев, как был запущен в промышленную эксплуатацию, но при этом имел ряд серьезных проблем. Кроме того, заказчик планировал выполнить задачи по доработке нового функционала в максимально сжатые сроки. Передо мной была поставлена задача организовать эффективную работы по проекту с минимальным временем простоя сайта и максимальным удовлетворением потребностей заказчика.

Исходные данные:

  • Есть интернет-магазин на 1С-Битрикс
  • Проекту несколько лет, но только несколько месяцев назад сайт перевели на 1С-Битрикс
  • Посещаемость 10-15 тыс. человек в день
  • Каталог магазина содержит около 12 000 позиций товаров
  • Простои и отключения сайта недопустимы
  • Проект в течении полугода разрабатывался другой компанией:
    1. Есть ТЗ, примерно на 100 листов, соответствующее выполненной работе примерно на 40%
    2. Никакой документации проекта
    3. Отсутствие понимания, почему предыдущие разработчики использовали именно такие архитектурные решения.

Разработкой программного обеспечения в целом, и web-проектов в частности, занимаюсь около 8 лет. За это время сталкивался с проектами различной сложности и, на первый взгляд, задаче не показалась мне слишком трудной. При выполнении проектов в нашей компании, как правило, применяется методология SCRUM. От нее я и начал отталкиваться.

Первым делом, получил доступ исходному коду проекта. Поверхностно проанализировал. Согласовал с заказчиком список первостепенных задач. Составил план разработки для 3х разработчиков и, как сказал Гагарин, поехали!

Проблема №1 – во всем виноваты разработчики

Как это обычно и бывает, во всем виноваты все, кроме заказчика. Дизайнер сделал макет, который слишком много весит, хостер предоставил сервер, который медленно работает, разработчики сделали сайт, который все время глючит и ломается, менеджеры выполнили какие-то задачи, которые мы выполнять не просили, после перехода со старой версии сайта на 1С-Битрикс произошло резкое снижение поискового трафика и т.д. Ситуация не однозначная. С одной стороны основная ответственность конечно же должна лежать на компании разработчике. Нужно было донести до заказчика последствия всех действий с сайтом и подготовить к результату. При выполнении работы предложить целостную архитектуру будущей системы и план разработки, которого нужно придерживаться до завершения основных этапов. Провести тщательное тестирование функционала и сдать работу. С другой стороны, не редко сталкиваюсь с ситуацией, когда заказчик все сам лучше знает, потому что у него мама когда-то рисовала, а посему является лучшим дизайнером, и его 7ми летний сын прекрасно разбирается в SEO-оптимизации, потому что все время проводит за компьютером, играя в GTA.

Кто виноват, кто прав судить не нам. В данном случае, предыдущим подрядчиком была достаточно известная надежная компания и ничего плохого об их разработке сказать не могу. Да и заказчик, объективно, переживает за свой продукт и старается его улучшить. Как оно было не знаю, для себя я нашел объяснение в недостаточном количестве аналитики предоставленной исполнителем заказчику.

В результате:

  • Проект не доведен до логического завершения. Многие задачи брошены на середине пути
  • Проект не задокументирован. Работа части функционала не очевидна. При разработке нового функционала оказывается, что перестал работать функционал, который раньше работал и о существовании которого новый разработчик и не подозревал
  • Часть написанного предыдущим исполнителем кода приходится переписывать с нуля
  • Задуманная архитектура проекта в первые недели/месяца работы новому подрядчику не ясна. Доработка функционала одного модуля приводит к потере работоспособности функционала никак не связанного с ним модуля
  • Заказчик нервничает, исполнитель нервничает, посетители не довольны, посещаемость уменьшается, продажи падают

Решение проблему вижу только одно: постепенно планомерно вычищать все модули сайта по очереди для доведения продукта до требуемого состояния. Какие-то ошибки были вынесены в отдельные задачи и выполнены немедленно, что-то удалось поправить параллельно с разработкой нового функционала. Результат - с каждым апдейтом, после оперативного вычищения вылезших багов, сайт становится все лучше и стабильнее.

Проблема №2 – параллельная разработка.

В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки. Проблема заключается в том, что разработка ведется несколькими, в моем случае, тремя, разработчиками непрерывно. В случае с классической разработкой все просто. Каждый разработчик занимается своим модулем. Затем проводится функциональное тестирование каждого модуля, все доработки сливаются в репозиторий какой-нибудь системы контроля версий, дальше это тестируется все вместе (интеграционное тестирование). Если результат нормальный –тестовая версия презентуется заказчику. После принятия тестовой версии происходит обновление продакшен-сервера. В соответствии с методологией SCRUM я определил, чтоб буду выкладывать новые версии на боевой сайт раз в неделю. Соответственно, есть 3-4 дня на основную разработку. 1 день на тестирование и исправление ошибок и пол дня на обновление боевого сервера. Сроки конечно колеблются, но правила «релиз каждый четверг» старался четко придерживаться.

Первое с чем столкнулся, в 1С-Битрикс есть ситуации, в которых один и тот же файл одновременно задействован в разном функционале в разных концах сайта. Самое простое и очевидное решение – использовать систему контроля версий, в моем случае, SVN, которым пользуюсь во всех остальных проектах. Но для использования контроля версий необходимо, чтоб у каждого разработчика была своя собственная версия кода, которую он правит и затем сливает общий репозиторий.

Как же быть с лицензией? Обратился в техническую поддержку 1С-Битрикс. Получил предложение докупить доп. лицензии для разработки. Мягко сказать, не обрадовался, но других предложений не получил. Выход нашел достаточно быстро. Решил использовать NFR-ключи. Благо, партнерский статус позволяет. В результате создал 5 исталяций интернет-магазина:

  • Продакшен-сервер
  • Тестовый сервер
  • 3 сервера разработки (по одному на разработчика)

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

Сейчас использую следующую схему:

  • Каждый разработчик использует для работы только свою локальную копию
  • В оговоренное время все завершенные доработки сливаются в общую ветку в репозитории
  • QA забирает себе «смердженную» версию для тестирования
  • После тестирования и исправления ошибок происходит обновление демонстрационного сервера для заказчика
  • После проверки и акцепта заказчиком, доработки переносятся на боевой сервер.

Из очевидных минусов такого подхода хочу выделить низкий уровень вовлеченности заказчика в разработку. Результат виден заказчику уже только на финальной стадии. Такой подход применим если у вас есть хороший аналитик, который редко ошибается и находится в постоянно контакте с заказчиком. Иначе, многие задачи придется переделывать с нуля.

По мере построения схемы столкнулся с еще одной проблемой. Проект занимает на диске около 80Гб. Без кеша и временных файлов – около 60. Пытался по началу убрать картинки и видео из контроля версий – не получилось. Информация на сайте меняется постоянно. Тестировать нужно на актуальных данных. Первый комит сайта в репозиторий у меня шел кусками более 2х суток. Первый чекаут в папку для разработки проходит несколько часов (SVN сервер в локальной сети разработки). Если, не дай бог, случайно сделать полный апдейт папки проекта – можно уходить курить, обедать, играть в пинг-понг или керлинг. Комит только выбранных файлов или папок проходит достаточно быстро. Решение: выполнил задачу – закомить сразу десяток измененных файлов.

Проблема №3 – обновление продакшен-сервера и совместная работа с заказчиком

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

Тут отлично работают законы Мерфи:

  • Если что-то плохо работает на тестовом сервере – на боевом сервере это обязательно сломается.
  • Если что-то отлично работает на тестовом сервере – на боевом сервере это все равно обязательно сломается.
  • Если баг на сайте существует всего 5 секунд, его обязательно найдет кто-то из посетителей и обязательно напишет об этом в отзывах или в форме обратной связи.
  • Если сайт не работает 1 минуту во время обновления, то именно в эту минуту владелец компании будет показывать его своему другу или конкуренту (и это не смотря на согласование времени и процедуры обновления).
Я, конечно, утрирую, но в каждой шутке есть доля шутки. Минимальная нагрузка на сайт с 4 до 6 утра. Обновлять в это время конечно бы лучше, но уж очень не хочется.

В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части:

  • Обновление программного кода
  • Обновление базы данных с помощью SQL-скриптов

В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут. Можно конечно апдейтить только измененный файлы, но тогда теряется весь смысл репозитория. Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку. А это всегда медленно, нужно помнить все изменения, которые необходимо выполнить, велика вероятность случайно ошибиться. Можно, конечно, написать SQL скрипт, который сам внесет все нужные изменения в базу. В простейших случаях, разумеется, так и делаем. Но в большинстве случаев написание и отладка такого скрипта занимает больше времени чем сама разработка и намного больше времени, чем выполнение всех действий вручную с последующей проверкой.

Хорошего решения проблемы пока не нашел. Сейчас обновляем настройки в базе вручную. Для минимизации ошибок составляется чек-лист со списком что нужно сделать при апдейте. Обновление стараемся производить максимально внимательно и аккуратно. После обновления всей командой проверяем основной функционал продакшен сервера и проводим дополнительное тестирование. Количество ошибок минимизировано, но полностью от багов и простоев при обновлении избавиться пока не получилось.

Второе, с чем столкнулся, это совместная работа с заказчиком. Т.к. проект большой, над ним постоянно трудится около 30 человек. Контент-менеджеры, менеджеры по продажам, SEO-оптимизаторы, маркетологи и много еще кого. Естественно, каждый вносит в страницы сайта и настройку модулей какие-то изменения. Первым решением было забрать права у заказчика на внесение изменений в программный код сайта. Решение абсолютно правильно, но стало только хуже. Если раньше заказчик предполагал, что он так же может зайти на сайт и случайно что-то сломать, то теперь все шишки стали сыпаться только на нас. При чем. Даже если контент-менеджер криво отредактировал текст на странице и не закрыл какой-то тег – все равно виноват разработчик. Решение нашлось довольно простое. В маркетплейсе есть бесплатны модуль по контролю версий страниц. Проблему это не убрало, все равно кто-нибудь время от времени что-то да наплужит, но зато теперь появилась возможность посмотреть в любой момент времени кто менял, что менял и почему все сломалось. Результат, конечно, не ice, но кучу нервов мне экономит.

Дополнительно приняли решение перед каждым обновлением тестового сервера берем на него копию с боевого. На это тоже уходит много времени. Заархивировать проект, перенести на другой сервер, разархивировать. Все это занимает несколько часов. Зато, новые доработки проверяются практически в боевых условиях. Если настройки тестового и продакшен сервера идентичны, разница в работе будет минимальна и количество ошибок существенно сокращается. Как показал опыт, за неделю продакшен сервер может измениться настолько, что часть нового функционала, работающего без проблем на копии недельной давности, на свежей копии может не заработать вообще.

Проблема №4 – «сделайте мне срочно, это же задача на 5 минут»

Проблема относится не столько к 1С-Битрикс, сколько к доработке и поддержке работающих проектов. Часто у заказчика возникает желание сделать какую-то мелочь, но срочно и сразу на боевом сайте. Результат всегда один – ничего хорошего из этого не выходит. В лучшем случае, об этой доработке просто забудут при очередном релизе, в худшем – сервер просто упадет и его придется несколько часов восстанавливать из бекапа.

Решение нашел только одно – никогда не идти на поводу у заказчика в ущерб надежности и безопасности. Как бы заказчик не просил, виноват всегда будет разработчик. Как говорил мне мой бывший начальник: «Я же тебя не просил сделать плохо».

И раз уж затронули тему бекапов, хочу заметить. Бекап средствами 1С-Битрик это конечно хорошо и удобно, но очень медленно. В случае, если срочно нужно восстановить 1-2 файла или несколько значений в базе, приходится ждать пока разархивируются все 60 Гб. Здесь наиболее эффективной мне кажется следующая схема:

  • Должен происходить ежесуточный бекап файлов и базы данных в виде архива на внешний источник данных.
  • Всегда делаем бекап непосредственно перед обновлением в одном из 2х вариантов:
    1. Вариант light – Копируем всю папку проекта в соседнюю папку на сервере. Базу данных в виде дампа сохраняем в отдельный файл. Ничего не архивируем. В случае, если нужно будет восстановить какое-то значение в базе или один из файлов, все будет под рукой и легкодоступно
    2. Вариант strong – аналогично предыдущему, только базу копируем в другую базу данных MySQL. Это позволит в случае полного краха за 1-2 минуты исправить в файле хостов корневую папку сайта и проект начнет работать из соседней папки с копией базы.

Заключение

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

Bitrix Framework - технологическое ядро (платформа) для создания и управления проектами (веб-сайтами и корпоративными порталами). Платформа позволяет создавать неограниченное количество проектов с применением одной копии (лицензии) продукта, размещая ядро и базу данных системы в единственном экземпляре на сервере.

На данный момент не все возможности старого ядра продублированы в D7. Но новое ядро D7 в Bitrix Framework постепенно замещает старое. Если использование старого ядра привело к предупреждению от IDE: Method/class is deprecated , значит нужно использовать методы .

В силу ряда причин API документация может не охватывать все методы. Для понимания работы иногда лучше просмотреть собственно программный код. Для этого можно использовать бесплатный модуль из Маркетплейса: .

Примечание : добавив к адресу любой страницы #examples можно быстро перейти к примеру, если он на ней есть. (В файлах документации формата CHM это не работает.)


Версии сущностей

Bitrix Framework постоянно развивается. Появляются новые функции, некоторые устаревают, в функциях появляются новые параметры. Однако достаточно большое число проектов не обновляются. Для облегчения программистского труда в документации проставлено с какой и по какую версию продукта класс, метод, параметр, событие существовали (существуют).

Версии проставляются в двух местах: в названии и в таблицах. Если метод действующий, то в заголовке будет стоять только номер версии с которой он появился в продукте. Если метод устарел, то там же будет указан диапазон версий, где он был действующий.

В таблицах указывается версия, с которой сущность появилась в продукте, только в том случае, если её появление не совпадает с моментом появления самого класса, метода и так далее. На иллюстрации ниже: параметр COURSE_ID появился вместе с методом (то есть с 5.1.0), а параметр CHAPTER_ID только с версии 9.5.4.

Если с развитием продукта параметр (обычно это относится к параметрам) изменялся, то будет соответствующее примечание в его описании. (Например: до версии х.х.х параметр назывался *****).

Пример

Примечания :

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

«Битрикс», 2001-2019, «1С-Битрикс», 2019