Версионирование в 1С

• Добавить свою публикацию

для этого требуется регистрация

YPermitin 08.04.2014 +1

Назначение

В типовой конфигурации «Управление производственным предприятием» версии 1.3 имеется функционал версионирования объектов, позволяющий отслеживать изменение справочников и документов во времени. Изменения отслеживаются как для реквизитов, так и для табличных частей.

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

Как мы видим, в двух версиях документа отличаются только дата. Далее внутреннее устройство универсального механизма версионирования объектов.

Внутреннее устройство

Выполним краткое описание механизмы версионирования. Рассматриваемые объекты входят в подсистему «Версионирование объектов».

Начнем с настроек и закончим таблицой хранения версий.

Настройки

Все настройки выполняются с помощью следующих объектов:

1. Константа «Использовать версионирование объектов»
2. Рег. сведений «Настройка версионирования объектов»
3. Перечисление «Варианты версионирования объектов»

Константа имеет булев тип. Если она отключена, то вне зависимости от настроек версионирования для отдельных объектов — версионирование не будет выполняться. В регистре сведений «Настройки версионирования объектов» выполняется настройка для отдельных видов справочников и документов. Есть три вида настройки для версионирования для объекта, заданные в соответствующем перечислении. Для справочников вариант «Версионировать при проведении» не доступен.

Измерение «Тип объекта» имеет строковый тип, в котором хранится имя объекта метаданных, для которого устанавливается вариант версионирования.

В режиме 1С:Предприятие настройки версионирования объектов включаются через формы редактирования настроек программы:

Нажав на кнопку «Настройка версионирования объектов» вы попадете в форму редактирования регистра сведений для установки параметров для каждого отдельного объекта:

Все вышеописанные объекты и составляют основу для настройки версионирования объектов в УПП 1.3. Рассмотрим как эти настройки используются в дальнейшем.

Использование настроек

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

Сейчас обратим внимание на подписку на события «ВерсионированиеОбъектов_ПриЗаписиОбъекта». Событие подписки выполняется для любых объектов справочников и документов. Обработчик подписки содержит следующий алгоритм:

Процедура МеханизмВерсионированияОбъектов_ПриЗаписиОбъекта(Источник, Отказ) Экспорт Перем ЧислоВерсийОбъекта; // Проверка нужно ли записывать версию объекта в соответствии // с настройками Если ОбъектВерсионируется(Источник, ЧислоВерсийОбъекта) Тогда ИмяВременногоФайла = ПолучитьИмяВременногоФайла(); ЗаписьXML = Новый ЗаписьXML; ЗаписьXML.ОткрытьФайл(ИмяВременногоФайла); ЗаписьXML.ЗаписатьОбъявлениеXML(); ЗаписатьXML(ЗаписьXML, Источник, НазначениеТипаXML.Явное); ЗаписьXML.Закрыть(); ДвоичныеДанные = Новый ДвоичныеДанные(ИмяВременногоФайла); ХранилищеДанных = Новый ХранилищеЗначения(ДвоичныеДанные, Новый СжатиеДанных(9)); УдалитьФайлы(ИмяВременногоФайла); ВерсионированиеОбъектовПривилегированный.ЗаписатьВерсиюОбъекта(Источник.Ссылка, ЧислоВерсийОбъекта, ХранилищеДанных); КонецЕсли; КонецПроцедуры

Нас интересует лишь функция «ОбъектВерсионируется», определяющая необходимость записии версии для записываемого объекта. Вот листинг этой функции:

// Проверяет настройки версионирования по переданному объекту и // и возвращает вариант версионирования. Если по объекту не настроено // версионирование, то он версионируется в соответствии с правилами // версионирования «по умолчанию». // Функция ОбъектВерсионируется(знач Источник, ЧислоВерсийОбъекта) // Проверяем, что подсистема версионирования включена Если глЗначениеПеременной(«ИспользоватьВерсионированиеОбъектов») Тогда ВариантВерсионирования = ПолучитьВариантВерсионирования(Источник); ЧислоВерсийОбъекта = ВерсионированиеОбъектовПривилегированный. ПолучитьКоличествоВерсийОбъекта(Источник.Ссылка) ВерсионироватьОбъект = Истина; Если ВариантВерсионирования = Перечисления.ВариантыВерсионированияОбъектов.НеВерсионировать Тогда ВерсионироватьОбъект = Ложь; // Если версионирование проводится при проведении, то для непроведенных документов // или нулевой версии объекта записать варианта не выполняется ИначеЕсли ВариантВерсионирования = Перечисления.ВариантыВерсионированияОбъектов.ВерсионироватьПриПроведении Тогда Если ЧислоВерсийОбъекта = 0 И НЕ Источник.Проведен Тогда ВерсионироватьОбъект = Ложь; КонецЕсли; КонецЕсли; Иначе ВерсионироватьОбъект = Ложь; КонецЕсли; Возврат ВерсионироватьОбъект; КонецФункции

