Цикл випуску Kubernetes

Орієнтація на поліпшення, Тікети та PR для віх випуску

Цей документ орієнтований на розробників та учасників Kubernetes, які повинні створювати поліпшення, тікети або pull request (PR), що спрямовані на конкретну віху випуску.

• TL;DR
  • Звичайна розробка (Тижні 1-11)
  • Заморожування коду (Тижні 12-14)
  • Після випуску (Тижні 14+)
• Визначення
• Цикл випуску
• Видалення елементів з віхи
• Додавання елемента до віхи
  • Відповідальні за віхи
  • Додавання функціоналу
  • Додавання тікетів
  • Додавання PR
• Інші обовʼязкові мітки
  • Мітка власника SIG
  • Мітка пріоритету
  • Мітка виду проблеми/PR

Процес управління поліпшеннями, тікетами та pull request у випуску Kubernetes охоплює кілька зацікавлених сторін:

• власники поліпшень, проблем та pull request
• керівництво SIG
• Команда випуску

Інформація про робочі процеси та взаємодії описана нижче.

Як власник поліпшення, проблеми або PR, ви несете відповідальність за забезпечення виконання вимог до етапів випуску. Команди автоматизації та випуску будуть звʼязуватися з вами, якщо необхідні оновлення, але бездіяльність може призвести до видалення вашої роботи з віхи. Додаткові вимоги існують, якщо цільова віха — це попередній випуск (див. процес cherry pick для отримання додаткової інформації).

TL;DR

Якщо ви хочете, щоб ваш PR було прийнято, він повинен мати наступні обовʼязкові мітки та віхи, представлені тут командами Prow, необхідними для їх додавання:

Звичайна розробка (Тижні 1-11)

• /sig {назва}
• /kind {тип}
• /lgtm
• /approved

Заморожування коду (Тижні 12-14)

• /milestone {v1.y}
• /sig {назва}
• /kind {bug, failing-test}
• /lgtm
• /approved

Після випуску (Тижні 14+)

Повернення до вимог фази 'Звичайної розробки':

• /sig {назва}
• /kind {тип}
• /lgtm
• /approved

Злиття в гілку 1.y тепер відбувається через cherry pick, затверджені Менеджерами випуску.

Раніше була вимога, щоб pull request, націлені на етапи випуску, мали повʼязаний тікет в GitHub, але зараз це більше не потрібно. Функції або вдосконалення фактично є тікетами GitHub або KEPs, які призводять до подальших PR.

Процес позначення мітками повинен бути послідовним для всіх типів артефактів.

Визначення

• issue owners (власники тікетів): Автор, відповідальні та користувач, який перемістив тікет у віху випуску

• Release Team (Команда випуску): Кожен випуск Kubernetes має команду, яка виконує завдання управління проєктом, описані тут.

  Контактну інформацію для команди, повʼязаної з будь-яким даним випуском, можна знайти тут.

• Y days (Робочі дні): Стосується робочих днів

• enhancement (поліпшення): дивіться "Is My Thing an Enhancement?"

• Enhancements Freeze (Заморожування поліпшень): граничний термін, до якого KEP мають бути завершені, щоб поліпшення стали частиною поточного випуску

• Exception Request (Запит на виняток): Процес запиту продовження терміну для конкретного поліпшення

• Code Freeze (Заморожування коду): Період приблизно 4 тижні до фінальної дати випуску, протягом якого до релізного коду приймаються лише критичні виправлення помилок.

• Pruning (Очищення): Процес видалення поліпшення з віхи випуску, якщо воно не повністю реалізоване або вважається нестабільним.

• release milestone (віха випуску): семантичний рядок версії або віха GitHub, що стосується випуску MAJOR.MINOR версії vX.Y.

  Дивіться також версіювання випусків.

• гілка випуску (release branch): Гілка Git release-X.Y, створена для віхи vX.Y.

  Створюється на момент випуску vX.Y-rc.0 і підтримується після випуску приблизно протягом 12 місяців з патч-випусками vX.Y.Z.

  Примітка: випуски 1.19 і новіші отримують 1 рік підтримки патч-випусків, а випуски 1.18 і раніші отримували 9 місяців підтримки патч-випусків.

Цикл випуску

Випуски Kubernetes наразі відбуваються приблизно три рази на рік.

Процес випуску можна умовно розділити на три основні фази:

• Визначення покращень
• Реалізація
• Стабілізація

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

Протягом року, коли триває визначення нових функцій, деякі з них стають ціллю для конкретного випуску. Замороження покращень починається приблизно через 4 тижні після початку циклу випуску. На цей момент всі заплановані роботи для даного випуску мають бути визначені у відповідних планових артефактах у співпраці з Лідером покращень Команди Випуску.

Після Замороження покращень важливо відстежувати віхи в PR та тікетах. Елементи в межах віхи використовуються як список для завершення випуску. В тікетах віхи мають бути правильно застосовані через сортування SIG, щоб Команда Випуску могла відстежувати проблеми та покращення (будь-який тікет, пов’язаний з покращенням, потребує віхи).

Існує певна автоматизація, яка допомагає автоматично призначати віхи PR.

Ця автоматизація наразі застосовується до наступних репозиторіїв:

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

Під час створення PR для гілки master потрібні люди, які вказують, на яку віху вони хотіли б спрямувати PR. Після злиття PR для гілки master мають автоматично призначені віхи, тому з цього моменту втручання людей в управління віхою PR є менш необхідним. В PR для гілок випуску віхи автоматично призначаються під час створення PR, тому втручання людей для управління віхою взагалі не потрібне.

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

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

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

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

