Консалтинг и внедрение

Внедрение git в команде 1С: от хранилища конфигурации до сборки в GitLab

Настроим процесс, в котором программисты 1С работают в ветках, код проходит ревью, а сборка и проверки идут сами на каждый merge request. Без перехода на EDT: конфигуратор остаётся, хранилище можно отпустить постепенно.

WhatsApp orqali yozish Bepul ekspress-audit olish

50+ наших внешних обработок и расширений живут в git исходниками XML

700 000 - 1 000 000 ₸ narxi · аудит, репозиторий, правила веток и сборка в CI для одной конфигурации, без налогов сопровождение перехода команды и другие конфигурации оцениваем на аудите и добавляем единым счётом

Tanish muammolarmi?

Объект захвачен, команда ждёт

Один программист держит в хранилище общий модуль или документ, второй ждёт, пока его отпустят, или правит в обход и потом переносит руками.

Одна линия разработки и нет ревью

Срочную правку негде отделить от недоделанной доработки. Код попадает в рабочую базу без второго взгляда, а откатить одну задачу из хранилища нельзя.

Расширения и внешние обработки вне истории

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

Про git слышали, начинать страшно

По статьям переход занимает недели, ConfigDumpInfo.xml конфликтует при каждом слиянии, а после чистого слияния база может не загрузиться.

Кому это нужно

Команде от трёх программистов 1С, которые дорабатывают одну конфигурацию и упираются в хранилище: захваты объектов, очередь на помещение, срочная правка смешивается с недоделанной задачей, ревью кода нет. Чаще всего это ИТ-отдел компании с типовой УТ, ERP или Бухгалтерией и заметным слоем своих доработок.

Если программист один, проект такого масштаба не нужен. Выгрузки в XML и пары скриптов ему хватит, это мы бесплатно подскажем в WhatsApp.

Что ломается при переходе и что мы с этим делаем

Инструменты для git в 1С бесплатные и давно работают. Затыки начинаются, когда их собирают в процесс для живой команды. Их список известен заранее, поэтому правила под каждый ставим до первого конфликта.

Что ломается	Почему	Что делаем
ConfigDumpInfo.xml конфликтует при каждом слиянии	служебный файл выгрузки, у каждого программиста свой	на аудите решаем, хранить его или пересобирать хуком: от этого зависит выгрузка только изменённого
Form.xml при параллельной правке одной формы	идентификаторы элементов у двух веток совпадают	правило “одна форма в одной ветке” и хук, который ловит дубли индексов
Выгрузки от разных программистов не совпадают	формат выгрузки меняется с версией платформы	одна версия платформы для выгрузки у всей команды, CI это проверяет
git слил без конфликта, а база не загружается	git сливает строки, 1С проверяет объект целиком	CI загружает ветку в тестовую базу до слияния в основную
Выгрузка большая, загрузка долгая	у крупных конфигураций XML весит больше гигабайта	частичная выгрузка и загрузка только изменённых файлов

Что у нас за плечами

Свою разработку мы ведём в git без хранилища и без EDT. Больше пятидесяти внешних обработок и несколько расширений лежат исходниками XML, обработка собирается из файлов скриптом, история каждой правки видна построчно. Как мы храним и описываем внешние обработки, разобрано в статье про хранение внешних обработок 1С.

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

На каких инструментах

Всё на открытых проектах сообщества 1С, лицензий покупать не придётся:

gitsync переносит историю хранилища в git на переходный период;
vanessa-runner собирает cf, cfe и epf и загружает ветку в базу из скриптов;
BSL Language Server проверяет код на каждый merge request;
precommit4onec разбирает внешние обработки в исходники при коммите и чинит индексы форм;
YAxUnit подключаем, если команда готова писать тесты.

Своего закрытого софта не ставим, процесс остаётся у вас и работает без нас. GitLab или GitHub выбираете вы. Если код нельзя выносить наружу, работаем с GitLab на вашем сервере.

Для CI нужна тестовая база, близкая к рабочей. Если её нет или она отстала, пригодится наш инструмент для тестовой базы из бэкапа. А совместимость внешних обработок с новым релизом типовой отдельно проверяет бесплатная обработка, про её устройство есть статья.

Что не делаем

Миграцию на 1С:EDT под ключ. Весь процесс строим на конфигураторе и XML-выгрузке. EDT под крупную конфигурацию просит 16 ГБ памяти и долгие сборки, и большинство команд по этой причине остаются в конфигураторе.
Тесты за команду. Фреймворк подключим и поставим его запуск в CI, а покрытие тестами пишут ваши программисты или оцениваем отдельно.
Обновление рабочей базы из ветки без человека. Обновление рабочей базы требует остановки и прав, поэтому кнопку оставляем у ответственного. CI готовит сборку и проверяет её на тестовой базе.

