Виведення нового релізу проекту в продакшн вимагає ретельного дотримання балансу між швидкістю розгортання та надійністю рішення. У компанії Slack цінують швидкі ітерації, короткі цикли зворотного зв'язку, оперативну реакцію звернення користувачів. Крім того, у компанії є сотні програмістів, які прагнуть максимально можливої продуктивності.
Автори матеріалу, переклад якого ми сьогодні публікуємо, кажуть, що компанія, яка прагне дотримуватись подібних цінностей і при цьому зростає, має постійно вдосконалювати свою систему розгортання проектів. Компанії потрібно вкладати сили у прозорість та надійність робочих процесів, роблячи це для того, щоб ці процеси відповідали б масштабам проекту. Тут мова піде про робочі процеси, що склалися в Slack, і про деякі рішення, які привели компанію до використання в ній існуючої системи розгортання проектів.
Як процеси розгортання проектів працюють сьогодні
Кожен PR (pull request) в Slack повинен бути обов'язково підданий код-рев'ю і має успішно пройти всі тести. Тільки після того, як будуть виконані ці умови, програміст може виконати злиття свого коду з гілкою master проекту. Однак розгортання такого коду виконується тільки в робочий час за північноамериканським часом. В результаті ми, за рахунок того, що наші співробітники знаходяться на робочих місцях, повністю готові до вирішення будь-яких несподіваних проблем.
Щодня ми виконуємо близько 12 запланованих розгортань. У процесі кожного розгортання програміст, призначений головним з розгортання, відповідає за виведення нового складання в продакшн. Це багатокроковий процес, який забезпечує плавне виведення складання в робочий режим. Завдяки такому підходу ми можемо виявляти помилки до того, як вони торкнуться всіх наших користувачів. Якщо помилок виявиться занадто багато, розгортання збірки можна відкотити. Якщо ж окрему проблему виявлено після релізу, для неї легко можна випустити виправлення.
Інтерфейс системи Checkpoint, якою користуються в Slack для розгортання проектів
Процес розгортання нового релізу в продакшні можна уявити що складається з чотирьох кроків.
▍1. Створення гілки релізу
Кожен реліз починається з нової гілки релізу, з моменту нашої Git-історії. Це дозволяє призначати реліз теги і дає місце, в яке можна вносити оперативні виправлення для помилок, знайдених у процесі підготовки релізу до випуску в продакшн.
▍2. Розгортання у проміжному оточенні
Наступний крок роботи полягає у розгортанні складання на проміжних (staging) серверах та у запуску автоматичного тесту на загальну працездатність проекту (smoke test). Проміжне оточення – це продакшн-оточення, в яке не потрапляє зовнішній трафік. У цьому оточенні ми проводимо додаткове тестування. Це дає нам додаткову впевненість у тому, що змінений проект працює правильно. Одних лише автоматизованих тестів для набуття такої впевненості недостатньо.
▍3. Розгортання в dogfood-і canary-оточеннях
Розгортання в продакшні починається з dogfood-оточення, представленого набором хостів, які обслуговують наші внутрішні робочі простори Slack. Оскільки ми дуже активні користувачі Slack, застосування такого підходу допомогло виявити безліч помилок на ранніх стадіях розгортання. Після того, як ми переконалися, що базовий функціонал системи не порушений, виконується розгортання збірки в canary-оточенні. Воно є системами, на які йде приблизно 2% продакшн-трафіку.
▍4. Поступовий висновок у продакшн
Якщо показники моніторингу нового релізу виявляються стабільними, і якщо після розгортання проекту в canary-оточенні ми не отримали скарг, ми продовжуємо поступовий переклад продакшн-серверів на новий реліз. Процес розгортання розбитий на такі етапи: 10%, 25%, 50%, 75% та 100%. В результаті ми можемо повільно передавати продакшн трафік новому релізу системи. При цьому ми маємо час на вивчення ситуації у разі виявлення деяких аномалій.
▍Як бути, якщо під час розгортання щось пішло не так?
Внесення модифікацій у код – це завжди ризик. Але ми справляємося з цим завдяки наявності у нас добре підготовлених «головних з розгортання», які керують процесом виведення нового релізу в продакшн, спостерігають за показниками моніторингу та координують роботу програмістів, які випускають код.
У тому випадку, якщо щось справді пішло не так, ми намагаємося виявити проблему якомога раніше. Ми досліджуємо проблему, знаходимо PR, який викликає помилки, відкочуємо його, ретельно аналізуємо та створюємо нове складання. Щоправда, іноді проблема виявляється непоміченою до виведення проекту у продакшн. У такій ситуації найважливіше – це відновити роботу сервісу. Тому ми, до початку дослідження проблеми, негайно відкочуємося до попереднього робочого збирання.
Будівельні блоки системи розгортання
Розглянемо технології, що лежать в основі нашої системи розгортання проектів.
▍Швидкі розгортання
Вищеописаний робочий процес може здатися в ретроспективі чимось цілком очевидним. Але наша система розгортання стала такою далеко не одразу.
Коли компанія була значно меншою, вся наша програма могла працювати на 10 Amazon EC2-інстансах. Розгортання проекту у такій ситуації означало застосування rsync для швидкої синхронізації всіх серверів. Раніше новий код від продакшна відокремлював лише один крок, представлений проміжним оточенням. Складання створювалися і перевірялися в такому оточенні, а потім йшли відразу в продакшн. Розібратися в такій системі було дуже просто, вона дозволяла будь-якому програмісту в будь-який час розгорнути написаний код.
Але в міру того, як зростала кількість наших клієнтів, зростали масштаби інфраструктури, необхідної для забезпечення роботи проекту. Незабаром з огляду на постійне зростання системи наша модель розгортання, заснована на відправленні нового коду на сервери, перестала справлятися зі своїм завданням. Зокрема, додавання кожного нового сервера означало збільшення часу, необхідного виконання розгортання. Навіть стратегії, що базуються на паралельному застосуванні rsync, мають певні обмеження.
У результаті ми вирішили цю проблему, перейшовши повністю паралельну систему розгортання, влаштовану негаразд, як стара система. А саме тепер ми не відправляли код на сервери, використовуючи скрипт синхронізації. Тепер кожен сервер самостійно завантажував нову збірку, дізнаючись про те, що це потрібно зробити завдяки спостереженню за зміною ключа Consul. Сервери завантажували код паралельно. Це дозволило нам підтримувати високу швидкість розгортання навіть за умов постійного зростання системи.
1. Продакшн-сервери спостерігають за ключем Consul. 2. Ключ змінюється, це повідомляє серверів про те, що їм потрібно розпочати завантаження нового коду. 3. Сервери завантажують tarball-файли з кодом програми
▍Атомарні розгортання
Ще одним рішенням, що допомогло нам дійти до багаторівневої системи розгортання, стало атомарне розгортання.
До використання атомарних розгортань кожне розгортання могло призвести до появи великої кількості повідомлень про помилки. Справа в тому, що процес копіювання нових файлів на продакшн-сервери не був атомарним. Це призводило до існування короткого часового відрізка, коли код, у якому викликалися нові функції, виявлявся доступним до того, як виявлялися доступними самі функції. Коли такий код викликався, це призводило до внутрішніх помилок. Це виявлялося в невдалих запитах до API і в «зламаних» веб-сторінках.
Команда, яка займалася цією проблемою, вирішила її, ввівши поняття «гарячих» (hot) та «холодних» (cold) директорій. Код у «гарячій» директорії відповідає за обробку продакшн-трафіку. А в «холодних» директоріях код під час роботи системи лише готується до використання. У ході розгортання новий код копіюється в «холодну» директорію, що не використовується. Потім, коли на сервері не буде активних процесів, відбувається миттєве перемикання директорій.
1. Розпакування коду програми у «холодну» директорію. 2. Перемикання системи на «холодну» директорію, яка стає «гарячою» (атомарна операція)
Підсумки: зсув акценту на надійність
У 2018 році проект зростав до таких масштабів, коли дуже швидке розгортання почало шкодити стабільності продукту. У нас була дуже розвинена система розгортання, в яку ми вклали багато сил і часу. Нам потрібно було лише перебудувати та вдосконалити процеси організації розгортання. Ми перетворилися на досить велику компанію, розробки якої використовувалися у всьому світі для організації безперебійного зв'язку та для вирішення важливих завдань. Тож у центрі нашої уваги опинилася надійність.
Нам потрібно було зробити процес розгортання нових релізів Slack безпечнішим. Ця потреба і призвела нас до вдосконалення нашої системи розгортання. Власне, вище ми й обговорювали цю ось удосконалену систему. У надрах системи ми продовжуємо користуватися технологіями швидкого та атомарного розгортання. Змінилося те, як саме виконується розгортання. Наша нова система призначена для поступового виконання розгортання нового коду на різних рівнях, у різних середовищах. Тепер ми використовуємо більш досконалі, ніж раніше, допоміжні інструменти та засоби для моніторингу системи. Це дає нам можливість відловлювати та усувати помилки задовго до того, як вони отримають шанс дістатися кінцевого користувача.
Але ми не збираємося зупинятися на досягнутому. Ми постійно покращуємо цю систему, застосовуючи досконаліші допоміжні інструменти та засоби автоматизації роботи.
Шановні читачі! Як влаштований процес розгортання нових релізів проектів там, де ви працюєте?
Джерело: habr.com