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

01.12.11

База данных - Инструменты администратора БД

Описание варианта прикручивания полезной практики контроля версий к 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С конфой, на которую накачена подсистема заключается как раз в возможности создать новую «нулевую» версию с идеально соответствующей основой.

 

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

См. также

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

12000 руб.

06.12.2023    2976    13    1    

34

SALE! 20%

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 8000 руб.

10.11.2023    3531    11    1    

34

SALE! 30%

PowerTools

Инструментарий разработчика Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

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

3600 2520 руб.

14.01.2013    177744    1073    0    

849

Ускоренное проведение документов (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    27378    79    146    

59

Система хранения присоединенных файлов в томах на диске

Инструменты администратора БД Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием Платные (руб)

Конфигурация Комплексная автоматизация 1.1 (и УПП 1.3 тоже) хранит файлы и изображения в справочнике Хранилище дополнительной информации в реквизите Хранилище типа ХранилищеЗначений. Та же история с ВложениямиЭлектроннойПочты. Но при этом присоединенные файлы в Электронном документообороте хранит в томах на диске. Эта доработка позволяет использовать стандартный механизм хранения файлов, изображений и вложений электронных писем в томах на диске. При этом можно разделить тома хранения по объектам конфигурации.

4200 руб.

10.11.2015    61317    88    59    

73

"Менеджер потоков 2.1": УПП: "Восстановление партий"

Инструменты администратора БД Платформа 1С v8.3 1С:Управление производственным предприятием Россия Бухгалтерский учет Управленческий учет Платные (руб)

Как оптимизировать то, что, считалось, не поддается оптимизации? Как повысить доступность базы данных? Как проводить самую «времяемкую» операцию не по паре раз в неделю, а по несколько раз в день*? Ответ есть!

20000 руб.

12.09.2019    11746    5    9    

7

Брандмауэр для сервера 1С Предприятие 8 - внешнее управление сеансами

Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Управление возможностью начала и возобновления сеансов пользователей по различным условиям, ограничение общего числа возможных сеансов для работы с информационной базой, резервирование возможности работы с информационной базой определенных польззователей, запрет запуска нескольких сеансов для пользователя, журнализация событий начала (возобновления) и завершения (гибернации) сеансов, ведение списка активных сеансов для информационных баз кластера серверов

3600 руб.

06.02.2017    31110    31    18    

47

Хранилище файлов на SQL

Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Управленческий учет Платные (руб)

Привязка файлов / сканов к объектам 1С с сохранением их на SQL-сервере

12000 руб.

09.10.2019    10984    5    8    

9
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kuntashov 449 02.12.11 08:01 Сейчас в теме
Интересный и в общем-то логичный подход.

Вопросы:

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

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

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

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

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