Простой подход к версионированию баз данных MS SQL Server

Предисловие.

Очень часто в прикладных программах возникает необходимость использовать современные базы данных, которые предоставляют разработчику очень большой функционал, основанный не только на уровне данных, но также и созданию собственного API для предоставления доступа к этим данным, посредством хранимых процедур, триггеров, функций. Очевидно, что во всей этой структуре в зависимости от обстоятельств, могут понадобятся какие-либо изменения. И в самом безобидном случае, когда разработчик имеет дело с одним клиентом и одной изменяющейся базой данных (предположим на небольшом предприятии), процесс обновления выглядит просто – мы делаем необходимые изменения в структуре, сравниваем с помощью специальных утилит, например SQL Examiner, старую и новую версию и накатываем сгенерированный sql-скрипт на существующую базу. Как видно в описанном случае, миграция данных происходит каждый раз при обновлении структуры базы. Но к сожалению, описанная ситуация встречается крайне редко, чаще — клиенты и соответствующих для них базы данных для какого-либо продукта у разработчиков исчисляется сотнями, если не больше. Таким образом, для нормального жизненного цикла базы данных необходима система версионирования (не путать с системами версионирования исходников типа Subversion).

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

Dklab_rowlog — это библиотека из нескольких хранимых процедур PostgreSQL, позволяющая добавить версионирование записей к любой таблице в БД. Иными словами, что бы ни происходило с таблицей, как бы данные там ни менялись (добавлялись/удалялись), это будет отражено в специальной табличке-логе.

Преимущества:

• Версионирование добавляется к любой таблице за 1 минуту с использованием 1 SQL-команды.
• Можно указать, какие колонки надо сохранять, а какие — нет (что экономит место). При этом запись в лог добавится только в случае, если хотя бы одна из указанных колонок изменилась.
• Можно указать колонку, которая будет трактоваться как «ID автора изменения».
• Можно задать колонки, которые будут логироваться в любом случае, независимо от того, менялись они или нет.

Примеры использования

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

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

В топике рассматривается еще одна простая система версионирования структуры БД, а также ИМХО, почему нам не подходят другие.

Предыстория

В сети появляется масса разнообразных статей, посвященных миграции структуры базы данных, в которых предлагается множество вариантов безболезненного решения данной проблемы (стоит учесть, что необходимость в такого рода миграции уже сама по себе является серьезной проблемой). Любопытно, но исключить необходимость в таком решении предлагают существенно реже. Автор уверен, что вместо поиска решения сложной проблемы, лучше постараться ее предотвратить. Сделать это нужно как можно раньше. Ниже вас ждет рассказ о проекте, демонстрирующем негативную сторону миграции структуры базы данных.

Статьи, на которые стоит обратить внимание:

• Версионная миграция структуры БД: от теории к практике
• Версионная миграция структуры базы данных: основные подходы

Преамбула

Пару лет назад я и мои сотрудники столкнулись с проблемой сопровождения большого количества аналогичных БД на удаленных филиалах. Удалены они иногда на тысячи километров, а объемы исчислялись гигабайтами – что не позволяло использовать какое-либо зеркалирование серверов. Осложнялась ситуация мелкими отличиями, т.е. 95% бизнес-логики филиалов совпадало, но было ещё 5%, которые сильно мешали и ни о какой автоматической обработке группы филиалов не было и речи.

Здравствуйте. Что такое миграции и зачем они нужны хорошо рассказано в статье Версионная миграция структуры базы данных: основные подходы.
Я же хочу вам рассказать о системе версионных миграций: FluentMigrator. Почему мне нравится именно этот проект? Из-за приятного синтаксиса миграций и поддержки различных СУБД. Заинтересовались? Добро пожаловать под кат.

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

Я, конечно, пытался использовать какие-то методы сортировки помимо файловой системы — т.к. часто хочется упорядочить файлы не по одному критерию, а по нескольким равнозначным, что невозможно сделать в древовидной иерархии — требуется сетевая структура. Но все мои усилия разбивались об интерфейс. Судите сами.

Введение

Грамотно налаженные и состоявшиеся процессы — не для нас! Это ведь скучно, когда все уже настроено и работает как часы, но к этому надо стремиться. А уж после порадоваться проделанной работе и очередной раз проверить, как же все хорошо работает…

