Инженерный контур 1С. Часть 4 - Декомпозиция метаданных, отказ от блокирующего Хранилища 1С и внедрение гибридного контура версионирования

5 сентября 2026 · infolimp.ru

Контекст и аудитория

• Профиль читателя: Ведущие разработчики 1С, системные архитекторы, release-инженеры, технические руководители команд разработки и DevOps-специалисты, внедряющие современные инженерные практики версионирования, непрерывной интеграции и контроля качества в контур корпоративных систем на платформе «1С:Предприятие 8.3».
• Исходное состояние системы: Сквозной практический кейс серии - продуктивный контур «Торговый контур»:
• Масштаб и прикладное решение: Крупное торгово-производственное предприятие, эксплуатирующее глубоко кастомизированную конфигурацию на базе 1C:ERP Управление предприятием 2.5 (более 3 500 объектов метаданных, объем расширений и доработок превышает 450 000 строк кода BSL).
• Инфраструктура и СУБД: Кластер серверов «1С:Предприятие 8.3» (релиз 8.3.24) под управлением Linux, база данных объемом 1.8 ТБ под управлением PostgreSQL 16.
• Организационная структура разработки: Распределенная инженерная команда из 8 разработчиков, одновременно реализующая функциональные требования по трем ключевым направлениям:
  1. Модернизация контура адресной складской логистики (WMS-функционал, поштучная обработка грузовых мест, интеграция с ТСД);
  2. Реализация обязательных государственных требований поштучной прослеживаемости и маркировки товаров;
  3. Развитие интеграционного контура внешних REST/HTTP API для обмена данными с витринами маркетплейсов и логистическими 3PL-операторами.
• Исходное состояние версионирования и проблемы:
  • Управление изменениями осуществлялось через классическое монопольное Хранилище конфигурации 1С;
  • Ежедневные простои разработчиков в очередях на захват разделяемых объектов метаданных (документ РеализацияТоваровУслуг, регистры накопления, общие модули проведения и общих механизмов);
  • Длительное время доставки изменений (Lead Time) - релизный цикл составлял от 3 до 4 недель;
  • Высокие риски перезаписи кода при ручном объединении веток перед выпуском релиза;
  • Полное отсутствие инструментария асинхронного предварительного рецензирования кода (Code Review) до его попадания в общую конфигурацию.
• Ограничения:
• Недопустимость деградации скорости разработки: Сохранение высокой отзывчивости инструментов на типовых операциях редактирования кода и форм;
• Минимизация совокупной стоимости владения (TCO): Отказ от закупки дорогостоящих рабочих станций с 64+ ГБ RAM под тяжелые IDE;
• Сохранение прикладной целостности метаданных: Гарантия исключения коллизий внутренних идентификаторов UUID и разрушения связей метаданных при слиянии изменений.

В чём проблема

1. Архитектурный кризис монопольного Хранилища конфигурации 1С

Механизм «Хранилище конфигурации 1С» был спроектирован в эпоху локальных монолитных доработок и базируется на парадигме пессимистической блокировки (Pessimistic Locking). Для внесения изменений в любой объект метаданных разработчик обязан выполнить монопольный захват объекта на сервере Хранилища.

В команде из 8 инженеров, дорабатывающих смежные функциональные подсистемы на базе 1C:ERP 2.5, данная модель приводит к деградации инженерных процессов:

Разработчик 1 (Логистика):       [Захват: Документ.РеализацияТоваровУслуг] ---(В работе 4 дня)---> [Помещение]
Разработчик 2 (Маркировка):                                +---(Ожидание захвата 4 дня: Простой)---+
Разработчик 3 (Интеграции API):  [Захват: ОбщийМодуль.ПроведениеСервер] ------(Блокировка общего контура)--->

1. Невозможность изолированной работы над функциональными ветками (Feature Branches): Разработчик не может зафиксировать промежуточное состояние незавершенной задачи без публикации его в общий контур Хранилища. В результате в общую конфигурацию попадает незаконченный функционал, блокирующий сборку релизов и тестирование смежных задач.
2. Очереди ожидания разделяемых артефактов: В крупных конфигурациях существуют «узловые» объекты: ключевые общие модули (ОбщегоНазначенияУТ, ПроведениеСервер), документы движения и подсистемы. Захват такого объекта одним инженером останавливает работу остальных членов команды либо провоцирует кулуарные договоренности и передачу доработок через внешние файлы обработок.
3. Отсутствие асинхронного Code Review: Помещение в Хранилище является атомарным действием. Архитектор или ведущий разработчик лишены возможности провести превентивную инспекцию изменений в интерфейсе Pull Request / Merge Request до того, как код физически окажется в основной ветке. Постфактум-анализ журнала Хранилища не позволяет заблокировать дефектные архитектурные решения.
4. Изоляция от автоматизированных конвейеров CI/CD: Хранилище конфигурации не предоставляет стандартизированных webhooks, API для интеграции с системами отслеживания задач (Jira, Kaiten, GitLab Issues) и не способно триггерить запуск контейнеризированных модульных тестов при фиксации изменений.

