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

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

Переваги для бізнесу очевидні:

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

Щоб ефективно вирішувати нові задачі, команди розробки та підтримки повинні знати стратегії розгортання та уміти їх використовувати в залежності від ситуації.

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

“Big Bang” Deployment

Розвертання всього і зразу. Цей підхід набув популярності в часи коли ПЗ випускалась на фізичних носіях і встановлювалось клієнтом самостійно. Даний підхід вимагає від бізнесу довготривалої розробки та тестування. Його часто асоціюють з “Waterfall” методологією розробки.

Сучасні програми мають перевагу в регулярному та автоматичному оновленні на стороні клієнта або сервера. Це робить метод “Big Bang” повільнішим і менш гнучким. Даний підхід неприйнятний для публічно доступного або критичного для бізнесу програмного забезпечення де відключення або злам несе величезні фінансові втрати. Повернення до попередньої версії може бути затратним по часу, дорогим або взагалі неможливим.

Rolling Deployment

“Rolling” або стратегія поступового накатування – підхід до розгортання ПЗ на великій кількості нод поступово. Оновлення може відбуватись як і на хмарних серверах, так і на окремих комп’ютерах фізично розташованих у вас в приміщенні. Початково, програмне забезпечення, оновлюється на одному або декількох інстансах, а далі, в залежності від результатів, якщо успішно – більше серверів оновлюється поступово.

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

Нижче на схемі можна побачити як це відбувається.

Blue-Green, Red-Black or A/B Deployment

Цю стратегію називають по різному, найпопулярніша назва – Blue-Green. Цей підхід є відносно безпечним варіантом розгортання ПЗ. Для його роботи потрібно 2 ідентичні копії середовища.

Перша копія (Blue)  це production версія на яку направлений весь трафік. Інша, її копія (Green), але недоступна для користувачів. Обидні використовують ту ж базу даних і конфігурацію.

Оновлення заливається на Green версію і тестується з точки зору функціональності та продуктивності. Якщо результати задовільняють – трафік перемикатися на Green версію і вона уже стає production. У випадку виникнення будь-яких проблем, завжди можна повернутися на попередню версію.

Даний підхід полягає на управлінні трафіком. Цього можна досягнути оновленням DNS CNAMES  або  зміною налаштування балансувальника навантаження (load balancer).

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

Цей підхід може бути ідеальним для систем розвернених в Cloud де виділення ресурсів є швидким і не дорогим.

Canary Deployment

Canary стратегія схожа на blue-green за винятком того що вона ще менш ризикована. Замість того щоб перемикатися з Blue на Green за один крок, ви використовуєте поетапний перехід.

З даним підходом, необхідно оновити лише частину production інфраструктури. Після цього лише частина користувачів направляється на оновлену версію. Це мінімізує будь-який вплив.

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

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

Traffic splitting

Розділення трафіку – варіант розгортання ПЗ під час якого можна порівняти результати двох різних версій. Цей тип ще часто називають A/B тестуванням.

Можна налаштувати Load balancer щоб він направляв користувачів на різні версії. При цьому можна вказати скільки відсотків повинні потрапляти на конкретну версію. При такому підході можна порівняти продуктивність або результати двох версій які працюють одночасно.

Приклад використання цього методу описаний Google Cloud Platform лабораторній роботі https://google.qwiklabs.com/focuses/639?parent=catalog і можна глянути нижче.

Your new App Engine app is extremely popular and the drumbeat for new features is constant. You want to ensure that you can get your upgrades out the door as soon as possible without the high cost of full-scale load testing and without adversely affecting your entire user base. What’s your best roll-out strategy? – Rely on traffic splitting in App Engine to start with a small percentage of users using the upgrade and then increasing the percentage over time until all users have it.

 

 

 

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Схожі статті