2024-02-14, Мысли по процессу релиза

Owned by Anonymous
Last updated: Feb 14, 2024 by Ivan Golikov
2 min read

Процесс на текущий момент:
PR из develop в rc ветку ⇒ Мерж ⇒ CI пайплайн собирает образ с тегом rc.

Проблемы

  • Ветка rc по сути играет роль master, но почему-то master не используется и заброшен ⇒ людям, попадающим на страницу проекта не очевидно какая ветка содержит актуальный код релиза.

  • Не очень понятно, почему rc, а не release

  • Нет тегов прошлых релизов ⇒ сложнее процедура отката при неудачном релизе, плюс сложнее тестировать различные версии продукта (например для сравнения производительности)

  • Нюанс с тем что сборки develop ветки маркируются тегом latest. С моей точки зрения это может быть неудачным дизайном если мы позиционируем продукт как достаточно стабильный, в таком случае лучше тегом latest помечать последний релиз.

  • Недостаточно внятная нумерация версий, сейчас у нас есть версии 0.2.40 и 0.2.62 которые отличаются в патч-части, но по факту несовместимы (одна и та же версия плагина не будет работать и с тем и с другим). Условно говоря это могли бы быть 0.2.40 и 0.3.0. В принципе пока продукт не выходит в массы это и не страшно, но небольшие неудобства доставляет. Отчасти тут моя ошибка, можно было продумать и обговорить этот момент.

Как можно исправить

  1. Релиз: PR из develop в master ветку. Можно переименовать в main. Это будет работать когда бэкенд-разработчик на проекте один. Если их будет несколько то будет лучше иметь промежуточную ветку release (develop → release → master).
    Альтернатива: trunk-based и мержить фичи в master. Нормальный вариант если поддерживается только одна, "последняя" версия продукта. Чуть сложнее будет настройка CI в сборке контейнеров (нужно отличать когда делать dev-сборку, когда релизную), но не критично.

  2. При мерже в master ветку CI пайплайн ставит на собранный контейнер два тега: latest и номер версии.

  3. При мерже в develop ветку CI пайплайн ставит на собранный контейнер два тега: nightly и номер версии.

  4. Удалить (лишние) rc ветки.

  5. Немного не связано, но было бы неплохо почистить ветки (если будет время).

  6. Задокументировать процесс релиза, в том числе зафиксировать логику инкремента версий.

  7. Почистить untagged сборки контейнеров бэкенда

Что нужно иметь в виду

  • Лимиты на ghcr.io, где хранятся наши собранные контейнеры.