Контроль версий на cf
Что такое системы контроля версий (далее СКВ) слышали наверное все. Но многие полагают, что это инструмент прежде всего коллективной разработки. А между тем, есть еще одна область, с которой встречался наверное любой 1сник - ветви. И в этой области помощь СКВ так же неоценима. Зачем руками перетаскивать обновление подсистемы, задействованной в десятке родственных, но не одинаковых баз, если можно сказать: перенеси изменения от версии А до Б вот в эту базу.
Самые частые места встреч с ветвями для 1сника это:
- обновления измененных типовых (ветвь 1с и рабочей базы)
- несколько версий одной базы, доработанной слегка по своему под каждое юрлицо (по ветке на базу)
- долгий проект, за время написания которого до состояния, которое не стыдно показать пользователям рабочая база уже успевает измениться. (проект и рабочая база)
- Некая подсистема, которую надо поднять на самых разных базах, живущая при этом своей жизнью (очень похоже на п. 1, но имеет свои особенности, если эту систему пишем мы сами)
- всяческие гибриды вышестоящих пунктов
Вообще говоря, штатной системой контроля версий в 1С является хранилище конфигурации, однако его недостатки
- оно ИМХО малость отстало в плане технологий (монопольное блокирование каждого кусочка и необходимость захвата корня по слишком многим поводам)
- Отсутствие возможности работать с ветками в рамках одного хранилища
- Очень небыстрое создание нового хранилища (особенно больших баз)
- Регулярные падения (после третьего сообщения о том, что к хранилищу не подключиться, так как ему походу хана я прекратил эксперимент с этой технологией)
Не позволяют испытывать удовольствия от работы с ним, или я просто не умею готовить эту штуку.
Однако проблемы с ветками от отсутствия удобного штатного хранилища никуда не исчезают. Больше того имеется другое штатное средство для случая номер раз встречи с ними – поставка. Взяв за основу обновление типовой при помощи поставки я начал натягивать эту технику на все остальные случаи, и в итоге получилась следующая технология работы, состоящая из развернутых баз, хранилища версий и набора алгоритмов.
Базы организуются в три уровня:
- Рабочие базы – базы с данными и пользователями. Находятся на поддержке и по возможности в точности совпадают с версией поддержки. Единственный случай отличая – горячие сверхсрочные исправления по живому.
- центральная база разработки – всегда совпадает с последней версией поддержки. Просто по построению. Находится на поддержке себя и всего, что только можно (1С, всякие наши и не сильно подсистемы, выделенные в отдельные поставки)
- локальные базы разработки – в них происходят все доработки, уровень поддержки совпадает с центральной разработкой
А дальше начинаем жить как в старом добром SVN/Git (то есть пытаемся):
«Хранилище» это центральная база разработки плюс папка с версиями
«Метки/Версии» это собственно реквизит версия.
«Параллельные ветки» храним в наименовании конфигурации. Чем меньше они времени живут, тем лучше. Три-четыре поддержки УПП раздувают CF до немерянных размеров. Если предполагается долгая жизнь параллельных веток, то лучше устроить «пирамидку» то есть выбираем базовую ветвь, основанную на конфигурации 1С например, а центральную базу ответвления уже ставим на поддержку базовой ветви, и снимаем поддержку 1С.
«checkout» - загрузка или ДТшника базы разработки (она же кстати тестовая эталонная), или ее ЦФ.
«checkout» - обновление на последнюю поставку
«commit» - обновление на последнюю поставку, затем объединение центральной базы разработки с получившимся локальным CF, затем создание новой поставки. Вообще все изменения центральной базы разработки осуществляются путем сравнения и измененным CF (или локальным или боевым) и созданием новой поставки. Иначе наличие трех по разному измененных баз (вашей локальной, центральной и рабочей) создает слишком много геморроя.
Комментарии к комитам пишутся в отдельный общий текстовый макет, дабы не потеряться. Номер версии – текущие дата-время или дата-номер поставки в дне.
Прискорбный в других случаях запрет запуска нескольких конфигураторов на одну базу естественным образом обеспечивает единую очередность версий при групповой разработке. Атомарность коммита поддерживается тоже епстественным образом.
Работа с подсистемами
Под подсистемой я понимаю некую достаточно изолированную сущность, которая используется в разнородных рабочих базах 1С. В моей работе это подключение к электронному архиву и самописная система версионирования.Эти подсистемы применяются во всех базах, на которых ведется учет (бухгалтерия, УПП, ЗУП и пара самописок)
В качестве основы для подсистемы выбирается самая простая и стабильная база из тех, где она будет установлена идеально, если у вас среди рабочих есть типовая база 1С, на которой единственное изменение эта подсистема. Потом создается «нулевая» версия подсистемы: основа, в которой этой подсистемы нет вообще. После чего спокойно и неспешно подсистема начинает жить своей жизнью (в своей поставке, на которой должны стоять все базы разработки, использующие эту подсистему). Когда надо установить подсистему на базу, на которой ее никогда не было, то делается следующая вещь:
- Объединяем с постановкой на поддержку и всеми снятыми галками вашу базу с нулевой версией – изменений БД не происходит, а база уже на поддержке.
- обновляемся последней поставкой подсистемы. (в сравнении отображается только появившаяся подсистема и немного мусора, на котором мы аккуратно снимаем галки)
Появление мусора на втором пункте обусловлено тем, что к сожалению, кроме подсистемы обычно развивается и ее основа, а разработка на прошлой версии основы бывает не всегда возможна. Идеальность случая с типовой 1С конфой, на которую накачена подсистема заключается как раз в возможности создать новую «нулевую» версию с идеально соответствующей основой.
Засим спасибо за внимание, буду рад конструктивным комментам, которые позволят улучшить статью, а то и технологию.