2. Пределы масштабирования и ограничения 1C:Enterprise Development Tools (1C:EDT)

Естественной альтернативой Хранилищу со стороны вендора выступает среда 1C:EDT на базе Eclipse, изначально ориентированная на версионирование в Git. Однако при внедрении в контуре доработанной 1C:ERP 2.5 выявились критические эксплуатационные барьеры:

1. Экстремальные требования к аппаратным ресурсам рабочих станций: Для поддержания индекса и AST-дерева метаданных конфигурации масштаба 1C:ERP 2.5 процессу 1C:EDT требуется от 16 до 24 ГБ выделенной оперативной памяти (JVM Heap Xmx). При наличии фоновых локальных баз данных рабочая станция инженера требует не менее 32–64 ГБ RAM и 8–16 физических ядер CPU, что влечет резкий рост TCO инфраструктуры разработки.
2. Накладные расходы фоновой индексации при переключении контекстов: Переключение между ветками в Git (git checkout между релизной веткой и функциональной веткой доработки логистики) приводит к инвалидации внутренних индексов среды. Фоновая переиндексация модели метаданных занимает от 15 до 35 минут, в течение которых среда полностью загружает дисковую подсистему и процессор, блокируя автодополнение и синтаксический анализ.
3. Методический и когнитивный барьер команды: Инженеры, обладающие высокой продуктивностью в классическом Конфигураторе 1С, сталкиваются с задержками при открытии тяжелых управляемых форм и редакторов табличных документов, что снижает оперативную скорость выпуска доработок на начальных фазах проекта.

3. Обоснование гибридной архитектурной модели

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

$$\text{Гибридный контур} = \underbrace{\text{Конфигуратор 1С}}{\text{Быстрое локальное редактирование и отладка}} + \underbrace{\text{CLI платформы (ibcmd / 1cv8)}}{\text{Пакетная декомпозиция и сборка}} + \underbrace{\text{Git (GitLab / 3-way merge)}}_{\text{Ветвление, Code Review, Quality Gates}}$$

Данный подход позволяет: - Сохранить мгновенный отклик среды разработки и привычный инструментарий отладки для инженеров; - Перейти на полноценную модель изолированных веток (Feature Branch Workflow); - Внедрить обязательное рецензирование кода (Code Review) для 100% изменений; - Интегрировать версионирование с конвейерами непрерывного тестирования (CI/CD).

Архитектура решения

1. Архитектурная топология гибридного контура

Взаимодействие компонентов гибридного контура разработки исключает прямое подключение рабочих баз инженеров к единому серверу Хранилища. Единым источником правды (Single Source of Truth) становится Git-репозиторий декомпозированных XML/BSL-исходников конфигурации.

2. Механика трехстороннего слияния (3-Way Merge) метаданных 1С

В распределенной системе управления версиями слияние двух расходящихся веток основывается на алгоритме трехстороннего слияния (3-Way Merge). При выполнении команды git merge задействуются три состояния файла:

1. Базовый предок ($O$ - Base): Состояние файла в точке ветвления (наиболее поздний общий коммит предка между ветками).
2. Локальная ветка ($A$ - Ours / Local): Состояние файла в текущей активной ветке разработчика.
3. Вливаемая ветка ($B$ - Theirs / Remote): Состояние файла во вливаемой ветке коллеги.

Результирующий узел $M$ вычисляется на основе матрицы дифференциальных изменений:

$$\Delta A = A - O, \quad \Delta B = B - O$$

Если $\Delta A$ и $\Delta B$ затрагивают непересекающиеся диапазоны строк или независимые программные процедуры BSL, Git выполняет автоматическое слияние:

$$M = O + \Delta A + \Delta B$$

