Manage YDB releases
На базе исходного кода из репозитория YDB разрабатываются два продукта с независимыми релизными циклами:
Релизный цикл сервера YDB
Номера и расписание релизов
Версия сервера YDB состоит из трех чисел, разделенных точкой:
- Две последние цифры календарного года релиза
- Порядковый номер мажорного релиза в этом году
- Порядковый номер минорного релиза в этом мажорном
Таким образом, мажорная версия сервера YDB - это комбинация первый двух чисел (например, 23.3), а полная версия - это комбинация всех трех (например, 23.3.5).
Расписание релизов сервера YDB обычно включает в себя 4 мажорных релиза ежегодно, поэтому релиз YY.1 является первым, а YY.4 - последним в году YY. Количество минорных релизов не является постоянным и может варьироваться от одного мажорного релиза к другому.
Совместимость
YDB поддерживает совместимость между мажорными версиями таким образом, чтобы гарантировать, что кластер может работать, когда на его узлах выполняются две смежные мажорные версии исполняемого файла сервера YDB. Вы можете обратиться к статье Обновление YDB для информации о процедуре обновления кластера.
Учитывая вышеуказанную цель совместимости, мажорные релизы выпускаются парами, в основном с добавлением в нечетных версиях новой функциональности, отключенной feature-флагами, и включением этой функциональности по-умолчанию в четных.
Например, версия 23.1 поставляется с отключенной новой функциональностью, и может быть постепенно развернута на кластере, работающем под управлением 22.4, без остановки работы кластера. Как только на всех узлах кластера будет запущена 23.1, его можно будет далее обновить до 23.2, чтобы использовать новые функциональные возможности.
Релизные ветки и теги
Цикл выпуска для нечетного мажорного релиза начинается с отведения ветки от main ветки участником релизной команды YDB. Название релизной ветки начинается с префикса stable-, за которым следует мажорная версия с точками, замененными на дефис (например, stable-23-1).
Цикл выпуска четного мажорного релиза начинается с отведения ветки от ветки предыдущего нечетного мажорного релиза.
Все выпуски мажорных версий, как четных, так и нечетных, проходят цикл тестирования, в процессе которого создается ряд минорных версий. Каждая минорная версия фиксируется путем назначения тега с полным номером версии на соответствующей релизной ветке. Таким образом, в ветке stable-24-1 могут быть теги 24.1.1, 24.1.2 и т.д. Как только минорная версия успешно прошла необходимое тестирование, мы считаем ее стабильной, и регистрируем релиз на GitHub для ее тега, добавляем его на страницы документации загрузки and список изменений, и так далее. Для мажорной версии может быть более одного стабильного релиза.
Тестирование
Тестирование релиза является итеративным. Каждая итерация начинается с назначения тега на коммит в релизной ветке для минорной версии, подлежащей тестированию. Например, тег минорной версии 23.3.5 отмечает 5-ю итерацию тестирования для мажорной версии 23.3.
Тег может считаться либо "кандидатом", либо "стабильным". Изначально первый тег назначается релизной ветке сразу после ее создания, и этот тег считается "кандидатом".
Во время итерации тестирования код из релизных веток проходит всестороннее тестирование, включая развертывание в UAT, prestable, и production средах использующих YDB компания. Для выполнения такого тестирования код YDB из релизного тега на GitHub импортируется в корпоративный контекст пользователя в соответствии с его политиками и стандартами. Затем производится его сборка, развертывание в необходимых средах, и тестирование.
Основываясь на перечне выявленных проблем, релизная команда YDB решает, можно ли повысить статус минорного релиза до стабильного, или необходимо запустить новую итерацию тестирования с новым тегом минорного релиза. Фактически, как только во время тестирования обнаруживается критическая проблема, разработчики исправляют ее в main и сразу же мержат изменения в релизную ветку. Таким образом, к моменту завершения тестирования, если в релизной ветке есть какие-либо коммиты поверх текущего тега, это означает что последует новый тег и новая итерация тестирования.
Стабильный релиз
Если итерация тестирования подтверждает качество минорного релиза, релизная команда YDB готовит перечень изменений, и публикует релиз на страницах Releases на GitHub и Загрузки в документации, объявляя его тем самым стабильным.
Цикл выпуска YDB CLI (интерфейс командной строки)
Номера выпусков и расписание
Версия YDB CLI состоит из трех чисел, разделенных точкой:
- Порядковый номер мажорной версия (в настоящее время "2")
- Порядковый номер минорной версии для заданной мажорной
- Номер патча
Например, 2.8.0 - это 2-я мажорная, 8-я минорная, без патчей.
Для минорных релизов YDB CLI не существует расписания, новый релиз выходит в тот момент, когда у нас появляется некоторая новая ценная функциональность. Изначально каждый новый минорный релиз имеет 0 в качестве номера патча. Если в этой версии обнаруживаются критические ошибки, или в неё не вошла какая-то незначительная часть запланированной функциональности, мы можем выпустить патч, увеличив только номер патча, как это было для 2.1.1.
В целом, цикл выпуска для YDB CLI намного проще и короче, чем для сервера, что приводит к более частым выпускам.
Релизные теги
Теги для YDB CLI назначаются в транке (ветка main) участником релизной команды YDB после запуска тестов для некоторой ревизии. Чтобы отличаться от тегов сервера YDB, теги CLI YDB содержат префикс CLI_ перед номером версии, например CLI_2.8.0.
Стабильный релиз
Чтобы объявить тег YDB CLI стабильным, участник релизной команды YDB готовит перечень изменений, и публикует релиз на странице GitHub Releases и в разделе Загрузки документации.