Comments 29
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах? Мы живёл не в идеальном мире и такое происходит сплошь и рядом и далеко не всегда это вредительство, часто это исправления на лету, так как не всё оттестировали, а править надо. Так же можно поправить много объектов и забыть что правил если чинил аварию, а этот механизм поможет понять что и кто изменил и отразить это уже в контроле версий приложения.
А кто руками что-то правил — просили не делать и показывали результаты нарушения техники безопасности работы с production.
Сделали 3 инстанса БД — production, qa, dev.
qa — копия production (на несколько дней/недель отстает).
dev — схема точно такая же, но данных меньше (скажем, не 100М строк, а 10К). Перед каждым прогоном автоматически восстанавливается из бэкапа.
Пишешь скрипт, тестишь руками на dev. Когда готово — гоняешь на dev уже полностью, причем начальное состояние dev каждый раз одно и то же.
Если есть время — гоняешь еще на qa, если все горит — запускаешь на production и держишь кулачки.
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах?
Контроль версий тут конечно не поможет, здесь помогут массовые расстрелы, казни и прочие репрессии.
Уже правильно советовали, все изменения в БД через миграции, миграции в VCS. У разработчиков и тестеров не должно быть доступа к боевым базам, плюс, по-хорошему, у каждого разработчика своя копия БД. Всё это дисциплинирует, и разработчики забывают, что можно руками что-то там править в БД.
Простите, а какую задачу вы решаете, и почему вам не подходят традиционные системы управления версиями?
А еще эту задачу решает реализация "изменения попадают в БД только из гита". Потому что в гите-то они все равно должны быть.
решение автора не отменяет использование GIT (или его альтернативы)
из моего опыта — вариант автора использовался на DEV\TEST среде что найти виновного в поломке, ибо DEV и TEST базы были в единственных экземплярах и если что-то существенное ломалось могло затронуть работу многих
ну все что было на проде соответствовало тому что лежит в master гита
ибо DEV и TEST базы были в единственных экземплярах и если что-то существенное ломалось могло затронуть работу многих
Это очень, очень, очень печальная история (это говорит человек, который в таком режиме работал и бросил).
конкретно в том случае были большие сложности с поддержанием более чем одной DEV\TEST базы — приложение было сложным монолитом с огромным числом логики в базе, позднее его распилили на микросервисную архитектуру, но почему-то проще оно от этого не стало :)))
вот и жили вот так, понятное дело что такое себе удовольствие, но со временем привыкаешь и учишься по быстрому разгребать случаи когда чье-то неудачное изменение в базе становится проблемой для многих
По-моему правильное решение выглядит так.
Лёша: ребята кто то видел Юлю?
Максим: она не коммитила…
Серёжа: давно пора!
На оракле столкнулся с такой проблемой, решаю так (+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,…
Или у вас хуяк-хуяк и в продакшн?
Вот вам гениальная идея, чтобы знали куда развиваться: используйте 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)
Контроль версий внутри SQL Server'a