Однако если оба инженера модифицировали одну и ту же процедуру BSL или один и тот же XML-узел описания реквизитов объекта, возникает конфликт слияния (Merge Conflict).

       Коммит A (Ветка Логистики: добавлен реквизит ВесБрутто) [LOCAL]
      /
Коммит O (Общий предок: документ РеализацияТоваровУслуг) [BASE]
      \
       Коммит B (Ветка Маркировки: добавлен реквизит КодМаркировки) [REMOTE]

3. Неприменимость стандартного текстового слияния Git к метаданным 1С

Стандартные механизмы слияния Git (стратегии ort, recursive и утилита diff3) оперируют плоскими текстовыми строками. Для объектной модели метаданных платформы «1С:Предприятие» строковое слияние XML-файлов несет критические риски:

1. Разрушение синтаксической целостности XML-контейнеров: Вставка стандартных текстовых маркеров конфликта (<<<<<<<, =======, >>>>>>>) прямо внутрь тегов XML преобразует файл конфигурации в невалидный XML-документ (not well-formed). Платформа 1С при попытке последующей загрузки /LoadConfigFromFiles аварийно завершает работу с фатальной ошибкой парсера DOM.
2. Коллизия и дублирование внутренних системных UUID: Каждый объект, табличная часть и реквизит метаданных 1С идентифицируются уникальным 128-битным идентификатором UUID (uuid="7e8b9d30-..."). При автоматическом строковом слиянии Git может объединить два разных реквизита, созданных независимо, но получивших пересекающиеся ссылки в контейнерах ChildObjects, что разрушает ссылочную целостность метаданных.
3. Сбивка порядка следования элементов схемы XDTO: Платформа 1С строго регламентирует последовательность дочерних узлов в файлах метаданных (например, Properties обязаны предшествовать ChildObjects). Текстовый слиятель Git не учитывает XSD-схему и перемешивает узлы, делая файл непригодным для сборки конфигурации.

4. Принцип делегирования разрешения конфликтов платформе 1С

Единственным гарантированно безопасным способом разрешения конфликтов в метаданных является делегирование операции штатному механизму объединения конфигураций 1С: - Конфликт в программных модулях *.bsl может быть разрешен текстовым трехсторонним диффером, понимающим структуру процедур; - Конфликт в структурных файлах метаданных *.xml и файлах форм перенаправляется через интерфейс git mergetool в специальный сеанс Конфигуратора 1С, запускаемый с ключами объединения конфигураций /MergeCfg. Конфигуратор анализирует семантику метаданных, проверяет типы данных, исключает дублирование UUID и генерирует валидную результирующую структуру.

Пошаговая реализация

Шаг 1: Инициализация репозитория и нормализация окончаний строк (.gitattributes)

Платформа «1С:Предприятие» крайне чувствительна к кодировке и символам перевода строк в исходных файлах. Тексты модулей BSL и XML-дескрипторы платформы сохраняются с окончаниями строк CRLF (\r\n).

При кроссплатформенной разработке (Linux/Windows) отсутствие жестких правил приводит к тому, что Git автоматически преобразует CRLF в LF. В результате при выгрузке вся конфигурация помечается как модифицированная (ложный diff на сотни тысяч строк).

В корне репозитория создается конфигурационный файл .gitattributes:

# articles/04-devex-git/artifacts/git/.gitattributes
* text=auto

# Фиксация CRLF для исходных кодов и описаний метаданных 1С
*.bsl       text eol=crlf diff=bsl
*.os        text eol=crlf diff=bsl
*.xml       text eol=crlf diff=xml merge=1c
*.mxl       text eol=crlf
*.txt       text eol=crlf
*.json      text eol=crlf

# Скрипты автоматизации и документация
*.sh        text eol=lf
*.ps1       text eol=crlf
*.md        text eol=lf

# Исключение бинарных контейнеров из текстового анализа и слияния
*.cf        binary -text -diff -merge
*.cfe       binary -text -diff -merge
*.epf       binary -text -diff -merge
*.erf       binary -text -diff -merge
*.dt        binary -text -diff -merge
*.1CD       binary -text -diff -merge

Дополнительно в репозитории размещается .gitignore-1c, исключающий служебные файлы платформы:

# articles/04-devex-git/artifacts/git/.gitignore-1c
.env
*.local.conf
*.log
dump.log
load.log
update.log
*.tmp
*.bak
*.orig
*.1CD
*.cfl
*.pfl
/out/
/bin/
/build/

Шаг 2: Конфигурирование драйвера трехстороннего слияния в .gitconfig

