версионирование что это такое

Версионирование объектов (новые возможности «1С:Бухгалтерии 8»)

В «1С:Бухгалтерии 8» (ред. 3.0), начиная с версии 3.0.35, реализован механизм версионирования объектов, с помощью которого можно отслеживать историю изменений документов и справочников.

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

Использование версионирования особенно актуально на начальном этапе внедрения программы, когда объемы информации небольшие, а исполнители совершают много ошибок (например, вводят лишнюю информацию или очищают наименование или значение какого-то реквизита внутри объекта).

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

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

Объекты версионирования

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

Если для выбранного справочника или документа версионирование включено, в его форме будет доступна команда История изменений (рис. 1).

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Рис. 1. Команда История изменений в форме элемента справочника.

По этой команде открывается список версий объекта (рис. 2).

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Рис. 2. История изменений объекта.

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

В списке выводится следующая информация:

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

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

Используя соответствующие кнопки, в форме списка доступны следующие действия:

Обращаем ваше внимание, что при удалении объекта его история также удаляется, поэтому в этой ситуации версионирование не поможет.

Настройки хранения версий

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Рис. 3. Механизм версионирования объектов в составе раздела Администрирование.

После этого становится доступной гиперссылка Настройки хранения, перейдя по которой можно произвести необходимые настройки версионирования (рис. 4).

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Рис. 4. Настройки версионирования объектов.

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

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

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

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

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

Команды Установить вариант версионирования и Установить срок хранения версий также можно найти в меню Еще или в контекстном меню, вызываемом правой кнопкой мыши.

По гиперссылке Количество и объем хранимых версий объектов можно перейти к просмотру одноименного отчета.

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

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

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Рис. 5. Настройка регламентного задания по удалению устаревших версий.

В соответствии с выполненными настройками устаревшие версии будут автоматически удаляться регламентным заданием (в нашем примере ежедневно).

Источник

v3.14.1592-beta2: все, что вы хотели знать о семантическом версионировании

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такоеУсилия и деньги, вкладываемые в продвижение языка Go, часто приносят пользу и другим разработчикам. В конце прошлого года на сайте gopheracademy была опубликована очень удачная статья о семантическом версионировании. Том самом, которое используется в npm, начинается с домика ^ и все ломает. Под катом спрятан перевод, который поможет вам быстро осмотреть сад граблей версионирования и как сейчас принято им пользоваться. И немного примеров на Go. Передаем слово автору!

Семантическое версионирование (также известное как SemVer) уже стало популярным подходом к работе с версиями программ и библиотек. Оно не только облегчает работу с последовательными релизами, но позволяет и людям, и автоматике понимать совместимость этих релизов друг с другом и с остальным миром. SemVer можно использовать много где, но больше всего этот подход известен в системах управления зависимостями.

Прежде чем рассказывать о специфичных для Go вещах, давайте посмотрим, что такое семантическое версионирование (примечание переводчика: ради этой части и был затеян перевод).

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

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

Несмотря на то, что в спецификации ничего не говорится о префиксе “v”, он часто используется перед строкой семантической версии, например, “v.12.3”. Так же, как и метаданные, его принято игнорировать.

Все это и многое другое можно найти в официальной спецификации: http://semver.org/

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

Парсинг семантических версий в Go

Для Go доступно несколько пакетов для работы с семантическими версиями. В этой статье я рассмотрю вот этот: github.com/Masterminds/semver. Он соответствует спецификации, поддерживает необязательный префикс “v”, сортировку, работу с диапазонами и ограничениями. При этом с ограничениями этот пакет работает так же, как большинство решений для других языков программирования, таких как JavaScript, Rust и другие.
Пример ниже парсит строку семантической версии и выводит либо “major” версию, либо сообщение об ошибке:

Возвращаемое значение является экземпляром semver.Version, который содержит некоторое количество полезных методов. Если переданная строка не является семантической версией, то возвращается ошибка semver.ErrInvalidSemVer.

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

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

С помощью библиотеки semver вы можете сортировать семантические версии средствами стандартной библиотеки. Например:

В этом примере набор семантических версий преобразуется в экземпляры semver.Version, которые затем складываются в semver.Collection. А у semver.Collection есть все необходимое для использования со стандартной библиотекой sort. Это очень удобно для правильной сортировки pre-release информации и игнорирования мета-тегов.

