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

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

4 голосов
/ 01 марта 2012

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

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

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

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

Ответы [ 2 ]

5 голосов
/ 01 марта 2012

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

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

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

Обоснование

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо,

Джон

...