Для связывания командной строки Git и платформы 1С создается файл настроек gitconfig-1c. В нем определяются: 1. Регулярные выражения для отображения имени текущей функции BSL в заголовках изменений (xfuncname); 2. Инструмент mergetool "1cv8", запускающий Конфигуратор в режиме интерактивного объединения с передачей базового предка ($BASE) и вливаемой ветки ($REMOTE).

# articles/04-devex-git/artifacts/git/gitconfig-1c
[core]
    autocrlf = false
    safecrlf = warn

[diff "bsl"]
    xfuncname = "^[ \t]*(Функция|Процедура|Function|Procedure)[ \t]+([a-zA-Zа-яА-Я0-9_]+)"

[diff "xml"]
    xfuncname = "^[ \t]*<([a-zA-Z0-9_:]+)[^>]*name=\"([^\"]+)\""

[merge "1c"]
    name = 1C:Enterprise metadata 3-way merge driver
    driver = git-merge-1c %O %A %B %L %P
    recursive = binary

[mergetool "1cv8"]
    cmd = "\"$V8_EXE_PATH\" DESIGNER /F \"$V8_MERGE_IB_PATH\" /N \"$V8_USER\" /P \"$V8_PASSWORD\" /MergeCfg \"$REMOTE\" -BaseCfg \"$BASE\""
    trustExitCode = false
    keepBackup = false

Подключение конфигурации в локальном репозитории разработчика:

git config --local include.path ../articles/04-devex-git/artifacts/git/gitconfig-1c

Шаг 3: Автоматизация цикла синхронизации «база данных <-> файлы репозитория»

Разработчик не должен вызывать утилиты платформы вручную со сложными наборами параметров. Цикл синхронизации автоматизирован через кроссплатформенные сценарии: - dump-config.sh / dump-config.ps1 - выгрузка изменений из базы данных в Git; - load-config.sh / load-config.ps1 - загрузка изменений из Git в базу данных с обновлением структуры БД.

Листинг сценария декомпозиции (dump-config.sh):

#!/usr/bin/env bash
set -euo pipefail

SRC_DIR="${SRC_DIR:-./src}"
LOG_FILE="${LOG_FILE:-./dump.log}"
V8_BIN="${V8_PATH:-C:/Program Files/1cv8/8.3.24.1667/bin/1cv8.exe}"
V8_CONN="${V8_CONN_STRING:-/F \"${HOME}/1cv8_bases/trade_dev\"}"

echo "[INFO] Выгрузка конфигурации из информационной базы в ${SRC_DIR}..."

"${V8_BIN}" DESIGNER \
    ${V8_CONN} \
    /N "${V8_USER:-Developer}" \
    /DumpConfigToFiles "${SRC_DIR}" -Format Hierarchical \
    /Out "${LOG_FILE}"

# Нормализация окончаний строк и удаление висячих пробелов
find "${SRC_DIR}" -type f \( -name "*.bsl" -o -name "*.xml" \) | while read -r file; do
    sed -i -e 's/[ \t]*\r*$//' -e 's/$/\r/' "${file}"
done

echo "[INFO] Декомпозиция и нормализация успешно завершены."

Листинг сценария загрузки и применения конфигурации (load-config.sh):

#!/usr/bin/env bash
set -euo pipefail

SRC_DIR="${SRC_DIR:-./src}"
LOG_FILE="${LOG_FILE:-./load.log}"
V8_BIN="${V8_PATH:-C:/Program Files/1cv8/8.3.24.1667/bin/1cv8.exe}"
V8_CONN="${V8_CONN_STRING:-/F \"${HOME}/1cv8_bases/trade_dev\"}"

echo "[INFO] [1/2] Загрузка метаданных в конфигурацию..."
"${V8_BIN}" DESIGNER \
    ${V8_CONN} \
    /N "${V8_USER:-Developer}" \
    /LoadConfigFromFiles "${SRC_DIR}" -Format Hierarchical \
    /Out "${LOG_FILE}"

echo "[INFO] [2/2] Применение изменений в конфигурацию базы данных (/UpdateDBCfg)..."
"${V8_BIN}" DESIGNER \
    ${V8_CONN} \
    /N "${V8_USER:-Developer}" \
    /UpdateDBCfg \
    /Out "${LOG_FILE}"

echo "[INFO] База данных успешно синхронизирована с репозиторием."

Шаг 4: Настройка pre-commit хуков контроля целостности