Диапазоны, Ограничения и Wildcards

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

Для тех, кто знаком с диапазонами версий по другим языкам и тулзам, библиотека предлагает хорошо знакомую нотацию:

Источник

Версионирование (история изменений) объектов в 1С:Предприятие 8

Механизм версионирования позволяет хранить не только даты и автора изменений, но и историю изменений документа (реквизиты. параметры данных и т.д.), опция позволяет просматривать различные версии состояния одного и того же документа. Чтобы использовать данную опцию, необходимо предварительно провести настройку версионирования объектов. Как настройку, так и просмотр всех состояний документа может проводить администратор системы.

Как настроить версионирование объектов?

Выполнение настройки версионирования проводится в учетной записи Администратора, в которой открыты все права.

1. Открыть конфигурацию в режиме конфигуратора

2. Выбрать КонфигурацияПоддержкаНастройка поддержки

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

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

4. Выбрать КонфигурацияСравнить, объединить с конфигурацией из файла, выбрать загруженный файл

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

5. В открывшемся окне снять галку у вкладки Свойства в основной конфигурации (слева), затем нажать Выполнить

6. Для настройки необходимо открыть программу, на панели навигации перейти к пункту Операции/Константы:

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такоеверсионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое
7. В закладках нужно выбрать «Версионирование», установить галочку перед надписью «Использовать версионирование объектов»:

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такоеверсионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

8. Далее следует открыть блок настройки, для чего нужно нажать на кнопку Настройка версионирования объектов…»

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

В параметрах настройки есть возможность указать значение всех типов документов, справочников:

Не версионировать — параметр установлен для всех типов объектов по умолчанию;
Версионировать — параметр применяется для настройки справочников и документов;
Версионировать при проведении —используется только для документов.

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такоеверсионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое
В том случае, если для какого-либо типа документа или справочника выбран параметр Версионировать, в историю версий этого объекта будет выполняться запись при каждом изменении этого объекта.

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

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

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

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

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такоеверсионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Для удобства можно ввести кнопку на отчет прям из документа, которая будет формировать отчет сразу по изменениям версий данного документа:

версионирование что это такое. Смотреть фото версионирование что это такое. Смотреть картинку версионирование что это такое. Картинка про версионирование что это такое. Фото версионирование что это такое

Конфигурация тестировалась на различных версиях:

— 1С Бухгалтерия 2.0 (2.0.44.8)

— Управление торговлей 10.3 (10.3.34.2)

— Альфа-Авто: Автосалон+Автосервис+Автозапчасти, редакция 5.1 (5.1.02.09).

Должно работать с любой конфигурацией на обычных формах.

Источник

Подходы к версионированию изменений БД

Намного лучше дисциплинарные ограничения убирать инструментарным расширением
Автор статьи

Введение

При разработке информационной системы, то есть программы, нацеленной на хранение, работу с данными, обработку, анализ и визуализацию какой-то базы данных, одним из краеугольных камней стоит задача разработки БД. Когда я только начинал задаваться этим вопросом, казалось – что ни сделай, все равно будет криво.

На протяжении 5 лет разработки нескольких корпоративных ИС, я ставил и пытался решать вопросы, как тот или иной аспект разработки БД сделать удобным. Искал инструменты, помогающие что-то делать с БД, методологии. На удивление в этой области мало наработок. И в каждом подходе сразу видно – вот это нельзя, вот тут будет неудобно, тут слишком много дисциплинарных правил (см эпиграф)… В этой статье я попытался собрать те походы, которые считаю наиболее эффективными, и один, в добавление к собранным, представлю как венец моих исканий, который считаю наиболее «бронебойным».

Эволюция проблемы

Приведу пример, как может задача разработки БД стать проблемой и эволюционировать. Если интересна сразу глобальная постановка задачи со всеми фичами, этот параграф можно пропустить.

Какие-то из пунктов этой эволюции могут показаться излишними и вообще придумыванием себе проблем, но при их решении удобным инструментом разработка БД станет почти такой же простой и безболезненной, как и разработка обычного кода приложения.

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

Полная универсальная постановка задачи