В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.



Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.

Вчера, 24 апреля, был анонсирован релиз NGINX 1.6 и 1.7. Эта статья объясняет, как планируются релизы NGINX и значение этого изменения нумерации версий.

NGINX 1.6 отделился от текущей основной (mainline) ветки 1.5, а последняя была перенумерована в 1.7. Это ежегодное событие, когда берется текущая основная ветка с новой функциональностью и от нее ответвляется новая стабильная (stable) ветка. Разработка активно продолжается на уже перенумерованной основной ветке.


Версия 1.4 более не поддерживается. Основная ветвь 1.5 была форкнута для создания стабильной 1.6 и перенумерована в 1.7.

С радостью объявляем о выходе новых релизов NGINX 1.8 стабильной (stable) ветки и NGINX 1.9 основной (mainline) ветки, в рамках которой будет продолжаться разработка новой функциональности. Новые ветки релизов заменяют 1.6 и 1.7 соответственно.

За последний год в 1.7 было выпущено 12 версий, и все новые возможности, которые в них появились, теперь доступны в 1.8, включая:

• Проверку SSL сертификатов бэкендов — Призвана защитить соединения с upstream-серверами от MITM-атак;
• Логирование в syslog — Позволяет передавать логи по сети посредством UDP-сообщений;
• Пулы потоков для выполнения блокирующих операций ввода-вывода — Увеличивают производительность NGINX в ситуациях, когда блокировка на чтении с диска неизбежна;
• Новый метод балансировки нагрузки “hash” — Позволяет выбирать сервер из группы базируясь на хэше от произвольной переменной;
• Небуферизированный прием тела запроса — Позволяет передавать запрос на бэкенд сразу, не дожидаясь окончания приема тела запроса целиком.

Полный список нововведений за последний год можно посмотреть в логе изменений для 1.8.

Я мог бы легко оформить свое предложение в виде письма в техподдержку Хабрахабра, но мне захотелось узнать, нужно ли то, что я собираюсь предложить кому-то еще, кроме меня.

Ащепятки

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

Почему мы все здесь собрались?

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

*Поломанный кран в офисе Magento и быстрое решение воплощенное в жизнь одним из инженеров — типичный Backward Compatible фикс.

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

Введение

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

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

Всем привет!

Всегда было интересно, что такое версии продукта и как ими управлять? Как автоматизировать управление версиями разработки? Прошу под кат.

Эта статья — своеобразный мастер-класс «DVC для автоматизации ML экспериментов и версионирования данных», который прошел 18 июня на митапе ML REPA (Machine Learning REPA:
Reproducibility, Experiments and Pipelines Automation) на площадке нашего банка.

Тут я расскажу об особенностях внутренней работы DVC и способах применения его в проектах.

Примеры кода, используемые в статье доступны здесь. Код тестировался на MacOS и Linux (Ubuntu).

Средство разрешения зависимостей

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

Ограничения обычно задаются именами модулей и номерами версий. В экосистеме JVM для модулей Maven будет ещё указано наименование организации (group id). Кроме того, ограничения могут содержать диапазоны версий, исключаемые модули, переопределения версий и т.п.

Три основных категории пакетов представлены OS-пакетами (Homebrew, Debian-пакеты, и т.п.),
модулями для конкретных языков программирования (CPAN, RubyGem, Maven, etc) и расширения, специфичные для приложения (Eclipse plugins, IntelliJ plugins, VS Code extensions).

— Коллеги, файл project_lastVersion точно финальный? Или project_lastVersion_1?
— …

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

В статье я расскажу о наиболее актуальных и используемых вариантах контроля версий, а именно: Zeplin (+ Sketch), Figma, Abstract (+ Sketch), то есть опишу функции и особенности этих инструментов, относящиеся именно к версионированию.

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

Недавно мы писали о том, как работают IT-архитекторы, а теперь расскажем подробности об одном из наших кейсов и покажем схему работы системы. В этом проекте мы помогли заменить «коробочное» банковское приложение на микросервисное ДБО, при этом наладив быстрый выпуск релизов – в среднем 1 раз в неделю.