Сначала проверяется включена ли константа использования версионирования объектов. После этого получаем вариант версионирования для текущего объекта, который мы настраивали в регистре сведений «Настройка версионирования объектов». Листинг этой функции:

Функция ПолучитьВариантВерсионирования(Источник) // Получаем имя объекта в метаданых ИмяОбъекта = Источник.Метаданные().Имя; // Получаем запись для текущего объекта по его имени НастройкаВерсионирования = РегистрыСведений.НастройкаВерсионированияОбъектов.СоздатьМенеджерЗаписи(); НастройкаВерсионирования.ТипОбъекта = ИмяОбъекта; НастройкаВерсионирования.Прочитать(); // Если вариант настроен — возвращаем его Если ЗначениеЗаполнено(НастройкаВерсионирования.Вариант) Тогда Возврат НастройкаВерсионирования.Вариант; Иначе // Если нет настройки и это справочник, то возвращаем вариант «Не версионировать» Если Справочники.ТипВсеСсылки().СодержитТип(ТипЗнч(Источник.Ссылка)) Тогда Возврат Перечисления.ВариантыВерсионированияОбъектов.НеВерсионировать; Иначе // Если это документ и для него не установлен вариант версионирования, // то если документ проводится возвращаем вариант «Версионировать при проведении» // иначе «Версионировать всегда» Возврат ?(ДокументПроводится(Источник.Метаданные().Имя), Перечисления.ВариантыВерсионированияОбъектов.ВерсионироватьПриПроведении, Перечисления.ВариантыВерсионированияОбъектов.ВерсионироватьВсегда); КонецЕсли; КонецЕсли; КонецФункции

В комментариях описан принцип работы функции. Заметьте, что если для документа не установлена настройка варианта версионирования, то он будет версиронировать все равно (при проведении или всегда).

Вместо заключения

Выше мы рассмотрели внутреннее устройство настроек версионирования объектов в конфигурации «Управление производственным предприятием» версии 1.3. В следующей статье мы подробно рассмотрим способ хранения версий объектов в базе данных, а также работу с ними.

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

В программах «1С» реализованы механизмы, позволяющие отслеживать изменения в базах различными способами:

• С помощью журнала регистрации. Платформенный механизм, позволяющий узнать кто и когда менял объект, без возможности детально отследить изменившиеся значения объектов;
• Через платформенный механизм ИсторияДанных. Отметим, что данный механизм появился в платформе 8.3.11 и позволяет работать с версионированием через встроенные механизмы платформы, что является несомненным плюсом.
• Через версионирование объектов (активируется самостоятельно). Данный механизм обеспечивается наличием в конфигурации подсистемы БСП «Версионирование объектов». Соответственно присутствует во всех современных типовых конфигурациях, разработанных на основе БСП (Библиотека стандартных подсистем).

Версионирование – это хранение истории изменений объектов. В отличие от журнала регистрации, в котором может храниться история изменения объектов, механизм версионирования позволяет пользователю:

• Увидеть изменения, внесенные пользователями;
• Просматривать любые версии объектов;
• Сравнивать версии объектов между собой;
• Восстановить предыдущую версию объекта.

Рассмотрим настройку подсистемы БСП «Версионирования объектов» в 1С 8.3 Бухгалтерия.

Как включить или отключить версионирование объектов

Настройку можно включать не только для всего объекта целиком, но и выборочно – для его отдельных составных частей, включая реквизиты табличных частей, и тем самым экономить место.

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

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

Рис.1 АдминистрированиеРис.2 Общие настройки

«Включение» версионирования заключается в настройке объектов конфигурации, для которых будет вестись учет изменений. При этом ведение истории можно включать не только для всего объекта, но и для его отдельных составных частей. Установив галочку «Хранить историю изменений», переходим по гиперссылке «Настройки хранения».

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

