Должны ли данные UAT быть зеркалом производства? И если да, то как?

Question

Мы обсуждали идею о том, что UAT можно протестировать с данными, близкими к живым (скажем, максимум за неделю). Я твердо верю, что среды разработки и контроля качества должны контролировать свои собственные данные, но UAT (последний уровень перед производством) представляет собой некоторую "серую область". Итак, мои вопросы:

а) это хорошая идея? Я так думаю, но сомневаюсь.

б) если да, то каковы некоторые проверенные методы, которые люди использовали в прошлом?

• вручную через SqlCompare или подобное
• автоматизировано с помощью сценариев?
• как вы справляетесь с вариациями схемы между UAT/Production (UAT почти всегда будет опережать Production, кроме как сразу после оперативного развертывания)?

Answer 1

(при условии, что OP предполагает непрерывную схему в реальном времени и синхронизацию данных)

Короткий ответ:

• Схема - Нет - в развивающейся системе, находящейся в стадии разработки, UAT, вероятно, уже будет опережать производство, и в UAT будут внесены изменения, предназначенные для будущих развертываний производства.
• Данные - возможно (для получения хороших, свежих, репрезентативных данных), хотя, возможно, потребуется адаптировать любые различия в схемах. Альтернативой может быть применение ложного генератора данных.

обоснование

Под "зеркалом" я предполагаю, что вы не имеете в виду прямое зеркалирование или репликацию в режиме реального времени (для тестирования UAT обычно требуются кропотливые контрольные примеры данных, которые будут перезаписаны).

Вот как мы это делаем в корпоративной среде, FWIW

Через определенные промежутки времени, как правило, примерно через 1 месяц

• Последняя резервная копия базы данных prod восстанавливается в среде QA (обновление UAT)
• Сценарий "преобразования" среды запускается для каждой базы данных, обновляемой после восстановления (например, для точного конфигурирования или для маскировки конфиденциальных финансовых, клиентских или пользовательских данных и т. Д.)
• Все сценарии UAT, которых еще не было в PROD, затем запускаются с базами данных (вам понадобится хорошая дисциплина с контролем изменений в управлении сценариями, чтобы легко отслеживать это - мы все еще не всегда понимаем это правильно). После обновления мы не сравниваем напрямую UAT и QA, а просто возвращаем изменения обратно в UAT.
• Это служит хорошим тестированием / отладкой дыма, так как эти же сценарии vNext необходимо будет запускать против Production в момент выпуска Production.
• Современные системы могут не требовать явных / внешних сценариев миграции версий (например, при первом запуске Entity Framework Code First попытались бы обновить схему базы данных), хотя это может быть связано с риском при применении их к устаревшим или общим базам данных.

Некоторые другие соображения

• В корпоративной среде, где системы интегрированы друг с другом, рекомендуется обновлять все базы данных системы одновременно, чтобы общие данные и ключи были "синхронизированы".
• Во многих корпорациях изменения в среде UAT (включая обновления данных) могут потребовать одобрения платы управления изменениями, поскольку доступность UAT имеет решающее значение для развертывания новых систем и может повлиять на многие проекты.

Просто обратите внимание на цикл 'script' для синхронизации схем - в наших средах:

• DEV бесплатен для всех - любой разработчик может внести изменения в DDL или данные.
• QA и UAT заблокированы - сценарии должны быть сгенерированы (обычно SQLCompare) и затем отправлены администраторам баз данных для выполнения (в QA) и утверждения и выполнения (UAT). (Мы ищем способы автоматизации развертывания в QA, однако нам нужно сохранить каждый скрипт в SCM)
• Эти сценарии затем проверяются в системе контроля версий и отслеживаются "для каждой среды".

Answer 2

Вот что мы сделали для последней компании, в которой я работал. У нас было много государственных проектов и контрактов. Вот пример нашего уровня окружения, которое мы использовали в некоторых проектах. В приведенном ниже примере QA был для нас, UAT был для клиента, а Pre-Prod был другой средой, которую мы иногда создавали, но не всегда; просто в зависимости от проекта.

DEV ==> QA ==> UAT ==> PRE-PROD ==> PROD

Как только все данные были проверены, мы скопировали из Prod в UAT и QA практически все, включая все, что связано с БД.

У нас также был инструмент, который был написан для некоторых аспектов без необходимости всегда использовать SQL. У нас была веб-программа, и я не могу вспомнить, в чем она была написана. Мы назвали ее CTM - Control Table Management. Там мы можем вносить определенные изменения в таблицы, такие как обновления, исправления, выпадающие меню, орфографические и грамматические ошибки, и в действительности просто любые ошибки. что-нибудь. Были переключатели для фиксации изменений и поля для проверки того, в какие среды вы хотите откатить изменения.

Надеюсь, что это поможет кому-то там или дать людям некоторые идеи.:-)

Спасибо,

Джон