версионирование что это такое
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
Один из самых популярных вопросов относительно версий заключается в проверке, лежит ли версия в указанном диапазоне. Или удовлетворяет ли она каким-то другим ограничениям. Все эти проверки легко сделать с помощью библиотеки:
Для тех, кто знаком с диапазонами версий по другим языкам и тулзам, библиотека предлагает хорошо знакомую нотацию:
Версионирование ПО
Видов программ великое множество, и все они сильно друг от друга отличаются. Со временем даже одна система может развиться так, что ее станет не узнать. Как же разобраться во всем этом хаосе? Одним из решений является “Версионирование ПО”, с которым мы познакомимся в этой статье.
Польза от версионирования ПО
Применение версионирования решает следующие основные задачи разработки и сопровождения ПО:
Семантическое версионирование
Представьте, что вы используете пакет для обработки изображений в своей системе “Галерея фотографий”. Вся логика галереи всецело зависит от этого пакета, но пакет часто меняется, в нем появляются новые функции и закрываются старые баги, что постоянно изменяет его версию. Вы конечно же хотите “идти в ногу со временем” и часто обновляете этот пакет, но в один ужасный день вся система перестает работать. Быстрый анализ показывает, что проблема вызвана удалением из пакета одной старой, но используемой галереей функции (назовем ее crop ).
Как же обезопасить свой код от такого рода проблем? Решение есть, оно называется “Семантическим версионированием”. Использование систем, применяющих эту модель версионирования, обеспечивает вас удобным инструментом для контроля за возможными изменениями и совместимостью. Работает это очень просто, нужно всего навсего следовать следующим правилам при выборе версии ПО:
Чтобы было понятнее, рассмотрим несколько примеров:
Если вы увидите, что для используемого вами пакета обработки изображений ImageEditor 1.1.4 изменилась версия до 1.1.5 (патч-версия), смело обновляйте ее, ведь это не нарушит совместимости с вашей галереей.
Альфа, бета и другие имена версий
Список изменений
Для отслеживания изменений в версиях применяются файлы “Логов изменений” ( Changelog ), в которых описываются правки, сгруппированные по версиям. При выпуске новой версии ПО этот файл дополняется соответствующими этой версии изменениями. Каждая группа в этом файле, как правило, состоит из четырех подгрупп:
Взгляните на этот файл на примере пакета Zend-Diactoros.
Инструмент автоматизации управления версиями
Всегда было интересно, что такое версии продукта и как ими управлять? Как автоматизировать управление версиями разработки? Прошу под кат.
Меня зовут Роман. Я разработчик в очень интересной компании Softeq, где каждый человек — вдохновитель.
При разработке различных инструментов я впал в размышления о том, всем ли разработчикам известно, что же такое версия, какой смысл она несет и как ей управлять при разработке. Итак, давайте рассмотрим, что же такое версионирование.
Версионирование
Версионирование — разработка и управление несколькими выпусками продукта, которые имеют тот же общий функционал, но усовершенствованы, модернизированы либо индивидуализированы.
Коротко, версия говорит об изменении продукта. Как версия говорит об изменении продукта?
Давайте назовем систему упорядочивания символов для обозначения версии продукта — схемой версионирования. Различные схемы версионирования были созданы для отслеживания версий различного программного обеспечения.
Семантическое версионирование
Схем версионирования много, но мы сталкиваемся с Семантическим версионированием (Semantic Versioning) каждый день. Для Семантического версионирования характерно то, что номера версий и то, как они меняются, передают смысл содержания исходного кода и какие модификации были применены от одной версии к другой.
Рассмотрим, каким образом формируется номер Семантической версии.
Давайте представим, что у нас имеется проект в разработке. Главная задача проекта — управление построением библиотеки. Проект позволяет производить заказ материалов для построения здания, контролировать этапы построения библиотеки. В настоящее время спроектирована архитектура приложения, произведена реализация базовых задач. При тестировании функционала заказа материалов для построения здания библиотеки обнаруживается ошибка, bug. Производится исправление ошибки и повышается Patch версия проекта.
У заказчика возникла идея о необходимости внедрить анализ маркетинговой информации в проект. Разработчики искусно и быстро спроектировали сервисы анализа данных, интегрировали сервисы с актуальной архитектурой. Произведено добавление новой функциональности проекта, которая не нарушает обратной совместимости. Повысилась Minor версия проекта.
Проект был успешно реализован. Через некоторое время у заказчика возникла идея по развитию данной технологии автоматизации бизнеса. В предстоящих планах были совершенно новые сервисы: формирование команды строителей, внутренняя социальная сеть, внутренний обмен документами и прочее. Разработчики проявили высокую компетентность, и через некоторое время архитектура проекта была спроектирована для решения и новых, и старых задач. Новая архитектура проекта внесла обратно несовместимые изменения. Повысилась Major версия проекта.
Итак, мы представляем, что же такое версии продукта. Но как ими управлять?
Давайте рассмотрим инструмент автоматизации управления версиями.
Versionings
Управление версиями производится при помощи командной строки:
Давайте рассмотрим пример повышения версии продукта.
Действия
Ведется разработка проекта актуальной версии 2.5.3. Разработка нового сервиса проекта ведется в ветке crm-user-service. Завершилась разработка сервиса, закоммичены все изменения и принято решение о повышении минорной версии:
Результат
Замечания
Всем продуктивного настроения и отличного дня!
Подходы к версионированию изменений БД
Намного лучше дисциплинарные ограничения убирать инструментарным расширением
Автор статьи
Введение
При разработке информационной системы, то есть программы, нацеленной на хранение, работу с данными, обработку, анализ и визуализацию какой-то базы данных, одним из краеугольных камней стоит задача разработки БД. Когда я только начинал задаваться этим вопросом, казалось – что ни сделай, все равно будет криво.
На протяжении 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. Победа.
Как работает и что помогает решить версионирование объектов в 1С
Стандартный механизм, реализованный в программных продуктах, поставляемых фирмой 1С, позволяет решить задачу отслеживания изменений в базах данных двумя способами:
Сразу следует сделать небольшое замечание. В базах со значительным документооборотом и большими объемами вносимой информации версионирование объектов 1С может приводить к существенному увеличению объемов хранилища.
Что это за механизм и для чего он нужен
Журнал регистрации позволяет отследить историю изменения объекта, однако, у него есть один существенный недостаток – он не позволяет увидеть, какие именно изменения вносились в существующие данные.
Версионирование объектов позволяет:
Как уже было сказано выше, включать этот механизм следует обдуманно, заранее определив набор объектов хранения.
Чаще всего версионирование объектов 1С задействуют на этапе внедрения того или иного программного продукта:
Таким образом, с помощью этого механизма администратор и разработчики получают реальную возможность для анализа возникающих нестандартных ситуаций, систематизации ошибок и принятия решений относительно путей и способов устранения возникающих проблем.
В функционирующих на полную мощность системах, объемы версионирования можно ограничить наиболее важными направлениями и областями деятельности.
Включение системы версионирования
Рассмотрим последовательность действий для включения механизма версионирования объектов на примере конфигурации «Зарплата и управление персоналом», редакция 3.1.
Если его нет, зайдем в подменю «Все функции…» в ветку «Константы»-> «Использовать версионирование…» (Рис.2) и активируем галочку на этой форме
После активации флажка появится еще один элемент меню: «Настройки хранения» (Рис.3)
Перейдем по этой ссылке и откроем форму настройки хранения истории (Рис.5).
Настройка истории изменений
Давайте рассмотрим вышеприведенную форму:
Новые версии объектов могут сохраняться:
Сроки хранения версий можно ограничить периодами от одной недели до одного года, если ничего не выбирать в этой колонке, варианты объекта будут бессрочно храниться в базе.
В случае, если к существующему списку справочников и документов нам потребуется добавить собственный объект, мы должны:
После сохранения и обновления конфигурации наш добавленный элемент появится в отрывающейся форме настройки.
После активации и настройки расписания удаления объектов в системе появится соответствующее регламентное задание.
Здесь следует отметить, что вся информация о версиях объектов хранится в регистре сведений «Версии объектов», соответственно все действия, характерные для непериодических регистров сведений доступны и для этого регистра, в частности, полную его очистку можно выполнить с помощью кода, представленного на Рис.7
Как с этим механизмом работать
После включения возможности хранения вариантов объекта для какого либо элемента метаданных, на форме элемента (справочника, документа, бизнес-процесса) появится команда «История изменений». Активация этой команды вызовет соответствующую форму, в которой можно будет увидеть:
Еще раз обратим внимание на то, что этот мощный инструмент надо использовать обдумано и осмысленно, в противном случае он может значительно снизить эффективность работы с программой.