Рис.3 Выбор варианта хранения версииРис.4 Окно настройки сохранения версии

Следующий параметр – «Установить срок хранения версий».

Рис.5 Меню настройки срока хранения версий

После активации данной настройки у объекта появляется дополнительный пункт в меню – «История изменений» (кнопка «Еще» в журнале документов), а также кнопка на панели инструментов «Перейти к отчету по версиям объектов».

Рис.6 Настройки хранения истории измененийРис.7 Возможность просмотра истории изменений в журнале документов

Эти же пункты будут доступны и из самого документа.

Рис.8 Возможность просмотра истории изменений из документа

История изменений выглядит следующим образом: в открывшейся форме выводится список всех изменений объекта. Версию можно открыть или сравнить с любой из списка. Выбрать несколько строк можно с помощью кнопок «Shift» и «Ctrl».

Рис.9 История изменений документа «Счет» Рис.10 Просмотр версии объекта Рис.11 Формирование сравнительного отчета изменений между версиями Рис.12 Сравнение версий объекта

И в случае необходимости через кнопку «Перейти на версию» мы попадаем на выделенную (нужную) версию документа. Изменения, внесенные после этой версии, будут отменены.

Рис.13 Переход на другую версию объекта

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

О чем эта статья

В статье рассмотрен механизм версионирования объектов, реализованный в прикладном решении «Управление торговлей, ред.11» для сохранения истории всех изменений документов и справочников. Данный механизм позволяет восстановить измененные данные в случае ошибочных действий пользователей.

Применимость

Статья написана для редакции УТ 11.1. Если вы используете эту редакцию, отлично — прочтите статью и внедряйте рассмотренный функционал.

Если Вы работаете со старшими версиями УТ 11, то данный функционал является актуальным. В актуальных версиях для доступа к рассмотренному функционалу используйте команду Настройки хранения в разделе Поддержка и обслуживание (история хранения) подсистемы Администрирование.

Наиболее заметным отличием УТ 11.3/11.4 от редакции 11.1 является интерфейс Такси. Поэтому, чтобы освоить материал статьи — воспроизведите представленный пример на своей базе УТ 11. Таким образом Вы закрепите материал практикой 🙂

Версионирование объектов

– Кто испортил документ?! – крикнул Василий.

– Сегодня должен был получить премию за продажу товара. Прихожу к фин. менеджеру, а он мне говорит: «Какая премия? Вы не выполнили план продаж». Но как так? Помню, что провел реализацию на одну сумму, а сегодня сумма уже совсем другая. Что делать? Кто виноват?

Сердитый Василий берет телефон и набирает телефон тех. поддержки, которая обслуживает программу в компании и просит помощи: «Найдите виновных, надеялся премию получить!»

Трубку поднял оператор тех. поддержки и начал успокаивать Василия: «Не волнуйтесь, сейчас все выясним».

Как же повезло Василию, что в их компании использовалось УТ 11 и был включен функционал «Версионирование объектов». Оператор тех. поддержки без особого труда узнал кто, когда и что именно изменил в документах Василия.

Виновные были найдены и Василий в итоге получил премию.

Что же это за функционал такой, который помогает «разруливать» спорные моменты связаны с тем, кто именно из пользователей неверно заполнил и провел документ, установил не ту цену, склад, клиента, организацию и т.д?

В программе «Управление торговлей 11» присутствует отличная возможность для просмотра истории изменений (редактирования) справочников и документов под названием «Версионирование объектов». Давайте же рассмотрим как она работает.

Для включения использования этого функционала перейдем на закладку программы «Администрирование» пункт «Общие настройки» и установим галочку «Версионирование объектов».

(Нажмите, чтобы увеличить картинку)

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

(Нажмите, чтобы увеличить картинку)

В данном окне мы можем установить различные настройки версионирования объектов нашей базы. Их есть три вида:

Не версионировать – версии объекта не сохраняются.

Версионировать при записи – версии объекта сохраняются при любом изменении.

Версионировать при проведении – версии сохраняются только при проведении; настройка применяется только для документов, для которых разрешено проведение.

(Нажмите, чтобы увеличить картинку)