Для предотвращения случайного засорения репозитория бинарными файлами поставки (.cf, .epf) и коммита поврежденных XML-файлов внедрен превентивный перехватчик pre-commit:

#!/usr/bin/env bash
# articles/04-devex-git/artifacts/hooks/pre-commit
set -euo pipefail

STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)
[ -z "${STAGED_FILES}" ] && exit 0

# 1. Блокировка добавления тяжелых монолитных бинарников
for file in ${STAGED_FILES}; do
    case "${file,,}" in
        *.cf|*.cfe|*.epf|*.erf|*.dt|*.1cd)
            if [ "${ALLOW_BINARY_COMMIT:-0}" != "1" ]; then
                echo "[ERROR] Запрещена фиксация бинарных контейнеров 1С: ${file}" >&2
                echo "Декомпозируйте изменения через dump-config." >&2
                exit 1
            fi
            ;;
    esac
done

# 2. Детекция неразрешенных маркеров слияния
for file in ${STAGED_FILES}; do
    case "${file,,}" in
        *.bsl|*.xml|*.mxl)
            if grep -E "^(<<<<<<<|=======|>>>>>>>)" "${file}" >/dev/null 2>&1; then
                echo "[ERROR] Файл содержит неразрешенные маркеры конфликта: ${file}" >&2
                exit 1
            fi
            ;;
    esac
done

# 3. Синтаксическая валидация XML-метаданных
for file in ${STAGED_FILES}; do
    if [[ "${file,,}" == *.xml && -f "${file}" ]]; then
        python -c "import xml.etree.ElementTree as ET, sys; ET.parse(sys.argv[1])" "${file}" >/dev/null 2>&1 || {
            echo "[ERROR] Нарушена структура XML: ${file}" >&2
            exit 1
        }
    fi
done

Шаг 5: Практический сквозной сценарий разрешения конфликта слияния

Рассмотрим практический инцидент в проекте «Торговый контур»: - Инженер направления складской логистики в ветке feature/wh-box-cargo модифицировал экспортную процедуру ОбработатьПроведениеДокумента() в модуле ОбщийМодуль.ПроведениеСервер.bsl и добавил реквизит ОбъемГрузовогоМеста в документ РеализацияТоваровУслуг; - Одновременно инженер направления маркировки в ветке feature/marking-aggregation изменил ту же процедуру ОбработатьПроведениеДокумента() и добавил реквизит КодАгрегированнойУпаковки в тот же документ.

1. Попытка слияния веток:

git checkout feature/wh-box-cargo
git merge origin/feature/marking-aggregation

Git регистрирует два конфликта:

Auto-merging src/CommonModules/ПроведениеСервер/Ext/Module.bsl
CONFLICT (content): Merge conflict in src/CommonModules/ПроведениеСервер/Ext/Module.bsl
Auto-merging src/Documents/РеализацияТоваровУслуг/РеализацияТоваровУслуг.xml
CONFLICT (content): Merge conflict in src/Documents/РеализацияТоваровУслуг/РеализацияТоваровУслуг.xml
Automatic merge failed; fix conflicts and then commit the result.

2. Разрешение конфликта программного кода BSL:

В файле ПроведениеСервер/Ext/Module.bsl конфликт носит текстовый характер. Разработчик открывает трехсторонний diff в редакторе (VS Code / KDiff3) и объединяет алгоритмические блоки:

<<<<<<< HEAD
// Реализация складского учета грузовых мест
Если ЗначениеЗаполнено(СтрокаТаблицы.ОбъемГрузовогоМеста) Тогда
    Движения.ПараметрыГрузовыхМест.ЗаписатьПараметры(СтрокаТаблицы);
КонецЕсли;
=======
// Проверка маркированных упаковок
Если СтрокаТаблицы.МаркированнаяПродукция Тогда
    КонтрольМаркировкиСервер.ВерифицироватьКод(СтрокаТаблицы.КодАгрегированнойУпаковки);
КонецЕсли;
>>>>>>> origin/feature/marking-aggregation

Результирующий согласованный код объединяет обе ветви логики последовательно.

3. Разрешение структурного конфликта метаданных через Конфигуратор:

Редактировать РеализацияТоваровУслуг.xml вручную запрещено. Разработчик запускает:

git mergetool -t 1cv8

