#sql-server #git #version-control
#sql-server #git #контроль версий
Вопрос:
Хорошо, это вопрос, чтобы узнать, могу ли я получить некоторую помощь с идеями для решения этой проблемы.
Прежде всего, мы работаем со сценариями транзакций SQL Server, поэтому это не обычное кодирование, поэтому, например, переключение функций сложно реализовать (возможно вообще?).
Хорошо, наша проблема заключается в следующем:
- Задача 1: Добавить столбец в таблицу X
- Задача 2: удалить таблицу Y и изменить 3 хранимые процедуры, связанные с этой таблицей.
- Задача 3: усечь таблицу Z
И у нас есть три разных сервера, DEV -> TEST -> PROD.
НО! Поскольку это SQL, мы можем реализовать задачу 1 на DEV, задачу 2 на Test и Prod, но не на dev, а задачу 3 только на test.
И это тоже может изменить ход событий. Итак, внезапно нам нужно добавить задачу 2 в dev или задачу 3 в prod и так далее.
Сложно.
Это означает, что традиционный способ мышления заключается в переносе продукта, которым вы довольны, из DEV в TEST, а когда пользователи довольны тестированием, переместите этот полный продукт в PROD. Поскольку мы здесь не говорим о «полных продуктах», а вместо этого меняем наборы, которые должны быть реализованы на разных серверах в разное время, я немного не уверен в существующей передовой практике?
Есть ли в этом какая-то мысль, которую я могу прочитать, или у вас есть отличные предложения?
Спасибо!
Комментарии:
1. Я не уверен, что следую вашему утверждению «Поскольку это SQL, мы можем реализовать задачу 1 на DEV, задачу 2 на Test и Prod, но не на dev и задачу 3 только на test». Вы предполагаете, что можете применить изменения к тестированию / разработке, которые они разрабатывают? Рассмотрите возможность использования стратегии ветвления функций как для работы с БД, так и с приложениями, объединяясь в ветви интеграции, когда будете готовы.
2. Да, у нас могут быть изменения, реализованные только в test и prod, а не в dev (по множеству разных причин).
3. ИМХО, подход к сценариям миграции вручную (т. Е. «Задачи») будет кошмаром без знания состояния целевой базы данных. Рассмотрите возможность использования инструментов на основе моделей (например, SSDT) для облегчения создания сценариев развертывания. Разработка стратегии управления версиями без определенного SDLC будет сложной задачей.
Ответ №1:
Я не уверен, что понимаю вас на 100%, но настройка, которую вы описываете, в точности соответствует тому, как моя компания управляет своими развертываниями для SQL Server с использованием git.
У нас есть 3 сервера, мы просто используем разные имена DEV -> STAGE -> PROD .
Что касается ваших задач, я не уверен, что полностью понимаю вашу проблему.
Для нас все изменения проходят через все 3 сервера и всегда в одном и том же порядке.
Вся работа выполняется на сервере разработки, когда она завершена, изменения возвращаются в git.
Затем наш администратор базы данных развертывает эти изменения в STAGE для мониторинга и для QA для запуска автоматических тестов и регрессионного тестирования.
Если все выглядит хорошо, тогда мы планируем дату выпуска и внедряем изменения в PROD.
Комментарии:
1. Проблема в том, что наши задачи не всегда развертываются на всех трех серверах. Если у вас 10 задач. 1, 2, 5, 7 и 10 могут быть развернуты в DEV, 3, 4, 5, 6, 7, 8 для ТЕСТИРОВАНИЯ и, наконец, 1, 5 и 10 для ПОДТАЛКИВАНИЯ. Это старое наследие, и его трудно изменить. Вопрос в том, существует ли стандарт git для его обработки.