Установим для примера различные настройки для различных объектов базы: для справочника «Соглашения с клиентами» – версионировать при записи, для документа «Заказ клиента» – версионировать при проведении и т.д. Окно «Версионирование объектов» будет иметь следующий вид:

(Нажмите, чтобы увеличить картинку)

Для документа «Заказ клиента» установлено вид версионирования «Версионировать при проведении». Давайте перейдем в список заказов клиентов (закладка «Продажи» пункт «Заказы клиентов») и попробуем создать один документ «Заказ клиента» и перепровести его под разными пользователями.

В окне нашего документа «Заказ клиента» на панели навигации формы нажмем на пункт «История изменений».

(Нажмите, чтобы увеличить картинку)

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

(Нажмите, чтобы увеличить картинку)

Выделим все позиции и нажмем кнопку «Сравнить версии». Откроется отчет по изменениям версий объекта.

(Нажмите, чтобы увеличить картинку)

Здесь мы можем увидеть, что пользователь «Бахшиев» провел документ, а затем пользователь «Афанасьев» перепровел документ: изменил организацию с «Торговый дом «Комплексный”» на «ПБОЮЛ «Предприниматель”», изменил цену на товар «Телевизор «JVC”» с 20 000 на 28 000.

Также можно просматривать информацию про отдельную версию проведенного документа. Для этого в окне заказа «История изменений» выделим необходимую версию и нажмите кнопку «Открыть версию». Здесь можно посмотреть какие реквизиты документа были установлены пользователем, табличная часть «Товары» и график оплаты.

(Нажмите, чтобы увеличить картинку)

Функционал УТ 11 позволяет при необходимости даже перейти на нужную (прошлую) версию объекта. То есть в нашем случае документ провел пользователь «Бахшиев», а затем документ был изменен пользователем «Афанасьев». В окне заказа «История изменений» выделим мышкой версию «Бахшиев Павел Иннокентьевич» и нажмем кнопку «Перейти на версию».

(Нажмите, чтобы увеличить картинку)

В окне «История изменений» появится третья строчка с комментарием «Выполнен переход к версии №1 от 08.07.2013 15:49:42», а также сообщение об успешном восстановления объекта.

Теперь наш «Заказ клиента» возобновлено до версии пользователя «Бахшиев» – соответственно и организация, и цена снова стали такими, какими их установил пользователь «Бахшиев».

Как видим, функционал не сложный в использовании и очень полезный. С программой «Управление торговлей 11» Вы всегда будете в курсе кто и как именно провел документ или сохранил справочник.

Видов программ великое множество, и все они сильно друг от друга отличаются. Со временем даже одна система может развиться так, что ее станет не узнать. Как же разобраться во всем этом хаосе? Одним из решений является «Версионирование ПО”, с которым мы познакомимся в этой статье.

Версионирование это способ группировки и маркировки изменений, вызванных эволюцией системы. Говоря проще, это использование имен, для описания некоторого состояния программы. Чаще всего, в качестве имени выступает цифра, но может так же использоваться некоторое слово или смесь обоих, на пример — 2.4-alpha.

Применение версионирования решает следующие основные задачи разработки и сопровождения ПО:

1. Контроль изменений — с помощью версий, пользователи данной системы могут выбрать наиболее полезное для себя состояние (к примеру, с некоторой функциональностью или совместимую с данной ОС)
2. Группировка — версии позволяют автору ПО сгруппировать изменения и предоставить их пользователям в виде патча или обновления
3. Совместимость — при использовании «Семантического версионирования” (о котором мы поговорим немного позже), разработчики, использующие данный пакет, могут не бояться сломать свою систему после обновления или патча, так как правильный выбор версии гарантирует совместимость на уровне кода

Семантическое версионирование

Как уже было сказано ранее, версия может обозначаться любой последовательностью символов. Часто применяется простая модель версионирования: инкремент числа версии при каждом изменении — но это не всегда является удачным решением. Для понимания проблемы, с которой вы можете столкнуться при использовании такой модели версионирования, давайте рассмотрим простой пример:

Представьте, что вы используете пакет для обработки изображений в своей системе «Галерея фотографий”. Вся логика галереи всецело зависит от этого пакета, но пакет часто меняется, в нем появляются новые функции и закрываются старые баги, что постоянно изменяет его версию. Вы конечно же хотите «идти в ногу со временем” и часто обновляете этот пакет, но в один ужасный день вся система перестает работать. Быстрый анализ показывает, что проблема вызвана удалением из пакета одной старой, но используемой галереей функции (назовем ее crop).