Открывается интерфейс сравнения и объединения Конфигуратора 1С: 1. Платформа отображает дерево объектов: документ РеализацияТоваровУслуг; 2. В дереве флажками отмечены одновременно: - Новый реквизит ОбъемГрузовогоМеста (ветка feature/wh-box-cargo); - Новый реквизит КодАгрегированнойУпаковки (ветка feature/marking-aggregation); 3. Инженер подтверждает объединение («Выполнить»). Платформа корректно прописывает оба реквизита в иерархию XML-файла, генерирует уникальные UUID и обновляет ссылки в корневом контейнере метаданных; 4. После сохранения файла разработчик завершает процедуру слияния:

git add src/
git commit -m "merge: объединение функционала грузовых мест и маркировки"
pwsh -File ./articles/04-devex-git/artifacts/scripts/load-config.ps1

Проверка результата и метрики

Внедрение гибридной модели версионирования в проекте «Торговый контур» (1C:ERP 2.5, 8 инженеров) позволило собрать репрезентативную статистику за 6 месяцев промышленной эксплуатации.

Сравнительные метрики инженерных процессов

Динамика метрики Lead Time (время от начала задачи до промышленной эксплуатации):
Недели:    1    2    3    4
До:       [----------------------------------------------] 28 дней (Хранилище)
После:    [---] 3 дня (Git Feature Branches + PR)

Риски и ограничения

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

1. Категорический запрет на ручное строковое слияние XML-метаданных

• Риск: Разрешение конфликтов в файлах метаданных (Configuration.xml, дескрипторы справочников и документов) через стандартные текстовые редакторы без валидации платформой.
• Последствия: Случайное дублирование внутренних тегов, разрыв ссылок на реквизиты, поломка XSD-валидации. Конфигурация перестает собираться через /LoadConfigFromFiles, выдавая нелокализуемые ошибки платформы («Ошибка формата потока», «Файл метаданных поврежден»).
• Регламент: Любое нетривиальное расхождение в файлах *.xml должно разрешаться либо через механизм mergetool 1cv8, либо повторной выгрузкой после интерактивного объединения конфигураций в Конфигураторе.

2. Проблема коллизии внутренних идентификаторов UUID

• Риск: Параллельное создание двух новых объектов метаданных с одинаковыми именами или добавление реквизитов с совпадающими именами в разных ветках.
• Механика проблемы: Хотя платформа генерирует случайные UUID для новых реквизитов, слияние двух веток с параллельно созданными объектами с одинаковым именем приведет к коллизии в пространстве метаданных при попытке сборки конфигурации.
• Регламент: Архитектурное согласование схемы данных до начала кодирования; запуск пре-валидационных синтаксических проверок в CI-конвейере на уникальность имен метаданных.

3. Особенности версионирования управляемых форм

• Риск: Различие в форматах выгрузки форм между версиями платформы.
• Ограничение: В платформе 8.3.24+ управляемые формы выгружаются в виде структурированного XML-файла Form.xml и модуля Module.bsl. Однако при наличии в конфигурации устаревших обычных (толстых) форм или форм с двоичными данными их слияние в Git невозможно - такие формы должны обрабатываться как неделимые бинарные сущности.

Итоги

Практические итоги внедрения гибридной модели версионирования

Внедрение связки «Конфигуратор 1С + Git + CLI-скрипты автоматизации» доказало свою экономическую и инженерную состоятельность на примере высоконагруженного «Торгового контура»: 1. Команда полностью преодолела архитектурный кризис монопольного Хранилища: устранены взаимные блокировки, а время доставки функционала (Lead Time) сократилось с 3–4 недель до 2–3 дней. 2. Организован непрерывный контроль качества: 100% изменений проходят асинхронное предварительное рецензирование (Code Review) в ветках Feature Branches до слияния с основным контуром. 3. Сохранен низкий уровень совокупной стоимости владения (TCO): инженеры сохранили высокую скорость повседневной работы в легковесном Конфигураторе без закупки дорогостоящих рабочих станций под тяжелые Java-среды разработки.

Переход к следующей части цикла

Организация версионирования исходных кодов в Git и внедрение правил трехстороннего слияния закладывают инженерный фундамент для автоматизации контроля качества.

В Части 5 цикла мы перейдем к построению полноценного автоматизированного конвейера:

«Автоматизация тестирования и CI/CD: запуск модульных тестов YAxUnit в эфемерных Docker-контейнерах и построение Quality Gates для конфигураций 1С». Мы рассмотрим развертывание легковесных контейнеров с платформой 1С в Linux, запуск тестовых сценариев без графического интерфейса и настройку правил блокировки некачественных коммитов в GitLab CI.