Сроки и цена

Аудит, репозиторий с синхронизацией хранилища, правила веток и сборка в CI для одной конфигурации занимают 5-7 рабочих дней. Это вход по нашей общей схеме: экспресс-аудит бесплатный, дальше платная работа по вилке в шапке страницы.

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

Siz nima olasiz

Репозиторий в GitLab или GitHub с историей конфигурации, расширений и внешних обработок
Синхронизация хранилища с git на переходный период: каждое помещение в хранилище становится коммитом
Правила веток, ревью и слияния, записанные для вашей команды
Хуки и .gitignore против типовых конфликтов выгрузки: ConfigDumpInfo.xml, индексы элементов форм
Сборка cf, cfe и epf и проверка кода BSL Language Server на каждый merge request
Загрузка ветки в тестовую базу в CI: ошибку слияния видно до рабочей базы
План выхода из хранилища или правила гибрида, если хранилище остаётся

Biz qanday ishlaymiz

01
Аудит процесса и хранилища

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

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

Договариваемся о модели веток и ревью, ставим хуки и .gitignore, фиксируем одну версию платформы для выгрузки.
04
Сборка и проверки в CI

GitLab CI или GitHub Actions собирает cf, cfe и epf, гоняет BSL Language Server и загружает ветку в тестовую базу.
05
Перенос команды

Первые задачи команда ведёт в ветках вместе с нами. Первые конфликты и первые слияния разбираем на живых доработках.
06
Отказ от хранилища или гибрид

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

Как это устроено у нас самих

Больше 50 внешних обработок лежат в git исходниками XML, у каждой своя история по строкам
750+ коммитов по обработкам без хранилища и без EDT
Расширения под три типовые конфигурации в том же репозитории
Обработка собирается из XML скриптом, руками в конфигураторе её никто не собирает

1C tizimingiz uchun bepul ekspress-audit

1-2 kun ichida bazangizni ko'rib chiqamiz, unumdorlik qayerda yo'qolayotganini topamiz va nima qilish kerakligini aytamiz. Majburiyatsiz.

Bepul ekspress-audit olish

Ko'p so'raladigan savollar

Обязательно ли переходить на 1С:EDT, чтобы работать с git?

Нет. Конфигуратор умеет выгружать конфигурацию в XML и загружать обратно, на этом и строим процесс. Программисты остаются в привычном конфигураторе, git хранит выгрузку, CI собирает cf, cfe и epf. EDT под крупную конфигурацию просит много памяти и долго собирает проект, поэтому большинство команд его не берут.

Можно ли оставить хранилище конфигурации и просто добавить git?

Можно, на переходный период так и делаем. gitsync переносит каждое помещение в хранилище в коммит git, команда работает по-старому, а история, ревью и сборка уже идут в GitLab или GitHub. Затык в том, что гибрид легко остаётся навсегда. Поэтому сразу договариваемся, при каком условии хранилище выключаем: например, месяц слияний без ручной починки.

Что делать с ConfigDumpInfo.xml, который конфликтует при каждом слиянии?

Это служебный файл выгрузки, и у каждого программиста он свой. Частый совет убрать его в .gitignore снимает конфликт, но ломает выгрузку только изменённого: по этому файлу конфигуратор понимает, какие объекты поменялись с прошлой выгрузки, и без него каждый раз выгружает всё. Какой вариант подходит вам, хранить файл или пересобирать хуком после слияния, решаем на аудите по размеру конфигурации и тому, как команда загружает изменения.

git слил ветки без конфликта, а конфигурация не загружается. Почему так бывает?

git сравнивает строки текста, а 1С при загрузке проверяет объект целиком. Две ветки могут добавить элементы формы с одинаковым идентификатором или поменять один объект так, что по строкам конфликта нет, а по смыслу он есть. Лечится проверкой в CI: перед слиянием в основную ветку сборка загружается в тестовую базу, и ошибку видно до того, как её получит вся команда.

У программистов разные версии платформы. Это мешает?

Да. Формат XML-выгрузки меняется с версией платформы, и выгрузки разных версий дают в git лишние изменения или не загружаются друг у друга. Фиксируем одну версию для выгрузки у всей команды и ставим в CI проверку версии, чтобы расхождение ловилось на merge request, а не через неделю.

GitLab или GitHub, и можно ли без облака?

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