Насколько похожи должны быть среды PreProd и Prod?

Я только недавно был над проектом, и во время релиза мы поняли, что он не работает в Production. Он работает во всех других средах, но поскольку у нас есть отдельная команда релизов, и мы не можем сами настроить серверы и среды, мы не видим их конфигурации.

Мы подозреваем, что Prod имеет некоторые пользовательские разрешения в своей учетной записи или настройки IIS, которые отличаются, поэтому мы работаем, хотя сейчас.

Поэтому я думаю, что все это стало для меня опытом обучения, и я не хочу, чтобы это повторилось снова. Я хотел бы спросить, насколько должны отличаться эти среды? Я всегда думал, что PreProd должен быть идентичной копией среды Prod, используя копию той же базы данных, используя копию той же учетной записи пользователя, должен быть установлен на тех же серверах и т. Д.

Но как далеко я должен взять это? Если веб-сайт обращен наружу, должен ли PreProd быть внешним? Что если на веб-сайте есть компоненты, для которых не требуется учетная запись или пароль пользователя? Это все еще нормально выставлять это внешнему миру?

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

Очевидно, что будут вещи, которые вы не захотите идентичные - на ум приходят ссылки на платежные системы, но их следует высмеивать, как если бы они были настоящими . Есть также вещи, которые вы не можете воспроизвести - масштаб системы.

Возможно, вы захотите проверить по внешнему URL-адресу - снова вы тестируете то, что увидят ваши пользователи. Также тестирование через внешний URL-адрес будет использовать сеть не так, как внутреннее использование системы. Разрешения (например) будут играть роль, как и доступная пропускная способность, брандмауэры и т. Д. Все это будет с пользователями, но вы пропустите, если получите доступ к системе напрямую.

Я не вижу проблемы с компонентами, которые не требуют учетной записи и пароля, хотя. Если ему не нужен пароль, то он не является жизненно важным / чувствительным, если он чувствителен, то почему у него нет пароля?

Я думаю, что лучшей практикой для этого является подход «Blue Green Deployment», разработанный Джезом Хамблом и Дэвидом Фарли в их книге «Непрерывная доставка» и описанный Мартином Фаулером в его блоге « Blue Green Deployment» .

Предпосылка очень проста. Из поста Мартина Фаулера:

Сине-зеленый подход к развертыванию ... [гарантирует], что у вас есть две производственные среды, максимально идентичные. В любой момент, скажем, синий, например, живой. Когда вы готовите новую версию своего программного обеспечения, вы проходите финальную стадию тестирования в зеленой среде. Когда программное обеспечение работает в зеленой среде, вы переключаете маршрутизатор, чтобы все входящие запросы перешли в зеленую среду - синий теперь бездействует.

Сине-зеленое развертывание также дает вам быстрый способ отката - если что-то пойдет не так, переключите маршрутизатор обратно в синюю среду.

Этот подход решит вашу проблему отсутствия идентичных пред-производственных и производственных сред, а также оптимизирует вашу стратегию развертывания.

Наша конечная среда подготовки к работе - это просто один из работающих серверов, снятых с балансировщика нагрузки. Мы развернем нашу предварительную сборку (которая в основном идентична оперативной сборке, за исключением строк подключения к базе данных и нескольких других изменений конфигурации) и протестируем это. Если все в порядке, мы развертываем оперативный код, и, наконец, если все в порядке, мы возвращаем сервер балансировщику нагрузки и разворачиваем производственную сборку на оставшиеся серверы один за другим.

Они должны быть максимально похожими, чтобы вы могли выявлять проблемы в любой точке системы, за исключением невозможности масштабирования. Если это вообще возможно, единственным различием между вашей производственной средой и средой подготовки к работе / промежуточной обработки / тестирования будет размер - я ожидаю, что производственная среда будет состоять из гораздо большего количества машин в крупномасштабной среде. Вы даже должны отражать выделение компьютеров, которые у вас есть, таких как серверы баз данных, веб-серверы и так далее.

Однако точная репликация может оказаться невозможной при вашем текущем бюджете. Чем оно ближе, тем более эффективным будет тестирование и тем меньше вероятность возникновения проблем во время пуска в производство.

Я придерживаюсь иной позиции, чем ChrisF, в том, что эта среда должна быть публичной. Я говорю, что это не должно быть. Я бы предпочел запустить копию реальных баз данных или, по крайней мере, копию подмножества реальных действующих баз данных и обращенной внутрь среды. Таким образом, вы можете проверить реальные и реалистичные данные и не беспокоиться о дырах в безопасности, которые могут привести к утечке. Конечно, вы можете очистить данные, но это может привести к удалению из среды «грязных данных», которые могут привести к обнаружению дефекта в работающей системе.

Везде, где я работал, в банках, телекоммуникациях и т. Д. Pre-prod был прямой копией продукции, за исключением того, что база данных была бы недельной давностью или около того. Это был массовый процесс, поддерживающий данные в рамках pre-prod, но он считался важным для тех компаний, в которых я работал, которые внедрили pre-prod.

В банковской секции AU правительство штрафует банки за сбои в обслуживании, например, банкоматы на веб-сайтах и ​​т. Д. Не работают каждую минуту. Нередко можно услышать о команде разработчиков / тестировщиков, уволенных за инцидент. Pre-prod не для каждой компании или процесса разработки, но необходим для некоторых.