gifts2017

Контроль версий на cf/cfu

Опубликовал Dima Neumoichev (Ndochp) в раздел Администрирование - Системное

Описание варианта прикручивания полезной практики контроля версий к 1С без использования хранилища.

Контроль версий на cf

Что такое системы контроля версий (далее СКВ) слышали наверное все. Но многие полагают, что это инструмент прежде всего коллективной разработки. А между тем, есть еще одна область, с которой встречался наверное любой 1сник - ветви. И в этой области помощь СКВ так же неоценима. Зачем руками перетаскивать обновление подсистемы, задействованной в десятке родственных, но не одинаковых баз, если можно сказать: перенеси изменения от версии А до Б вот в эту базу.

 

Самые частые места встреч с ветвями для 1сника это:

  1. обновления измененных типовых (ветвь 1с и рабочей базы)
  2. несколько версий одной базы, доработанной слегка по своему под каждое юрлицо (по ветке на базу)
  3. долгий проект, за время написания которого до состояния, которое не стыдно показать пользователям рабочая база уже успевает измениться. (проект и рабочая база)
  4. Некая подсистема, которую надо поднять на самых разных базах, живущая при этом своей жизнью (очень похоже на п. 1, но имеет свои особенности, если эту систему пишем мы сами)
  5. всяческие гибриды вышестоящих пунктов

 

Вообще говоря, штатной системой контроля версий в 1С является хранилище конфигурации, однако его недостатки

  • оно ИМХО малость отстало в плане технологий (монопольное блокирование каждого кусочка и необходимость захвата корня по слишком многим поводам)
  • Отсутствие возможности работать с ветками в рамках одного хранилища
  • Очень небыстрое создание нового хранилища (особенно больших баз)
  • Регулярные падения (после третьего сообщения о том, что к хранилищу не подключиться, так как ему походу хана я прекратил эксперимент с этой технологией)

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

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

 

Базы организуются в три уровня:

  1. Рабочие базы – базы с данными и пользователями. Находятся на поддержке и по возможности в точности совпадают с версией поддержки. Единственный случай отличая – горячие сверхсрочные исправления по живому.
  2. центральная база разработки – всегда совпадает с последней версией поддержки. Просто по построению. Находится на поддержке себя и всего, что только можно (1С, всякие наши и не сильно подсистемы, выделенные в отдельные поставки)
  3. локальные базы разработки – в них происходят все доработки, уровень поддержки совпадает с центральной разработкой

 

А дальше начинаем жить как в старом добром SVN/Git (то есть пытаемся):

«Хранилище» это центральная база разработки плюс папка с версиями

«Метки/Версии» это собственно реквизит версия.

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

«checkout» - загрузка или ДТшника базы разработки (она же кстати тестовая эталонная), или ее ЦФ.

«checkout» - обновление на последнюю поставку

«commit» - обновление на последнюю поставку, затем объединение центральной базы разработки с получившимся локальным CF, затем создание новой поставки. Вообще все изменения центральной базы разработки осуществляются путем сравнения и измененным CF (или локальным или боевым) и созданием новой поставки. Иначе наличие трех по разному измененных баз (вашей локальной, центральной и рабочей) создает слишком много геморроя.

Комментарии к комитам пишутся в отдельный общий текстовый макет, дабы не потеряться. Номер версии – текущие дата-время или дата-номер поставки в дне.

 

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

 

Работа с подсистемами

Под подсистемой я понимаю некую достаточно изолированную сущность, которая используется в разнородных рабочих базах 1С. В моей работе это подключение к электронному архиву и самописная система версионирования.Эти подсистемы применяются во всех базах, на которых ведется учет (бухгалтерия, УПП, ЗУП и пара самописок)

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

  1. Объединяем с постановкой на поддержку и всеми снятыми галками вашу базу с нулевой версией – изменений БД не происходит, а база уже на поддержке.
  2. обновляемся последней поставкой подсистемы. (в сравнении отображается только появившаяся подсистема и немного мусора, на котором мы аккуратно снимаем галки)

 

Появление мусора на втором пункте обусловлено тем, что к сожалению, кроме подсистемы обычно развивается и ее основа, а разработка на прошлой версии основы бывает не всегда возможна. Идеальность случая с типовой 1С конфой, на которую накачена подсистема заключается как раз в возможности создать новую «нулевую» версию с идеально соответствующей основой.

 

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

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Александр Кунташов (kuntashov) 02.12.11 08:01
Интересный и в общем-то логичный подход.

Вопросы:

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

2. Автоматизировали ли вы как-то описанные операции (чекаут, коммит) или все делаете вручную?

3. Сколько проектов (разных хранилищ) вы используете по такой технологии и в течении какого времени? Какой самый большой cf-ник? Самый длинный changelog сколько записей насчитывает?

4. Вы один работаете по такой методике или в команде? Сколько человек в команде?

