У чому сенс постановки?

Я думав, що я це розробив, але прочитавши « Постійну доставку» (відмінна книга) я трохи розгублений. Вони говорять про наявність серверів для:

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

Я завжди думав, що інсценізація як функція UAT, але вони, схоже, мають постановку як окремий рівень. Отже, у цій схемі, яку функцію надавали б сервіси постановки?

Постановка ставить на місце цілі системи продуктів, але фактично їх ще не використовує. Коли вони переходять у користування, буде "виробництво". Ви повинні поставити все на місце, як воно буде використовуватися, протестуйте, а потім переверніть перемикач.

UAT зазвичай використовує "тестуюче" середовище, суттєво відрізняється від апаратного / програмного забезпечення / конфігурації, яке буде використовуватися у виробництві.

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

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

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

Отже, що ми робимо:

• Розвиток
  • включає безперервну інтеграцію та автоматизоване тестування
• тестування на випуск
  • моя група аналізує сам випуск
  • перегляд журналів установки
  • тестування відкату
• QA
  • тестування прийняття користувача

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

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

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

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

У відповідній примітці ось мої слайди з презентації, яку я щойно розповів, як працює наш процес випуску.

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

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

Я щойно натрапив на цю статтю про постановочні середовища, яка говорить

Постановка - це те, коли ви підтверджуєте відомі невідомі ваші системи.

Статтю варто прочитати повністю.