Стратегія випуску канарки проти синього / зеленого

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

Моє розуміння синьо / зеленого випуску полягає в тому, що у вас є 2 дзеркальних виробничих середовища ("синій" і "зелений"), і ви натискаєте зміни відразу на всі вузли синього або зеленого кольору, а потім використовуєте мережеву магію для управління до яких користувачів перенаправляються користувачі через DNS.

Отже, перш ніж почати, якщо щось, про що я вже говорив, невірно, почніть, виправляючи мене!

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

• Чи існують сценарії, коли канарки віддають перевагу синьому / зеленому та навпаки?
• Чи існують сценарії, коли модель розгортання може реалізувати обидві стратегії одночасно?

Синьо-зелений випуск простіший і швидший.

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

Вам потрібно зробити випуск канарки, якщо ви не повністю впевнені, що нова версія буде функціонувати правильно у виробництві. Навіть якщо ви ретельний тестер, Інтернет є великим і складним місцем і завжди постає перед несподіваними викликами. Навіть якщо ви використовуєте функції перемикання функцій, вони можуть бути реалізовані неправильно.

Автоматизація розгортання вимагає зусиль, тому більшість організацій планують використовувати ту чи іншу стратегію кожного разу.

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

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

Я написав детальний нарис на цю тему тут: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

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

Синій / зелений:

Канарські:

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

Канарка

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

2. Йдеться про уявлення про ефективність нової версії (інтеграція з іншими програмами, процесором, пам'яттю, використанням диска тощо).

Синій / зелений:

1. Йдеться більше про передбачуваний випуск із нульовим простоєм.
2. Легкий відкат у разі відмови.
3. Повністю автоматизований процес розгортання

Ось деякі вбудовані визначення -

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

   

• Тестування A / B - Одночасно запускаються дві версії програми. Частина запитів надходить до кожного. Потім розробники можуть порівнювати версії.  
• Canary Release - Нова версія мікросервісу запускається разом зі старими версіями. Тоді ця нова версія може прийняти частину запитів, і команда може перевірити, як ця нова версія взаємодіє із загальною системою.

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

Розгортання (двійкові файли)

Дія бінарного розгортання вашого продукту до (виробничої) системи.

Випуск (функціональність)

Дія управління доступністю функціоналу для (груп) користувачів.

Чому? У вас, як правило, виникають (декілька) двох проблем при "випуску": 1) Помилки / сумісність назад / тощо 2) Перевірка дійсності / зручності використання нових функцій

Тоді запитайте себе перед тим, як вибрати канарну або блакитну / зелену або будь-яку стратегію сірого / змішаного режиму: які проблеми ми маємо при випуску / розгортанні нової версії? І тільки тоді, якщо ви знаєте свої проблеми, вибирайте свою стратегію.

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

Позначення функцій

Дія "налаштування" (холодної чи навіть гарячої), яка функціональність (недоступна) доступна для (групи) користувачів

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