На самом деле про логарифмирование и регрессию — думал и пробовал. Не очень хорошо получилось. Мне кажется это из-за «длинного хвоста» долгих заявок, которые здорово выбиваются даже на логарифмической шкале. Поэтому я решил пока свести все к задаче классификации.
В VS2017 доступны два типа DB проектов — «стандартный» и новый RedGate ReadyRoll.
Стандартный проект при развертывании использует концепцию «desired state»: что в проекте — то будет и на целевой базе.
Для развертывания изначально проект собирается или в скрипты, или в файл .dacpac. Из dacpac можно развертывать на базу с помощью sqlpackage.exe — он выявляет разницу в состоянии целевой базы и пакета, и накатывает разницу на лету (там очень много параметров и настроек — в частности целевую базу можно даже забэкапить автоматически перед накатом).
Целевой базы может не быть — тогда они будет создана «с нуля».
Можно заставить процесс развертывания удалять объекты, которых нет в проекте — очень удобно для расчистки базы от следов «прямого вмешательства программистов», оставляющих после себя "_backup" версии объектов. При этом удаление таблиц или колонок не происходит если там есть данные.
Что касается конфигурации системы — это тоже (хотя бы то, что определено как минимальная конфигурация) хорошо держать в репозитории. В проекте есть понятие pre- и post-deployment скриптов — они как раз и могут накатывать конфигурацию.
Этот тип проекта + системы контроля версий кода + разумная стратегия branching & merging = вполне жизнеспособно для вашего сценария с многими разработчиками, dev/test/prod ландшафтом итд.
Посмотрите в сторону Visual Studio Team Services или TFS 2015/2017. Это решит почти все — хранение исходников, билды, развертывание на свои сервера или в Azure.
Второй тип проекта, ReadyRoll, подразумевает, что в проекте хранятся скрипты изменений, которые необходимо накатывать по очереди.
В целевой базе создается дополнительная таблица, в которой автоматически ведется учет — какие скрипты были применены.
Подход хорош при необходимости много таскать скриптов с модификацией данных. Но мне как-то этот подход кажется более хрупким, если основная задача — управлять кодом объектов и структурой таблиц.
Дело в том, что задача, которая изначально стояла перед нами — это «проверка корректности работы правил экспертной системы» (поверхностно я обмолвился по этому поводу в начале).
При такой постановке принципиально нужно формулировать тест в терминах «входные данные» + «правильный ответ», причем как-раз «правильный ответ» составляет суть бизнес требований к экспертной системе.
Т.е. если бы даже можно было бы создать довольно полный набор входных данных, их преобразование в «правильный ответ» не может быть сделано автоматически — это как раз задача подсистемы которую мы тестируем.
Что касается полноты тестового покрытия в нашем случае. Я могу только приблизительно оценить количество полных вариантов для одного правила — примерно 400 возможных адекватных бизнес-сценариев (про неадекватные, которые заказчик называет «exception», я даже говорить не хочу). Отдельные нюансы покрываются юнит тестами.
У нас есть на данный момент в среднем 40-50 сценариев на правило, но они покрывают наиболее вероятные сценарии — около 90% бизнес ситуаций.
Так что «техническое» покрытие выглядит незначительным — около 10%, и это не очень хорошо. Но поскольку мы не тестируем полностью «черный ящик», с точки зрения заказчика мы покрываем тестами около 90% ситуаций.
Стандартный проект при развертывании использует концепцию «desired state»: что в проекте — то будет и на целевой базе.
Для развертывания изначально проект собирается или в скрипты, или в файл .dacpac. Из dacpac можно развертывать на базу с помощью sqlpackage.exe — он выявляет разницу в состоянии целевой базы и пакета, и накатывает разницу на лету (там очень много параметров и настроек — в частности целевую базу можно даже забэкапить автоматически перед накатом).
Целевой базы может не быть — тогда они будет создана «с нуля».
Можно заставить процесс развертывания удалять объекты, которых нет в проекте — очень удобно для расчистки базы от следов «прямого вмешательства программистов», оставляющих после себя "_backup" версии объектов. При этом удаление таблиц или колонок не происходит если там есть данные.
Что касается конфигурации системы — это тоже (хотя бы то, что определено как минимальная конфигурация) хорошо держать в репозитории. В проекте есть понятие pre- и post-deployment скриптов — они как раз и могут накатывать конфигурацию.
Этот тип проекта + системы контроля версий кода + разумная стратегия branching & merging = вполне жизнеспособно для вашего сценария с многими разработчиками, dev/test/prod ландшафтом итд.
Посмотрите в сторону Visual Studio Team Services или TFS 2015/2017. Это решит почти все — хранение исходников, билды, развертывание на свои сервера или в Azure.
Второй тип проекта, ReadyRoll, подразумевает, что в проекте хранятся скрипты изменений, которые необходимо накатывать по очереди.
В целевой базе создается дополнительная таблица, в которой автоматически ведется учет — какие скрипты были применены.
Подход хорош при необходимости много таскать скриптов с модификацией данных. Но мне как-то этот подход кажется более хрупким, если основная задача — управлять кодом объектов и структурой таблиц.
При такой постановке принципиально нужно формулировать тест в терминах «входные данные» + «правильный ответ», причем как-раз «правильный ответ» составляет суть бизнес требований к экспертной системе.
Т.е. если бы даже можно было бы создать довольно полный набор входных данных, их преобразование в «правильный ответ» не может быть сделано автоматически — это как раз задача подсистемы которую мы тестируем.
Что касается полноты тестового покрытия в нашем случае. Я могу только приблизительно оценить количество полных вариантов для одного правила — примерно 400 возможных адекватных бизнес-сценариев (про неадекватные, которые заказчик называет «exception», я даже говорить не хочу). Отдельные нюансы покрываются юнит тестами.
У нас есть на данный момент в среднем 40-50 сценариев на правило, но они покрывают наиболее вероятные сценарии — около 90% бизнес ситуаций.
Так что «техническое» покрытие выглядит незначительным — около 10%, и это не очень хорошо. Но поскольку мы не тестируем полностью «черный ящик», с точки зрения заказчика мы покрываем тестами около 90% ситуаций.
Как-то так…