И вопрос ко всем, кто присоединится к дискуссии: какой способ контроля версий вы используете на своих проектах (инструмент, методику)?
2. Dima Neumoichev (Ndochp) 02.12.11 10:21
1. С хранилищем сравнивать не могу, реально долго с ним не работал. С отсутствием чего-бы то ни было ускорение естественно есть.
2. Пока не особенно напрягает делать руками, для большинства задач делается два один-два чекаута (на начало, на конец, если надо) и один комит
3. Одна пилотная база год, 110 версий и еще 4 полгода, когда пилот был признан успешным. Самая большая - УПП, 120 метров ЦФ. Для ускорения небольших задач порой выбрасывается этап с локальной базой и все-таки ведется работа сразу на центральной. Но если кому-то надо залить готовые изменения в ствол, когда тот изменен, то работающий на центре изгоняется, сохраняется текущий ЦФ (и из него строится таки локальная база), происходит откат центра на последнюю поставку и дальше все по схеме. Помогает или мешает такое отступление - не ясно. На небольших базах - однозначный минус. На УПП мнения в коллективе разделились.
4. Для разных баз по разному - оперативные самописки имеют основных ответственных, так что можно сказать по разработчику на базу, а над регламентными базами работаем вчетвером.
3. Александр Кунташов (kuntashov) 02.12.11 10:31
(2) Спасибо за развернутые ответы.
По п. 2. правильно я понимаю, что одним коммитом в "хранилище" помещается сразу куча закрытых задач? Т.е. "1 коммит = много записей в истории изменений (changelog)"?
4. Dima Neumoichev (Ndochp) 02.12.11 10:43
(3) kuntashov,
Одним комитом кладется или одна большая задача, или куча мелочей, сделанных за день-два одним человеком.
5. Сергей Карташев (Elisy) 07.12.11 07:42
Тема интересная и наталкивает на мысль, что нужны средства разработки альтернативной сериализации/десериализации конфигураций в удобочитаемыую структуру файлов на диске. Такой подход должен во многом упростить предложенный в статье метод.
6. Константин Бессмертный (byte.mdfab) 07.12.11 11:34
(5) Были бы такие средства - все было бы намного проще. Да где ж их взять то?
7. Сергей Карташев (Elisy) 07.12.11 11:53
(6) Сами эти средства точно не появятся, но даже сейчас есть заготовки на чтение.
http://infostart.ru/public/97194/
http://infostart.ru/public/80737/
У нас была идея расширить последнюю разработку в этом направлении, но ценителей СВН среди 1С-ников не очень много. Мало кто захочет видеть платное решение, а бесплатно не получится делать, так как проект очень ресурсоемкий.
8. Константин Бессмертный (byte.mdfab) 07.12.11 12:08
Без сборки cf из исходников толку от разработки мало. А насчет ценителей свн - это вы зря. Есть они. Просто все будет зависеть от размера платы.
9. Андрей Д. (bambr1975) 07.12.11 12:31
(7) Я, конечно, не "ценитель" СВН, но теоретически считаю эту задачу более-менее решаемой. Если говорить о GIT, то мне интересно, есть ли заготовки по вызову скриптов по управлению git-ом из 1с. Если есть - мне бы было интересно немного покопать в этом направлении.
10. Константин Бессмертный (byte.mdfab) 07.12.11 12:38
(9) Есть Снегопат в котором можно создавать любые скрипты.
11. Игорь Steelvan (Steelvan) 07.12.11 12:54
Не совсем понятно, это какая-то программа ?
12. Dima Neumoichev (Ndochp) 07.12.11 13:09
(11) Да, стартер/обертка для конфигуратора, добавляющая к тому ряд полезных фич и интерфейс для собственных скриптов расширения. (к сожалению платная, есть демка, чем ограничена - не понял. походу просто в развитии)
13. Константин Бессмертный (byte.mdfab) 07.12.11 13:22
(12) Демка отстает на несколько версий а также отсутствует обновление скриптов. ИМХО на сегодня уже вполне юзабельно. Как только появится удобная навигация - тут же куплю, благо цена вполне приемлема.
14. Mariya Cherkasskaya (mcher) 08.12.11 04:17
Спасибо. Интересно было почитать.
16. Сергей Карташев (Elisy) 06.01.12 12:36
(7)(8) В продолжение диалога - развили свои наработки до прототипа. Опубликовано описание здесь с примером:
http://www.richmedia.us/post/2012/01/06/cfproject-ctp.aspx
На Инфостарт опубликовал тоже, но жду прохождения модерации. Как будет одобрено, скину ссылку.
17. Сергей Карташев (Elisy) 06.01.12 13:07
18. bsi bsi (bsi) 23.02.12 23:50
19. Dima Neumoichev (Ndochp) 26.02.12 10:27
Не аналогичная, а скорее дополняющая. Там про удобное сравнение бинарных файлов обработок, уже лежащих в системе контроля версий. А в (17) про конфу, у меня вообще про то, как жить без использования "взрослых" систем контроля.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа