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

Question

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

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

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

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

Answer 1

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

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

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

Обоснование

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

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

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

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

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

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

Просто примечание о цикле «сценарий» для синхронизации схем - в наших условиях:

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

Answer 2

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

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

После того, как все данные были проверены, мы скопировали вниз от Prod до ЕСХН и QA чуть обо всем, в том числе все, DB Связанный.

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

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

Спасибо,

Джон