Задачи и проблемы, которые могут вставать при разработке БД:

По каждому объекту БД нужно иметь возможность увидеть историю его изменений.
A. Для контроля нужно иметь возможность увидеть, какие изменения будут накатаны, в конкретных SQL-скриптах («накопительные скрипты»).
B. Очень желательна возможность code review. Причем явный оператор alter предпочтительнее сравнения операторов create table (на основе которых делается diff и впоследствии накатывается), поскольку лучше контролировать действия с БД, а не декларации. А для процедур и подобных объектов надо иметь возможность видеть diff тела.

В моей практике я руководствовался пунктами:

Так что я считаю обязательными все пункты, кроме 3b и 4.

Подходы

Я пришел к выводу, что целесообразно выделить подходы:

В этом списке подходы отсортированы по увеличению полезности.

Похожие статьи

В целом к идеи автоматизации наката скриптов по коммиту я бы отнесся крайне настороженно – иногда бывает, что коммиты делаются неготовыми или неполными. Дисциплинарное правило «коммить в мастер только готовый код» на практике работает очень плохо. Лучше его избегать улучшением инструментария – для этого существует класс инструментов continuous integration (например, TeamCity от JetBrains или совсем бесплатный Jenkins). Я за то, чтобы накат скриптов на БД происходил исключительно осознанно человеком-программистом и только в нужные моменты времени – которые никак не должны быть связаны с коммитом.

1 Сравнение схем целевой БД и БД-источника

Инструмент

Redgate SQL Compare. Еще есть http://compalex.net/, но он работает только с php. Есть и другие инструменты сравнения схем БД.

Методология

Кроме БД prod – она целевая БД – делается БД dev – она БД-источник.

Каким-либо образом делаются изменения в БД-источнике. Причем эта БД-источник получается не тестовая в общепринятом смысле, потому что с ней нельзя делать все, что угодно – подразумевается, что все изменения (по крайней мере, изменения схемы БД) должны перенестись на целевую БД. Далее эти изменения могут скриптоваться, но эти скрипты впоследствии никак не используются – потому что, если их использовать и накатывать каким-либо образом, то вся суть подхода исчезает, сравнение схем становится бессмысленным. Эти скрипты могут лишь играть роль истории изменений. Но которая может отличаться от реальности, поскольку можно что-то визуально в Management Studio (или другом GUI для БД) поменять и забыть это заскриптовать. Или заскриптовать неправильно. Потом, в момент деплоя на целевую БД, делается (с помощью инструмента) diff-скрипт, который накатывается, приводя целевую БД в состояние равной схемы с источником.

Плюсы

Минусы

Подход не решает задачи

2 Cравнение заскриптованной схемы (и данных) с целевой БД

Инструмент

Я не знаю, какой инструмент мог бы сравнить две схемы БД не по самим базам, а по скриптам. Поэтому этот подход теоретический. Но, если найти или сделать такой инструмент, кажется, подход стал бы неплохим. Особенно, если этот инструмент мог бы сравнивать и данные.

Методология

Роль БД-источника тут играл бы каталог с скриптами, полностью создающими БД – и схему, и версионируемые данные (справочники, персистентные справочники). То есть программист вносит изменения в эти скрипты, запускает инструмент, который сравнивает весь каталог с целевой БД и делает diff-скрипт, который либо сохраняется для code review, либо сразу накатывается.
Так как инструмента нет, то можно лишь фантазировать о том, как этот инструмент мог бы сравнивать данные и настройки БД и SQL Server’а.

Плюсы

Минусы

Подход не решает задачи

3 На основе последовательных (инкрементальных) ручных SQL-скриптов

Инструмент

