Я і мої колеги завжди схиляємо своїх клієнтів повністю автоматизувати процес деплоя. Автоматизація допомагає скоротити кількість конфліктів і затримок, які виникають у процесі між «» завершенням «» роботи над програмою і введенням в експлуатацію. Дейв Фарлі (Dave Farley) і Джез Хамбл (Jez Humble) закінчують книгу «» Безперервна доставка «» (Continuous Delivery) на цю тему. Вона ґрунтується на безлічі ідей, які загалом пов'язані з безперервною інтеграцією і підштовхують до можливості швидко пустити софт у роботу. Голова про синьо-зеленого депле привернула мою увагу, тому що це один з маловикористовуваних методів, і я вирішив коротко його висвітлити.
Одне із завдань автоматизації деплоя - перехід з одного стану в інше всередині себе ж, з переведенням софту з фінальної стадії тестування в діючий продакшен. Зазвичай це потрібно зробити швидко, щоб мінімізувати час простою. При синьо-зеленому підході у вас є два продакшени, наскільки можливо ідентичних. У будь-який час один з них, припустимо синій, активний. При підготовці нової версії софту, ви робите фінальне тестування в зеленому продакшені. Ви переконуєтеся, що програма в цьому продакшені працює і налаштовуєте роутер так, щоб всі вхідні запити йшли в зелене операційне середовище - синя в режимі очікування.
Синьо-зелений деплою також дає вам можливість швидко відкотитися до старого стану: якщо щось піде не так, перемкніть роутер назад на синій продакшен. Але вам все ще доведеться справлятися з пропущеними транзакціями, поки зелений продакшен активний, і, залежно від структури коду, ви зможете направляти транзакції в обидва продакшени, щоб зберігати синій як резервну копію, при активному зеленому. Або можете перевести програму в read-only режим, перед синхронізацією, запустити її на час в цьому режимі, а потім перемкнути в режим read-write. Цього може виявитися достатньо, щоб позбутися багатьох невирішених проблем.
Два середовища повинні бути повністю самостійними, але настільки ідентичними, наскільки можливо. Іноді це можуть бути різні комп'ютери, іноді просто дві віртуальні машини, запущені одному (або декількох) комп'ютерах. Вони також можуть бути єдиним операційним середовищем, розбитим на відокремлені зони з окремими IP-адресами.
Після того, як зелений продакшен опиняється в роботі, і ви задоволені його стабільністю, можете використовувати синій як staging, щоб прогнати його через фінальні тести наступного деплоя. Коли ви будете готові до наступного релізу, зможете перемикатися з зеленого на синій так само як перемикалися з синього на зелений. У такій конфігурації і зелений і синій продакшен регулярно проходять через три стани - діючий додаток, попередню версію (для відкату) і staging наступної версії.
Перевага такого підходу в тому, що це той самий базовий механізм, який потрібен для гарячого резервування (hot-standby). Він дозволить вам тестувати процедуру аварійного відновлення при кожному релізі. (Сподіваюся, що ви релізите частіше, ніж у вас відбувається аварійне відновлення).
Основна ідея в тому, щоб мати два легко перемикання середовища, а способів змінювати деталі - безліч. Один варіант - робити перемикання перезапуском веб-сервера, а не через роутер. Інший - використовувати єдину базу даних, а синьо-зелені перемикання робити для вебу і прикладного рівня.
З базами даних при такому підході часто бувають проблеми, особливо якщо вам потрібно змінювати їх логічні структури для підтримки нової версії софту. Хитрість тут у тому, щоб розділити деплою зміни логічних структур і оновлення програми. Для цього спочатку потрібно застосувати рефакторинг бази даних, щоб змінити структури для підтримки нової і старої версій програми, задеплоїти ці зміни, перевірити, що все добре працює, і у вас є версія попереднього стану, і тільки потім задеплоїти нову версію програми. (А коли оновлення вже встаканилися, видалити підтримку бази даних для старої версії).
Цей підхід існує вже давно, але я не бачу, щоб його часто використовували. А повинні. Назву придумали Дан Норс (Dan North) і Джез Хамбл (Jez Humble).
(Переклад Наталії Басс)
