Версионная установка по умолчанию / настроенные триггеры и хранимые процедуры

Question

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

Как бы вы порекомендовали подходить к этой проблеме с технической точки зрения?как личная перспектива?

Редактировать 1: Небольшая справка о нашем текущем процессе может помочь в этом.Мы используем сервер непрерывной интеграции (TeamCity) для генерации артефактов установки и маркировки svn при регистрации. Я использую NMigrations для управления схемой и изменениями sp / trigger при применении исправлений.К сожалению, я не могу остановить несанкционированные изменения схемы, поэтому мне бы очень хотелось найти шаблон проектирования, который позволяет переопределить определение триггера / sp.

Answer 1

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

Answer 2

Вам необходимо четко отделить:

• управление исходным кодом
• управление выпуском

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

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