flyway db. Возможно, есть альтернативы (https://github.com/lecaillon/Evolve – я не готов рассказать об этом инструменте, но, похоже, делает что-то похожее).

Методология

Методология подхода наиболее проста. Зачаровывающе проста. По мере необходимости пишутся sql-скрипты изменений – произвольные, как на изменение схемы, так и на изменение данных. Не имеет значения, какие скрипты. Файлики нумеруются, складываются в папочку. В нужное время запускается инструмент, который в порядке нумерации накатывает новые, то есть еще не исполненные файлы скриптов на выбранную БД. Накатанные запоминает в специальной табличке, то есть повторно скрипт не исполнится.

Так работает компания Qiwi. Или работала, когда я там участвовал в разработке платежной системы. Но там без инструментов, инструмент заменяют дисциплинарные правила. Есть несколько QA-сотрудников, которые следят за специальным репозитарием git и накатывают новые скрипты, сначала на тестовую БД – смотрят, не сломалось ли чего, потом, если все хорошо, на prod.

Плюсы

Минусы

Подход не решает задачи

4 На основе ручных независимых SQL-скриптов, структура которых повторяет схему БД

Инструмент

Методология

Для создания и изменения схемы на каждый объект БД создаем по файлику, в котором будет скрипт, отвечающий за этот объект – таким образом при версионировании файлов получаем историю изменений на каждый объект. Эти файлики кладем в папочки, повторяющие структуру БД. Так как последовательность исполнения скриптов важна, вводим управляющие файлы, содержащие последовательность наката скриптов, а инструмент делает написание этих управляющих файлов достаточно простым и решает, какое изменение накатывать нужно, а какое нет – если оно уже было накатано ранее или отфильтровано. Кроме того, если нужно различие в чем-то в различных инстансах БД, вводим значения переменных, которые инструмент использует, модифицируя нужным образом скрипты для каждого инстанса. Кроме того, можно ввести фильтры на скрипты, и, в зависимости от контекста («только изменение схемы», «только импорт справочников», «создать/обновить только такой-то кусок схемы») отфильтровать скрипты.

Для изменения таблицы нужно в файлик с ее create’ом дописать скриптик (changeset) с оператором alter или create index или каким-то другим. Или можно изменить существующий соответствующий changeset, если возможно сделать его повторнонакатываемым.

Для изменения процедуры/функции/триггера/вью надо поменять код в файлике, соответствующем этому объекту. Чтобы этот скрипт был повторнонакатываемым, нужно в первом changeset’е сделать создание этого объекта с пустым телом, а во втором – оператор alter с нужным телом (жаль, у SQL Server’а нет оператора create or alter). Тогда первый changeset будет исполняться только один раз, а второй – при изменении.

Ну а для непосредственно deploy’я делаем bat-файл(-ы), запускающие инструмент с нужным контекстом и настройками. Таким образом нужный deploy будет запускаться посредством запуска соответствующего bat’ника.

Файлы

Делаем следующую структуру папок:

core
Тут будет сам инструмент и его настроечные файлы.

Как видно, идея этих папок в повторении схемы БД и соответствии каждого объекта своему одному файлу.

В головной папке будут файлы:

Заметим, что для создания/изменения хранимых процедур, триггеров, функций и типов последовательность не важна. Поэтому достаточно команды includeAll инструмента, накатывающего их в алфавитном порядке.

Как использовать

Для каждого варианта использования нужно создать bat-файл, запускающий инструмент с соответствующим контекстом – например, deploy_local_scheme.bat, deploy_local_full.bat, deploy_prod_scheme.bat, deploy_prod_full.bat, deploy_

.bat etc. В одном проекте у меня таких файликов было аж 18 – там была целая система миграции данных, и нужно было регулировать, когда какую миграцию исполнять.

Кроме контекста, bat-файл в себе должен содержать connection string и имя команды инструмента.
Возможные команды:

Я еще для удобства просмотра логов исполнения сделал вывод их в текстовый файлик:
> %outputfilename% 2>&1

Changeset’ы могут быть помечены атрибутами:

В случае, когда нужно изменить схему так, что сломаются какие-то скрипты изменения данных, то есть миграционные скрипты (например, если нужно изменить название таблицы, колонки, удаление чего-то), то нужно написать соответствующий alter или sp_rename в файлик, соответствующий данной таблице, и соответствующим образом изменить нужные скрипты. Далее, для одноразовых скриптов из них нужно сделать так, чтобы инструмент не выдавал ошибку, что накатанный changeset изменился. Это достигается двумя путями – либо команда changelogSync, либо вручную изменить соответствующую строку в таблице инструмента, обновив там md5-сумму – значение ее подскажет сам инструмент.

Плюсы

Минусы

Подход не решает задачи

Только необязательный в моем видении п3b. Победа.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *