Преамбула.
Описанная в статье методика не претендует на звание полноценной системы контроля версий. При написании статьи преследовались две цели:
- анализ существующих методов контроля изменений внешних обработок, описание их особенностей;
- описание альтернативного способа контроля изменений.
Существующие инструменты контроля версий внешних обработок.
Я классифицировал существующие системы контроля версий внешних обработок по двум признакам — место хранения версий (т.е. сам инструмент контроля) и вид хранения внешних обработок — бинарный/текстовый:
Место хранения версий | Тип хранения | Примечание | Примеры инструментов |
1. Под одной из существующих систем контроля версий (git, mercurial, svn и т.д.). |
Бинарный |
Т.к. данные хранятся в бинарном виде, то для сравнения используется внешний инструмент сравнения. Из минусов подобного подхода можно отметить хранение данных в бинарном виде, в результате чего часть преимуществ системы контроля версий теряется. |
|
2. Под одной из существующих систем контроля версий (git, mercurial, svn и т.д.). |
Бинарный и текстовый |
Для хранения используются те же системы контроля версий, что и в пункте 1, но перед сохранением изменений (коммитом) происходит парсинг и конвертация бинарного файла обработки в обычные текстовые файлы. Таким путем идут авторы публикации V8Commit. Плюсы — полноценное использование git’а из-за хранения исходников в текстовом виде. Минусы — отсутствие обратной «сборки» обработки (как следствие — нельзя внести изменения в модуль объекта сторонними средствами, смержить изменения с помощью утилиты сравнения и т.д.), много зависимостей (используется V8Reader + отдельная служебная база 1С + обвязка всего этого в виде скриптов). По-моему мнению этот инструмент наиболее приближен к полноценному контролю версий внешних обработок из всех. |
|
3. В отдельном типовом хранилище конфигураций. |
Бинарный (внутренний формат хранилища конфигурации 1С) |
Создается новое пустое хранилище конфигурации, каждая новая обработка добавляется как встроенная в соответствующую ветвь конфигурации. Плюсы: привычный инструмент разработчика 1С. Минусы: если в конфигурации, где хранятся внешние обработки, нет справочников, которые используются в реквизитах обработки, то тип данных реквизитов будет выставлен по-умолчанию, т.е. «Строка» (фактически это означает, что если в ваших обработках есть ссылочные типы, то данный способ не подходит). Также, можно отметить, что для добавления новой обработки необходим исключительный захват корня конфигурации (как следствие — невозможность одновременного добавления новых обработок различными пользователями). |
Альтернативный способ контроля версий.
Ниже речь пойдет об альтернативном варианте хранения версий внешних обработок, а именно о хранении версий обработок в самой информационной базе.
Практически во всех типовых конфигурациях существует подсистема версионирования объектов. Если включить данный механизм для справочника внешних обработок, то мы получим историю изменений каждой обработки во времени (в разрезе даты изменения, номера и автора). Также, в блоке версионирования будет храниться сам бинарный файл внешней обработки. Это означает, что при необходимости мы можем провести сравнение двух версий внешней обработки.
Приложенная к публикации обработка написана на обычных формах и протестирована на конфигурации УПП 1.3.56.1, но данную методику можно реализовать на любой конфигурации, содержащей в себе подсистему версионирования. Для сравнение двух версий обработок использовалась программа V8Viewer.
Плюсами данного подхода являются простота внедрения и использования (достаточно включить механизм версионирования для справочника внешних обработок). Из минусов — все тоже бинарное хранение данных и отсутствие инструментов для параллельной разработки (одновременное редактирование одного объекта, ветвление и т.д.).
Как этим пользоваться.
Перед использованием обработки следует произвести следующие настройки:
- Для сравнения внешних обработок используется утилита V8 Viewer, поэтому для корректного сравнения версий дополнительных обработок следует установить и настроить данный инструмент (подробности данной операции описаны в публикации v8Viewer).
- Включить версионирование для справочника внешних обработок:
- Указать путь к обработке сравнения (по нажатию кнопки «Настройки»):
Принципиально на этом этапе у нас уже готова система контроля версий — теперь любое изменение внешней обработки в информационной базе будет сохраняться в разрезе версии обработки, даты изменения и автора. Чтобы сравнить две версии внешней обработки следует выбрать в основном окне внешнюю обработку из одноименного справочника, указать две версии и нажать «Сравнить версии»:
В результате будет выведено окно программы V8Viewer, где будет возможность сравнить две версии:
Альтернативным вариантом использования является выгрузка версии в файл (это может потребоваться для восстановления старой версии обработки). Для выполнения данной операции нужно выбрать версию и нажать «Выгрузить версию».
Как это может помочь.
- Предложенная методика даст ответы на вопросы когда, кто и что именно менял в каждой версии внешней обработки (с возможностью сравнить код обработок, макеты и т.д.).
- Обработка позволит выгрузить произвольную версию обработки. Это позволит при необходимости «откатиться» на старую версию, если новая содержит ошибки или оказалась битой (такое бывает, когда по ошибке обработка затирается совершенно другой).
Скажите,а где настройка версифицирования в Зарплата и Управление Персоналом, редакция 2.5 (2.5.87.1)
В редакцию ЗиУП 2.5 механизм версионирования не встроен. Насколько мне известно, данная подсистема была добавлена в третьей редакции данной конфигурации.
В тексте публикации заявлена поддержка обработки только для конфигурации «Управление производственным предприятием» редакции 1.3. Для всех остальных конфигураций нужно смотреть индивидуально.
Как автор V8Viewer хочу сказать спасибо за то, что пользуетесь.
Единственно, не понял до конца — каковы преимущества предлагаемого подхода по сравнению с простым хранением обработок в git и управления всем этим с помощью Tortoise? Т.е. написана конфигурация, которая заменяет собой стандартные системы контроля? А зачем?
Прошу не воспринимать, как критику, я просто, возможно, не уловил каких-то моментов.
(0) Не хочу обижать автора v8Viewer, тем более, что работаем вместе 🙂 , но почему все-таки не v8Reader ?
1. v8reader все-таки помощнее при анализе модулей и особенно форм
2. вызов v8reader через командную строку 1С и спец.базы 1С не намного сложнее v8viewer.
Например, я постоянно пользуюсь v8reader для сравнения обработок через ком. строку (один хоткей в Фар) и через Гит (одна настройка в Source и Черепахе)
Ну и жду ответа на вопрос Андрея в (3)
(3) Evil Beaver, спасибо за проявленный интерес. К объективной критике отношусь положительно.
Возможно не совсем корректно описал механизм работы данной обработки. Отдельная конфигурация не создавалась — для хранения версий внешних обработок используется та же самая конфигурация, где эти обработки потом применяются (т.е. в нашем случае это УПП редакции 1.3). Плюсы у такого подхода исключительно в его простоте — включается версионирование для внешних обработок (пункт 3 в публикации) и изменения каждой версии начинают сохраняться.
Я не рассматриваю данную обработку как полноценную систему контроля версий — об этом я упомянул в начале статьи. Это скорее первый шаг на пути к такой системе, который позволяет быстро запустить контроль без установки стандартной системы контроля версий (git, mercurial, svn и т.д.) и без обучения остальных разработчиков навыкам работы с ней. В таблице сравнения я описал какой вариант лично для себя считаю предпочтительным — это V8Commit. Мы на пути к нему 🙂
(4) artbear,
Отличный и закономерный вопрос.
Сразу скажу, что для внутренних нужд мы используем как раз v8reader с незначительными изменениями (в коде обработки можно увидеть, что список инструментов сравнения можно расширить).
Причина по которой текущая публикация заточена под v8Viewer в том, что у v8reader нет простого способа запуска сравнения из текущего сеанса. Т.е. действительно можно запустить сравнение в отдельном сеансе через параметры командной строки, но нет возможности в текущем сеансе подключить обработку и вызвать, скажем экспортный метод Сравнить(ПутьКФайлу1, ПутьКФайлу2). Посчитал, что запуск отдельной информационной базы в данном случае будет избыточным.
(6) ИМХО запуск процесса v8Commit и запуск процесса 1С (для v8Reader) ничем не отличается.
Повторюсь — я постоянно пользуюсь сравнением внешних файлов 1С через v8Reader и мои «хотелки» постоянно растут и оперативно дорабатываются 🙂
Кстати, при работе с Гит в проекте precommit1C, который основан на v8reader, есть возможность сборки обработки из исходников текстов.
Твою задачуhttps://github.com/xDrivenDevelopment/v8Reader/issues/27 (программный запуск обработки из текущего сеанса) автор v8Reader реализует в скором времени 🙂
(6) Интересно, какие незначительные изменения v8Reader вы сделали?
(7) artbear,
В части запуска отдельной базы, либо отдельного приложения — тут уже разговор в плоскость вкусов переходит 🙂 Я принципиально ничего против этих двух вариантов не имею. В части precommit1C и сборки обработки — здорово. Я слежу за развитием данного проекта, но видимо упустил этот момент. В части программного запуска v8reader — супер, ждем-с 🙂
(8) artbear,
К своему большому стыду сделал весьма костыльно. А именно — завел у обработки строковый реквизит, куда извне передаю параметры сравнения. Соответственно при открытии формы обработки у данного параметра настроен больший приоритет, чем у параметров запуска сеанса. Других изменений не было. Пробовал проанализировать форму обработки на предмет точечных изменений там, но показалось, что придется внести значительный объем доработок. Это технический долг, который я отдам, когда в v8reader появится возможность программного запуска сравнения 🙂
Спасибо! По моему очень удобно для начала. Попробую убедить коллег.
(11) Alien_job, рад, что смог помочь 🙂
Можно для начала включить версионирование для справочника внешних обработок, а потом публично на примерах объяснить как это может быть использовано. Если данное предложение встретит отторжение в коллективе, то вы сможете использовать предложенный подход как минимум для себя.
Есть еще такая штука:http://infostart.ru/public/181018/
https://github.com/ilovb/1c-toolkit
https://github.com/ilovb/1c-toolkit/releases
На гитхабе:
Релиз тут:
Пользуемся утилитой tsvn_hook_pre-commit давно и исправно 🙂
По опыту могу сказать, что потребность в «сборке» так и не возникла ни разу.
(13) Потребность в сборке бывает, поверьте.
Например, когда используете генераторы кода.
(13) ilov_boris,
спасибо за обратную связь — добавил ваш инструмент в обзорную таблицу в текущей публикации.
В части сборки сам с такой необходимостью еще не сталкивался, но навскидку кажется, что это может быть удобно. Например, в случае внесения незначительных поправок в код на машине, где отсутствует платформа, либо для объединения обработок 1С сторонними средствами (WinMerge, Meld и т.д.). (14) Pr-Mex) также привел пример, где это может быть полезно. Допускаю, что такая функциональность нужна далеко не всем.
(15) конечно сборка нужна. Например затер коллега мои наработки своими. Это можно увидеть сравнив версии обработок вашим инструментом. Было бы проще сразу смержить их и сохранить новую версию чем выгружать обе версии, мержить в конфигураторе, загружать в справочник.
(13) Как только я начинал хранить обработки в git — а это было уже давно у меня сразу возникала необходимость сборок. Причем с наложением патчей.
Сценариев на практике возникало основных 2:
1. когда ядро обработки или подсистемы остается тем же, но необходимо делать несколько сборок — под разные версии платформы чаще всего. Чтобы не плодить кода в формате
делается просто сборки ядра + патчи для версии.
2. когда необходимо было делать сборки под разные типовые конфигурации — ядро обработки сохраняется, меняется только код вызова типовых функции.
Когда я говорю патч — я имею ввидуhttps://ru.wikipedia.org/wiki/Patch_(UNIX)