Наскільки подібними повинні бути середовища PreProd та Prod?

Я нещодавно був у проекті, і під час випуску ми зрозуміли, що це не працює у виробництві. Він працює у всіх інших середовищах, але оскільки у нас є окрема команда випуску, і ми не можемо самостійно налаштувати сервери та середовища, ми не маємо видимості конфігурації на них.

Ми підозрюємо, що Prod має деякі користувацькі дозволи у своєму обліковому записі чи налаштування IIS, які відрізняються, тому ми працюємо над цим зараз.

Тому я думаю, що все це було для мене досвідом навчання, і я не хочу, щоб те саме повторювалося знову. Я хотів би запитати, наскільки різними повинні бути ці середовища? Я завжди вважав, що PreProd має бути ідентичною копією середовища Prod, використовуючи копію тієї ж бази даних, використовуючи копію одного і того ж облікового запису користувача, слід встановлювати на тих же серверах і т.д.

Але як далеко я повинен це взяти? Якщо веб-сайт має зовнішню сторону, чи повинен PreProd бути зовні? Що робити, якщо на веб-сайті є компоненти, які не потребують облікового запису користувача або пароля для навігації? Чи все-таки добре це піддавати зовнішньому світу?

Ви, звичайно, повинні проходити тестування на середовищі, яке є ідентичним вашим виробником, наскільки це можливо. Якщо ви цього не зробите, ви не тестуєте, чим користуватимуться ваші клієнти. Якщо нічого іншого вам не потрібне таке середовище, щоб перевірити будь-які повідомлення про помилки.

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

Можливо, ви захочете протестувати через зовнішню URL-адресу - знову ви тестуєте те, що побачать ваші користувачі. Також тестування за допомогою зовнішньої URL-адреси використовуватиме мережу по-іншому, ніж внутрішнє використання системи. Дозволи (наприклад) будуть грати певну роль, як і доступна пропускна здатність, брандмауері тощо. Усі користувачі зіткнуться з цим, але ви пропустите, якщо матимете прямий доступ до системи.

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

Я вважаю, що найкращою практикою для цього є підхід Blue Green Deployment, сформований Джезом Хемблом та Девідом Фарлі в їхній книзі «Постійна доставка» та описаний Мартіном Фаулером у своєму дописі в блозі Blue Green Deployment .

Приміщення дуже просте. З поста Мартіна Фаулера:

Синьо-зелений підхід до розгортання ... [гарантує] у вас два виробничих середовища, максимально однакові. У будь-який час одна з них, скажімо, для прикладу синій, - це жива. Під час підготовки нового випуску програмного забезпечення ви проводите останню стадію тестування в екологічному середовищі. Після того, як програмне забезпечення працює в зеленому середовищі, ви перемикаєте маршрутизатор так, щоб усі вхідні запити переходили до зеленого середовища - синій тепер не працює.

Синьо-зелене розгортання також дає вам швидкий шлях до відкату - якщо щось піде не так, ви переключите маршрутизатор назад у синє середовище.

Такий підхід вирішить вашу проблему відсутності однакового середовища передвиробництва та виробництва, а також оптимізації вашої стратегії розгортання.

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

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

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

Я займаю іншу позицію, ніж ChrisF, якщо це середовище має бути загальнодоступним. Я кажу, що цього не повинно бути. Я б вирішив працювати на копії фактичних баз даних або, принаймні, на копії підмножини фактичних реальних баз даних та навколишнього середовища. Таким чином, ви можете перевірити фактичні та реалістичні дані та не турбуватися про безпечні отвори, що призводять до витоку. Можна, звичайно, санітувати дані, але це може видалити з середовища "брудні дані", які можуть призвести до виявлення дефекту в живій системі.

Скрізь, де я працював у банках, телекомунікаціях та ін., Попередня продажа була прямою копією виробництва, за винятком того, що база даних була б тиждень або близько того. Це був масивний процес збереження даних у межах попереднього продукту, але він вважався важливим для компаній, в яких я працював.

У розділі банківської служби АС уряд штрафує банки за невиконання обслуговування, наприклад, банкомати на веб-сайтах тощо, щохвилини знижуються. Не рідкість чути про те, що команда розробників / тестувань звільнилася через інцидент. Попередня пропозиція не для кожної компанії або процесу розробки, але важлива для деяких.