Ми в GitLab обробляємо виправлення ПЗ двома способами - "ручками" і автоматично. Читайте далі про роботу release manager зі створення та доставки важливих оновлень за допомогою автоматичного розгортання на gitlab.com, а також виправлень для користувачів, які працюють зі своїми установками.
Рекомендую поставити нагадування на своєму розумному годиннику: щомісяця 22 числа користувачі, які працюють з GitLab на своїх потужностях, можуть побачити оновлення актуальної версії нашого продукту. У щомісячному випуску можна знайти нові функції, розвиток вже існуючих, а також часто можна побачити кінцевий результат запитів, надісланих спільнотою, на інструментарій чи злиття.
Але, як показує практика, розробка ПЗ рідко буває без вад. При виявленні помилки або вразливості у системі безпеки, release manager у команді доставки створює виправлення для наших користувачів зі своїми установками. Gitlab.com оновлюється у процесі CD. Ми називаємо цей процес CD автоматичним розгортанням, щоб не було змішування з функцією CD у GitLab. Цей процес може включати пропозиції із запитів на злиття, відправлених користувачами, клієнтами і нашою внутрішньою командою розробки, так що вирішення нудної проблеми випуску виправлень вирішується двома способами, що дуже сильно розрізняються.
«Ми щодня забезпечуємо розгортання всього, що зробили розробники на всіх оточеннях, перш ніж викотити це на GitLab.com», пояснює , старший технічний менеджер інфраструктурного відділу «Сприймайте випуски для своїх установок як знімки для розгортання gitlab.com, для яких ми додали окремі дії щодо створення пакету, щоб наші користувачі могли використовувати його для встановлення на своїх потужностях».
Незалежно від помилки або вразливості, клієнти gitlab.com отримають виправлення невдовзі після публікації, що є перевагою автоматичного процесу CD. Виправлення для користувачів зі своїми налаштуваннями вимагають окремої підготовки, що виконується release manager.
Команда доставки посилено працює над автоматизацією більшості процесів, пов'язаних із створенням випусків для скорочення (mean time to production, тобто. часу, витраченого на виробництво), проміжку часу від обробки запиту на злиття розробником до розгортання на gitlab.com.
«Мета команди доставки - переконатися, що ми можемо працювати швидше, як компанія, або принаймні прискорити роботу людей по доставці, вірно?», каже Marin.
Як клієнти gitlab.com, так і користувачі своїх установок отримують вигоду від зусиль команди доставки зі скорочення часу циклу та прискорення розгортання. У цій статті ми пояснимо схожість і різницю між цими двома способами , а також опишемо, як наша команда доставки готує виправлення для користувачів, що працюють на своїх потужностях, а також, як забезпечується актуальність gitlab.com за допомогою автоматичного розгортання.
Що робить release manager?
Члени команди щомісячно наших випусків для користувачів на своїх потужностях, включаючи виправлення та випуски безпеки, які можуть відбуватися між випусками. Також вони відповідають за перехід компанії на автоматичне, безперервне розгортання.
Випуски для встановлення на своїх потужностях, а також випуски gitlab.com використовують схожі робочі процеси, але працюють у різний час, пояснює Marin.
Насамперед release manager, незалежно від типу випуску, забезпечує доступність та безпеку GitLab з моменту запуску програми на gitlab.com, включаючи гарантію того, що однакові проблеми не потраплять до інфраструктури клієнтів зі своїми потужностями.
Як тільки в GitLab помилка або вразливість позначається виправленою, release manager повинен оцінити, що вона потрапить у виправлення або оновлення безпеки для користувачів зі своїми установками. Якщо він вирішить, що помилка чи вразливість заслуговують на оновлення — починається підготовча робота.
Release manager повинен вирішити, чи готувати виправлення, або коли його розгортати — і це залежить від контексту ситуації, «а поки що машини не так добре управляються з контекстом, як люди», Каже Marin.
Все про виправлення
Що таке виправлення і чому вони нам потрібні?
Release manager приймає рішення про випуск виправлення залежно від серйозності помилки.
Помилки різняться залежно від їхньої серйозності. Так, помилки S4 або S3 можуть бути стилістичними, наприклад зміщення пікселя або значка. Це не менш важливо, проте тут немає особливого впливу на чийсь робочий процес, а значить ймовірність того, що виправлення буде створено для таких помилок S3 або S4, мала, пояснює Marin.
Однак уразливість S1 або S2 означає, що користувач не повинен оновлюватися до останньої версії, або є значна помилка, що впливає на робочий процес користувача. Якщо такі потрапляють у трекер - багато користувачів зіткнулися з ними, тому release manager відразу починає підготовку виправлення.
Як тільки виправлення для уразливостей S1 чи S2 готове, release manager запускає випуск виправлення.
Наприклад, виправлення GitLab 12.10.1 було створено після того, як виявилося кілька блокуючих проблем, а розробники усунули основну проблему, що призводила до них. Release manager провів оцінку правильності присвоєних рівнів серйозності, а після підтвердження було запущено процес випуску виправлення, який був готовий протягом доби після виявлення проблем, що блокують.
Коли накопичується багато S4, S3 і S2 - release manager дивиться контекст визначення терміновості випуску виправлення, а при досягненні деякого їх числа - вони всі об'єднуються і випускаються. Виправлення або оновлення безпеки після випуску коротко описуються в блогах.
Як release manager створює виправлення
Ми застосовуємо GitLab CI та інші функції, наприклад наш ChatOps, для створення виправлень. Release manager запускає випуск виправлення шляхом активації команди ChatOps на нашому внутрішньому каналі #releases у Slack.
/chatops run release prepare 12.10.1ChatOps працює в Slack, щоб активувати різні події, які потім обробляє та виконує GitLab. Наприклад, команда доставки провела налаштування ChatOps для автоматизації різних речей випуску виправлень.
Як тільки release manager запускає команду ChatOps у Slack, решта роботи відбувається автоматично у GitLab з використанням CICD. Між ChatOps у Slack та GitLab у процесі випуску відбувається двосторонній обмін даними, оскільки release manager активує деякі з основних етапів процесу.
На відео нижче надано технічний процес підготовки виправлення для GitLab.
Як влаштовано автоматичне розгортання gitlab.com
Сам процес та інструменти, що використовуються при оновленні gitlab.com, схожі на такі, що використовуються під час створення виправлень. Оновлення gitlab.com вимагає менше ручної роботи з точки зору release manager.
Замість запуску розгортання з використанням ChatOps ми використовуємо функції CI, наприклад , з якими release manager може запланувати виконання певних дій у потрібний час. Замість ручного процесу є конвеєр, який періодично запускається один раз на годину, який завантажує внесені нові зміни в проектах GitLab, упаковує їх і планує розгортання, а також автоматично запускається тестування, QA та інші необхідні кроки.
"Отже, ми маємо багато розгортань, запущених у різних оточеннях, до gitlab.com, а після того, як ці оточення будуть у хорошому стані, і тестування покаже хороші результати, release manager запускає дії з розгортання gitlab.com", - розповідає Marin.
Технологія CICD для підтримки оновлень gitlab.com автоматизує весь процес до того моменту, коли release manager повинен руками запускати розгортання виробничого оточення на gitlab.com.
Marin детально розповідає про процес поновлення gitlab.com на відео нижче.
Що ще робить команда доставки
Основна відмінність між процесами оновлення gitlab.com та випуском виправлень для клієнтів на своїх потужностях полягає в тому, що останній процес потребує більше часу та більшої кількості ручної роботи від release manager.
Іноді ми відкладаємо випуск виправлень для клієнтів зі своїми установками через передані проблеми, проблеми з інструментами, а також тому, що є багато нюансів, які треба враховувати при випуску єдиного виправлення, говорить Marin.
Одна із короткострокових цілей команди доставки – зменшити обсяги ручної роботи з боку release manager для прискорення випуску. Команда працює над спрощенням, оптимізацією та автоматизацією процесу випуску, що допоможе швидше позбутися виправлень для проблем з низьким рівнем серйозності (S3 та S4, прим. перекладача). Орієнтація на швидкість – ключовий показник продуктивності: треба зменшувати MTTP – час, з прийому запиту на злиття та до розгортання результату на gitlab.com – з поточних 50 годин до 8 годин.
Команда доставки працює над переходом gitlab.com на інфраструктуру на основі Kubernetes.
NB редактора: Якщо ви вже чули про технологію Kubernetes (а я навіть і не сумніваюся, що чули), але ще не помацали її руками, рекомендую взяти участь в онлайн-інтенсивах , який пройде 28-30 вересня, та , що пройде 14–16 жовтня. Це дозволить вам впевнено орієнтуватися у технології та працювати з нею.
Це два підходи, що мають одну й ту саму мету: швидка доставка оновлень як для gitlab.com, так і для клієнтів на своїх потужностях.
Чи є ідеї та рекомендації для нас?
Кожен може взяти участь у розробці GitLab, ми вітаємо відгуки наших читачів. Якщо у вас є ідеї для нашої команди доставки - не соромтеся з позначкою team: Delivery.
Джерело: habr.com