Для нашего сценария мы используем комбинацию № 3 и № 2. Если у нас есть новая сборка, мы заполняем пустые базы данных, устанавливаем вставки после развертывания, которые мы обычно используем, чтобы они не запускались, а затем заполняем данные после всей сборки/публикации. Я также склонен группировать связанные вставки, поэтому, если я вставляю 15 статусов, я добавляю их в один скрипт. Недостатком этого является то, что вам нужно убедиться, что ваш сценарий может быть повторно запущен и не вызовет проблем, поэтому вставка во временную таблицу, а затем выполнение левого соединения с вашей фактической таблицей может быть лучшим решением. Это снижает количество сценариев до более управляемого размера.
Для инкрементных выпусков я предпочитаю пакетную вставку с помощью Story (используя Scrum), чтобы связанные сценарии шли вместе. Это также помогает мне узнать, когда сценарий был запущен в производстве и его можно безопасно удалить из проекта.
Вы также можете подумать о том, чтобы иметь какую-то «справочную» базу данных, в которой вы храните только эталонные значения, а затем, возможно, такой инструмент, как Red-Gate Data Compare, чтобы получить соответствующий набор данных. Версия Pro может быть автоматизирована/скриптована, поэтому у вас может быть более простой способ получения новых данных для тестирования. Это может быть вашим лучшим решением в долгосрочной перспективе, поскольку вы можете легко настроить, какие таблицы вы хотите копировать, и установить фильтры для данных.
person
Peter Schott
schedule
28.05.2013
