Перейдите к стандарту "Рекомендации по изменению рабочих процессов в базе данных SQL"

Question

Перейдите к стандарту "Рекомендации по изменению рабочих процессов в базе данных SQL"

Фон

ASP.NET/C# Web App MS SQL

Производственная среда UAT Test Dev

Мы создаем патч-скрипты (XML и sql) с исходным кодом в Mercurial. У нас есть утилита cmd line, которая устанавливает исправления в БД (utitlity.exe install –patch) из папки Release пакетов сборки. Патчи содержат метаданные, которые помогают определить, когда патч должен запускаться, и мы регистрируем исправления, установленные в таблице в целевой БД. Все они были рассмотрены в трехлетнем вопросе:

Рекомендации по изменению рабочих процессов в базе данных SQL Server

Наша проблема / Твист

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

1. Новый клиент BA выполняет исследование системы и анализ соответствия. Из этого выходит документ с словом конфигурации о том, какие конфигурации приложения необходимо настроить. Обратите внимание, что некоторые из них могут также появляться постепенно. Нам нужно вставить эти новые конфигурации в систему для UAT разработчика и клиента.
2. Разработчик работает над запросом функции или исправлением ошибки. Новое изменение конфигурации вытекает из этого изменения. Конфигурация должна войти в систему для тестирования и продвижения до UAT и выше.
3. QA обнаруживает, что разработчик пропустил соответствующее изменение конфигурации. Эта конфигурация должна войти в систему для перехода на UAT и выше.
4. Сборка идет в UAT. Клиент выполняет приемочное тестирование, но обнаруживает, что он действительно хочет изменить другую несвязанную конфигурацию и продвигает ее вместе с изменениями. Другими словами, они обнаружили, что хотят изменить бизнес-процесс с помощью конфигурации. Конфигурация должна быть внесена в систему для продвижения в PRD.
5. Поскольку клиент работает в PRD, он может настроить параметры приложения. Эти конфигурации необходимо включить в систему для дальнейшей разработки и тестирования.

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

Наши попытки в процессе

а. У нас был член команды QA, который писал патчи (xml и sql) и проверял их. Для этого требуется сборка, чтобы убедиться, что они попадают в пакет. При таком подходе он действительно позаботился о пункте 1 выше, и мы развалились на другие пункты. Хорошая вещь для элементов, которые вошли в патчи, это была просто установка с помощью утилиты. б. Разработчик создал страницу конфигурации в приложении. Все конфигурации могут быть загружены и загружены через XML-документ, но для этого требуется, чтобы приложение работало. Для пункта 1 член команды QA вручную настроил конфигурации в приложении, а затем загрузил файл Config.xml. Этот файл XML будет использоваться для загрузки конфигураций в других средах. Мы бы использовали инструмент text diff, чтобы посмотреть на различия между файлами config.xml из разных сред. Это относится к пункту 1 и другим пунктам, но имеет проблемы. Проблемы заключались не во всех конфигурациях, внесенных в XML-документ (просто должен быть исправлен разработчиком), некоторые конфигурации не имели пользовательского интерфейса в приложении, поэтому вам все равно пришлось вручную перейти к базе данных, сравнивая XML документ с разницей в тексте был трудным в то время (смотрелся в основном из-за сортировки, но я уверен, что есть другие проблемы), XML не был очень удобочитаемым человеком, и, наконец, документ XML не позволял удалять существующие неправильные или устаревшие конфигурации. с. Недавно мы перешли к варианту B, но со временем для нового клиента мы только начали вручную отслеживать конфиги и продвигать их вручную (UI и DB) с помощью промо-акций. Излишне говорить много человеческих ошибок.

Итак, мы искали решения. В конце концов было бы здорово включить как можно больше автоматизации. Я смотрю на подход с использованием сценариев и просто сосредотачиваюсь на процессе, документации и смотрю на сравнение данных Redgate в дополнение к тому, что мы делали с сравнению в config.xml. С Redgate мы должны создавать представления, и нет никакого способа создать сценарии обновления из этого подхода, кроме как вручную обновить сценарии. Это по крайней мере позволяет сравнение без запуска приложения. Я также смотрю на извлечение конфигов из наших обычных патчей и создание системы, независимой от сборки (utility.exe –patch –config). Когда я говорю "сконцентрируйся на процессе", это будет что-то вроде того, что если мы сравниваем и находим изменение конфигурации, сообщаемое клиентом или нет, мы все еще пишем его сценарий, просто означает, что у нас должен быть процесс для быстрой повторной проверки установки конфигурации, прежде чем перейти к следующий уровень. Что касается документации, рассматривающей, как сделать исходный документ QA живым, а не предварительным документом. Цель состоит в том, чтобы попытаться повысить ясность и сократить недостающие конфигурации во время продвижения. К сожалению, это не улучшает скорость доставки.

У кого-нибудь есть какие-либо рекомендации или лучшие практики для передачи. Благодарю.

Answer 1

Могу ли я спросить, что именно вы подразумеваете под конфигурацией приложения? Я интерпретирую это как:

• Конфиг файлы в веб приложении
• Статические справочные данные внутри базы данных

Полное раскрытие Я работаю на Красные Ворота. Возможно, вам будет интересно взглянуть на Deployment Manager, это инструмент развертывания, который развертывает приложения, базы данных и конфигурацию. Это бесплатно до 5 проектов и целевых серверов.

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

Любая конфигурация приложения, которую необходимо изменить между средами, обрабатывается одним из следующих способов:

• Подстановка переменных в web.config. Инструмент позволяет указать значения переопределения для переменных в этих файлах и установить их для среды / сервера
• Подстановка файла web.config для каждой среды.
• Пользовательские сценарии PowerShell, которые запускаются до / после развертывания. Вы можете использовать их для выполнения пользовательского SQL на основе среды или сервера.
• Статические данные в базе данных, используя функцию статических данных SQL Source Control. Я написал сообщение в блоге о том, как предоставлять разные наборы статических данных для разных сред / клиентов.

Это позволяет вам контролировать исходные конфигурации приложений и развертывать их в разных средах.