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

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

Задача бизнеса и границы решения

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

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

Границы решения выглядят так. Мы не пытаемся сделать так, чтобы подрядчики «договорились сами». Мы описываем зоны, стыки и правила выпуска на бумаге, а затем проверяем, что эти правила соблюдаются технически. Всё, что выходит за рамки описанных зон, проходит через согласование с владельцем сайта.

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

Матрица подрядчиков: кто за что отвечает

Матрица подрядчиков — это рабочий документ, а не формальность. В ней по строкам идут зоны сайта, а по столбцам — кто отвечает, что получает на входе, что отдаёт на выходе и как его результат проверяется. Без такой матрицы любая правка превращается в спор о том, чей это участок.

Заполняйте матрицу совместно с командами. Когда подрядчики сами определяют зоны и границы, стыки становятся видимыми сразу.

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

Границы кода и согласование изменений

Границы кода — это ответ на вопрос «кто и что имеет право менять». На практике удобно разделить всё на три категории: общий код, зона конкретного подрядчика и временные правки.

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

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

Временные правки — то, что делается быстро и должно быть убрано. Их нужно помечать и вести отдельным списком, иначе они накапливаются и превращаются в постоянный источник неожиданностей.

Согласование изменений удобно вести через единый журнал. В нём фиксируют: что меняется, кто автор, какая зона затронута, на каком стенде проверено, когда выпускается и как откатывается. Журнал не заменяет переписку, но даёт точку опоры, когда нужно понять, из-за чего возникла проблема.

Отдельный вопрос — доступы. Каждому подрядчику выдаётся минимально необходимый набор прав. Если команде нужен доступ к данным, которые ей не нужны для работы, это повод пересмотреть схему, а не «выдать на всякий случай». Порядок выдачи и отзыва доступов стоит описать заранее.

Порядок совместного выпуска изменений

Выпуск — самый рискованный момент, потому что именно здесь встречаются правки разных команд. Чтобы не гадать, кто выпускает первым, порядок фиксируют заранее.

Подготовка к выпуску

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

Тестовый стенд

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

Выпуск и наблюдение

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

Разбор после выпуска

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

Многосайтовость или отдельные инсталляции: развилка для нескольких команд

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

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

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

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

В рамках системы сайт определяется как совокупность параметров в базе данных (идентификатор, доменное имя, папка сайта, региональные настройки и др.), условий подключения шаблонов, публичной части и настроек модулей, привязанных к этому сайту. В публичной части идентификатор текущего сайта хранится в константе SITE_ID. Это значит, что часть настроек и данных живёт на уровне сайта, а часть — на уровне всей установки, и разделить их произвольно нельзя.

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

Практический пример на тестовых данных

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

Рассмотрим пример компании с одним интернет-магазином на Битрикс. С сайтом работают три подрядчика: команда разработки (доработки функциональности), контент-подрядчик (тексты, карточки, разделы) и подрядчик по рекламе (лендинги под кампании и цели аналитики).

Входные условия

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

Что происходит

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

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

Наблюдаемый результат и проверка

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

Ценность примера — в порядке: сверка зон, тестовый стенд, выпуск, проверка. Этот порядок исключает взаимные поломки при работе нескольких подрядчиков.

Как проверить результат и принять работу

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

• Изменения из журнала выпущены полностью, ничего не осталось «на потом» без пометки
• Ключевые сценарии сайта работают: открываются разделы, карточки, формы, страницы кампаний
• Смежные зоны не пострадали: проверены участки, которые задевает общий код
• Настройки модулей соответствуют согласованному описанию
• Цели аналитики срабатывают на тестовых действиях
• Резервная копия сделана до выпуска и доступна для возврата
• Доступы подрядчиков соответствуют матрице, лишние отозваны
• Замечания приёмки зафиксированы с ответственным и сроком устранения

Если по какому-то пункту нет ясности, это повод не принимать работу с оговоркой, а вернуться к матрице и уточнить, кто отвечает за проверку. Приёмка без ответственного превращается в обмен сообщениями, а не в результат.

Типичные ошибки и ограничения

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

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

Третья — размытые доступы. Если у подрядчика прав больше, чем нужно для его зоны, риск случайной поломки растёт, а разбор инцидента усложняется.

Четвёртая — отсутствие журнала изменений. Без него сложно отследить, чья правка привела к проблеме, и приходится восстанавливать хронологию по переписке.

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ и риски, заказчику стоит собрать набор исходных данных. Чем полнее они будут, тем точнее получится план.

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

Описание текущих доступов: у кого какие права, кто и как их выдаёт и отзывает. Наличие тестового стенда и порядок его обновления. Наличие резервных копий и порядок возврата.

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

Если часть данных отсутствует, это не повод откладывать оценку — это повод включить в план отдельный шаг по их сбору. Когда команда разработки подключается к проекту, где уже работают другие подрядчики, полезно заранее проговорить зоны и стыки; о том, как выстроить такую работу, рассказывает материал про Битрикс-разработчика в аренду. А если нужно усилить проект на время или закрыть отдельную зону, стоит рассмотреть разработчиков в аренду как способ добавить компетенцию без перестройки всей схемы.

Что дальше

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

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