Коли кодова база достатньо стабільна, гілка master знову відкривається для загальної розробки, і робота починається над наступним етапом випуску. Будь-які залишкові модифікації для поточного випуску вибираються з master назад у гілку випуску. Випуск будується з гілки release.

Кожен випуск є частиною ширшого життєвого циклу Kubernetes:

Видалення елементів з віхи

Перед тим як заглибитися у процес додавання елемента до віхи, будь ласка, зверніть увагу:

Члени Команди Випуску можуть видалити тікет з віхи, якщо вони або відповідальний SIG визначать, що проблема насправді не блокує випуск і навряд чи буде вирішена вчасно.

Члени Команди Випуску можуть видалити PR з віхи з будь-якої з наступних або подібних причин:

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

Хоча члени Команди Випуску допоможуть з позначенням мітками та спілкуванням SIG(ів), відповідальність за категоризацію PR лежить на авторі, а також на отриманні підтримки від відповідного SIG для гарантування того, що будь-який збій, викликаний PR, буде швидко вирішений.

Де потрібно додаткове втручання, спроба ескалації буде зроблена Командою Випуску через такі канали:

• Коментар на GitHub, що згадує команду SIG та членів SIG відповідно до типу проблеми
• Надсилання електронного листа у список розсилки SIG
  • ініціалізовано з групових електронних адрес зі списку спільноти SIG
  • за бажанням також безпосередньо звертаючись до керівництва SIG або інших членів SIG
• Повідомлення в Slack-каналі SIG
  • ініціалізовано зі slack-каналу та керівництва SIG зі списку спільноти SIG
  • за бажанням безпосередньо згадуючи керівництво SIG або інших через "@".

Додавання елемента до віхи

Відповідальні за віхи

Члени команди milestone-maintainers на GitHub відповідають за визначення етапу випуску для артефактів на GitHub.

Ця група керується SIG Release і має представників від різних керівників SIG.

Додавання проміжного етапу релізу, що перебуває у процесі розробки, до pull requests після заморожування коду суворо заборонено, оскільки це може порушити стабільність релізу. Перш ніж вносити такі зміни, необхідно отримати схвалення як від керівника команди релізу, так і від почесного радника (радників).

Додавання функцій

Планування та визначення функцій сьогодні мають багато форм, але типовим прикладом може бути великий обсяг роботи, описаний у KEP, з відповідними завданнями на GitHub. Коли план досягнув стану, готового до реалізації, і робота вже триває, покращення або його частини стають цілями для найближчої віхи, створюючи завдання на GitHub і позначаючи їх командою Prow "/milestone".

Протягом перших ~4 тижнів циклу випуску Лідер покращень Команди Випуску буде взаємодіяти з SIG та власниками функцій через GitHub, Slack і зустрічі SIG, щоб зібрати всі необхідні планові артефакти.

Якщо у вас є покращення, яке ви хочете націлити на майбутню віху випуску, почніть розмову з керівництвом вашого SIG та з Лідером покращень цього випуску.

Додавання тікетів

Тікети позначаються як цільові для етапу через команду Prow "/milestone".

Лідер з сортування проблем Команди Випуску Bug Triage Lead та загальна спільнота відстежують нові завдання і сортують їх, як це описано в розділі посібника для учасників щодо сортування завдань.

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

Відкритий тікет більше не є обов’язковим для PR, але відкриті тікети та повʼязані PR повинні мати синхронізовані мітки. Наприклад, PR з високим пріоритетом проблеми може не бути злитим, якщо він позначений як нижчий пріоритет.

Додавання PR

PR позначаються як цільові для віхи через команду Prow "/milestone".

Це є обовʼязковою вимогою під час Замороження коду, як описано вище.

Інші обовʼязкові мітки

Ось список міток, їх використання та призначення.

Мітка власника SIG

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

Ці мітки додаються за допомогою команди Prow "/sig". Наприклад, щоб додати мітку, що SIG Storage відповідає, прокоментуйте /sig storage.

Мітка пріоритету

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

• priority/critical-urgent: Ніколи автоматично не видаляти з віхи випуску; постійно ескалювати до учасника та SIG через всі доступні канали.
  • вважається блокуючим випуск питанням
  • потребує щоденних оновлень від власників тікета під час Замороження коду
  • потребуватиме випуску патча, якщо його не виявили до завершення мінорного випуску
• priority/important-soon: Ескалювати до власників питання та власника SIG; видалити з віхи після кількох невдалих спроб ескалації.
  • не вважається блокуючим випуск питанням
  • не потребуватиме випуску патча
  • автоматично буде видалено з віхи випуску під час Замороження коду після 4-денної пільгового періоду
• priority/important-longterm: Ескалювати до власників питання; видалити з віхи після 1 спроби.
  • менш термінове / критичне, ніж priority/important-soon
  • видаляється з віхи більш агресивно, ніж priority/important-soon

Мітка типу тікета/PR

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

Для випуску цільових завдань, включаючи pull request-и, повинна бути встановлена одна з наступних міток типу:

• kind/api-change: Додає, видаляє або змінює API
• kind/bug: Виправляє нововиявлений баг.
• kind/cleanup: Додає тести, рефакторинг, виправляє старі баги.
• kind/design: Повʼязане з дизайном
• kind/documentation: Додає документацію
• kind/failing-test: Тест CI постійно не проходить.
• kind/feature: Нова функціональність.
• kind/flake: Тест CI показує періодичні збої.