Как же обезопасить свой код от такого рода проблем? Решение есть, оно называется «Семантическим версионированием”. Использование систем, применяющих эту модель версионирования, обеспечивает вас удобным инструментом для контроля за возможными изменениями и совместимостью. Работает это очень просто, нужно всего навсего следовать следующим правилам при выборе версии ПО:

1. Версия представляется в виде трех целых цифр, разделенных точкой (на пример 2.4.1). Первая цифра называется минором версии, вторая мажором, а третья патчем
2. Каждая из трех цифр не ограничена в своей размерности и служит для контроля изменений на данном уровне (об уровнях чуть позже). Это означает, что версия вида 3.15.91 вполне обычное явление и не следует стремиться к смене мажорной версии при достижении патч-версии десятки (частая ошибка новичков)
3. Патч-версия изменяется при любых изменениях системы, не добавляющих новую функциональность и не изменяющих старую. Обычно изменение патч-версии ПО означает, что в нем были поправлены некоторые баги или выполнен рефакторинг
4. Мажорная версия изменяется при добавлении новой функциональности с учетом обратной совместимости. Другими словами, вы можете смело обновлять ПО на новую мажорную версию, не опасаясь ошибок, описанных в примере выше, так как с этим обновлением вы получите только новую функциональность
5. Минорная версия изменяется при появлении несовместимых изменений, таких как: удаление устаревших (но, может быть, используемых кем то) функций, расширения семантики компонентов системы (к примеру добавление новых, обязательных аргументов функции) и т.п. Для обновления минорной версии необходимо предварительно обеспечить совместимость ваших компонентом с ее правками

Чтобы было понятнее, рассмотрим несколько примеров:

Если вы увидите, что для используемого вами пакета обработки изображений ImageEditor 1.1.4 изменилась версия до 1.1.5 (патч-версия), смело обновляйте ее, ведь это не нарушит совместимости с вашей галереей.

В новой версии 1.2.0 (мажорная версия) этого же пакета появилась функция resize? Обновитесь. Галерея будет продолжать работать без ошибок, ведь новая функция никак ей не помешает.

Вышла новая версия ImageEditor 2.0.0 из которой была удалена функция crop? Для обновления придется заменить эту функцию на аналогичную в вашей галерее, иначе обновиться до новой минорной версии вы не сможете.

Альфа, бета и другие имена версий

Часто имеет смысл расширять версию некоторым именем, на пример alpha. Делается это для дополнительной семантической группировки изменений, либо для конфиденциальности. Рассмотрим два случая такой модели:

1. «Альфа”, «бета” и «релиз” версионирование — такая модель используется для описания состояний системы, при которых она тестируется разными группами людей. Система, версия которой помечена как alpha (на пример 1.1.0-alpha) обычно еще слишком сырая для представления пользователю и тестируется внутри компании или только доверенными лицами. Пометка beta (на пример 1.1.4-beta) означает, что система, по мнению разработчика, завершена, но ее еще следует протестировать целевым пользователям. Релизная версия, маркеруемая как r (на пример 1.1.5-r) или вовсе не имеющая буквенных маркеров, полностью прошла тестирование внутри и вне компании и может безопасно использоваться клиентами
2. Проектные имена — эта модель подразумевает параллельное версионирование, облегчающее пользователям восприятие новой версии продукта. Она выражается в использовании запоминающихся имен версий, таких как star, zero, red и т.д., которые будут известны пользователям. Внутри компании, часто используется обычное семантическое версионирование

Список изменений

Для отслеживания изменений в версиях применяются файлы «Логов изменений” (Changelog), в которых описываются правки, сгруппированные по версиям. При выпуске новой версии ПО этот файл дополняется соответствующими этой версии изменениями. Каждая группа в этом файле, как правило, состоит из четырех подгрупп:

1. Добавлено (added) — новые функции
2. Устарело (deprecated) — устаревшие функции, которые будут удалены в следующих (минорных) версиях
3. Удалено (removed) — удаленные функции
4. Исправлено (Fixed) — исправленные баги и рефакторинг

Взгляните на этот файл на примере пакета Zend-Diactoros.