Comments 29
Статья интересная, но ещё более хороший пример, как делать не надо. По факту Вы придумали свою костыльно-велосипедную систему контроля версий. Может в качестве запасного (дублирующего) средства и пойдёт, но в таком случае в будущем Вы столкнётесь с рассинхронизацией пакетов в Ваших таблицах и в основной системе контроля версий. В общем статья хорошая, идея так себе. Заведите лучше аккаунт на гитхабе и там храните Ваши процедуры. Целее будут.
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах? Мы живёл не в идеальном мире и такое происходит сплошь и рядом и далеко не всегда это вредительство, часто это исправления на лету, так как не всё оттестировали, а править надо. Так же можно поправить много объектов и забыть что правил если чинил аварию, а этот механизм поможет понять что и кто изменил и отразить это уже в контроле версий приложения.
После того, как один мой коллега (но не я) разок во время аврала выполнил «DELETE FROM my_table» вместо «DELETE FROM my_table WHERE ...» (IDE позволяет выделить часть кода и выполнить только ее), стали все скрипты гонять как миграции БД, даже если все горит.
А кто руками что-то правил — просили не делать и показывали результаты нарушения техники безопасности работы с production.
Сделали 3 инстанса БД — production, qa, dev.
qa — копия production (на несколько дней/недель отстает).
dev — схема точно такая же, но данных меньше (скажем, не 100М строк, а 10К). Перед каждым прогоном автоматически восстанавливается из бэкапа.
Пишешь скрипт, тестишь руками на dev. Когда готово — гоняешь на dev уже полностью, причем начальное состояние dev каждый раз одно и то же.
Если есть время — гоняешь еще на qa, если все горит — запускаешь на production и держишь кулачки.
А кто руками что-то правил — просили не делать и показывали результаты нарушения техники безопасности работы с production.
Сделали 3 инстанса БД — production, qa, dev.
qa — копия production (на несколько дней/недель отстает).
dev — схема точно такая же, но данных меньше (скажем, не 100М строк, а 10К). Перед каждым прогоном автоматически восстанавливается из бэкапа.
Пишешь скрипт, тестишь руками на dev. Когда готово — гоняешь на dev уже полностью, причем начальное состояние dev каждый раз одно и то же.
Если есть время — гоняешь еще на qa, если все горит — запускаешь на production и держишь кулачки.
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах?
Контроль версий тут конечно не поможет, здесь помогут массовые расстрелы, казни и прочие репрессии.
Уже правильно советовали, все изменения в БД через миграции, миграции в VCS. У разработчиков и тестеров не должно быть доступа к боевым базам, плюс, по-хорошему, у каждого разработчика своя копия БД. Всё это дисциплинирует, и разработчики забывают, что можно руками что-то там править в БД.
Простите, а какую задачу вы решаете, и почему вам не подходят традиционные системы управления версиями?
К сожалению не все коммитят абсолютно все изменения в гит. Данная реализация решает эту задачу
А еще эту задачу решает реализация "изменения попадают в БД только из гита". Потому что в гите-то они все равно должны быть.
«Контроль версий внутри Sql server'a» != «Бест практис версионирования объектов БД»
для DEV (а иногда и TEST) среды это далеко не всегда вариант
решение автора не отменяет использование GIT (или его альтернативы)
из моего опыта — вариант автора использовался на DEV\TEST среде что найти виновного в поломке, ибо DEV и TEST базы были в единственных экземплярах и если что-то существенное ломалось могло затронуть работу многих
ну все что было на проде соответствовало тому что лежит в master гита
решение автора не отменяет использование GIT (или его альтернативы)
из моего опыта — вариант автора использовался на DEV\TEST среде что найти виновного в поломке, ибо DEV и TEST базы были в единственных экземплярах и если что-то существенное ломалось могло затронуть работу многих
ну все что было на проде соответствовало тому что лежит в master гита
ибо DEV и TEST базы были в единственных экземплярах и если что-то существенное ломалось могло затронуть работу многих
Это очень, очень, очень печальная история (это говорит человек, который в таком режиме работал и бросил).
По факту это очень часто встречается. При том, на продакшене может быть настроено всё по лучшим практикам, но вот ресурсы на дев и прочие стейджинги выделяются по остаточному принципу. Как вычислительные ресурсы, так и человеческие. :( И если по проблемам на продакшене потом часто проводится анализ причин и принятие комплекса технических и административных мер, минимизирующих повторение инцидентов такого типа, то на дев средах в лучшем случае принимаются минимальные организационные меры типа «кто ещё раз свои миграции не откатит при уходе со своей ветки — премии не получит».
честно говоря чего я уже не насмотрелся за 13 лет, удивить и испугать меня сложно :)))
конкретно в том случае были большие сложности с поддержанием более чем одной DEV\TEST базы — приложение было сложным монолитом с огромным числом логики в базе, позднее его распилили на микросервисную архитектуру, но почему-то проще оно от этого не стало :)))
вот и жили вот так, понятное дело что такое себе удовольствие, но со временем привыкаешь и учишься по быстрому разгребать случаи когда чье-то неудачное изменение в базе становится проблемой для многих
конкретно в том случае были большие сложности с поддержанием более чем одной DEV\TEST базы — приложение было сложным монолитом с огромным числом логики в базе, позднее его распилили на микросервисную архитектуру, но почему-то проще оно от этого не стало :)))
вот и жили вот так, понятное дело что такое себе удовольствие, но со временем привыкаешь и учишься по быстрому разгребать случаи когда чье-то неудачное изменение в базе становится проблемой для многих
Ну так введите правило — коммитят все. Как минимум один раз в конце дня.
По-моему правильное решение выглядит так.
Лёша: ребята кто то видел Юлю?
Максим: она не коммитила…
Серёжа: давно пора!
может все же liquibase или подобное?
Может и liquibase. Это всего лишь еще одна реализация версионирования, не претендующая на трон. Уповаю что и такое принесёт кому-то пользу
Заюзали у себя год назад liquibase и куча проблем ушла :) Еще плюс, если нет хранимок, то код разворачивается в любой СУБД (решили мигрировать на другой движек и, вуаля, БД уже есть)
Проблемы со структурой базы и хранимками легко решаются. А вот что делать с версионностью миграций данных? Да ещё и в определённой последовательностью с dml запросами.
На оракле столкнулся с такой проблемой, решаю так (+git):
https://github.com/stepanho/ora-sourcecontrol
Изините, это антипаттерн какой-то.
У вас абстрактный конь в ваккуме или есть продукт?
Обычно есть до десятка ветвей продукта — типа sandbox, main, version 2, subversion 2.1, subversion 1.0, service pack 1.1, feature pack 1.1a, custom user pack 1.1.aSiemens, и так далее.
У вас тикеты есть? Типа там feаture request, баги? С номерами сроками, -pre-review, post-review?
Unit tests, functional tests, load tests,…
Или у вас хуяк-хуяк и в продакшн?
Обычно есть до десятка ветвей продукта — типа sandbox, main, version 2, subversion 2.1, subversion 1.0, service pack 1.1, feature pack 1.1a, custom user pack 1.1.aSiemens, и так далее.
У вас тикеты есть? Типа там feаture request, баги? С номерами сроками, -pre-review, post-review?
Unit tests, functional tests, load tests,…
Или у вас хуяк-хуяк и в продакшн?
Статья представленна в классическом отвратно-замусоренном стиле «программист плюёт в вечность». Т.е. через пень-колоду объясняется идея, после чего статья засыпается простынями листингов (которые, очевидно, никто не читает), после чего пишется оптимистичная концовка «вот так мы строили-строили и наконец построили!». По литературе за изложение мыслей вам 2 балла. И отдельно 2 балла (от «трудовика» ггг) за самое худшее решение по версионированию.
Вот вам гениальная идея, чтобы знали куда развиваться: используйте DDL триггеры, чтобы создавать уведовления «такой-то чел сделал то-то». Уведомления накапливаются, агрегируются по юзерам и, скажем, в 3 дня засовываются в тикеты. После этого КАЖДЫЙ залезает в тикеты и просматривает, где-что он натворил, создаёт апдейт-скрипт и вуаля — пушит в гитхаб.
Таким образом вы и версионирование поддерживаете НОРМАЛЬНЫМИ, ПРОФЕССИОНАЛЬНЫМИ средствами, и изменения в базе не проходят незамеченными.
Но в вашем случае виноват ещё и бардак (коий софтом не лечится) — боритесь за дисциплину, безалаберные кодеры пусть учатся дома, а на работе — будь добр, отвечай за сделанное.
Вот вам гениальная идея, чтобы знали куда развиваться: используйте DDL триггеры, чтобы создавать уведовления «такой-то чел сделал то-то». Уведомления накапливаются, агрегируются по юзерам и, скажем, в 3 дня засовываются в тикеты. После этого КАЖДЫЙ залезает в тикеты и просматривает, где-что он натворил, создаёт апдейт-скрипт и вуаля — пушит в гитхаб.
Таким образом вы и версионирование поддерживаете НОРМАЛЬНЫМИ, ПРОФЕССИОНАЛЬНЫМИ средствами, и изменения в базе не проходят незамеченными.
Но в вашем случае виноват ещё и бардак (коий софтом не лечится) — боритесь за дисциплину, безалаберные кодеры пусть учатся дома, а на работе — будь добр, отвечай за сделанное.
по поводу <> не оно?
declare @xml xml = '<root><cmd>
declare @i int = 1
select @i = case when ISNULL(@i,0)<>0 then -1 else 1 end
select @i
</cmd></root>'
declare @cmd nvarchar(max) = @xml.query('//cmd').value('.', 'nvarchar(max)')
select @cmd
exec (@cmd)Sign up to leave a comment.
Контроль версий внутри SQL Server'a