semver-теги и релизный процесс

Что нужно знать перед уроком

M9 урок 2 — чистая проверка pkglint. M8 урок 3 — связь семверных версий и content-based тегов. Этот урок описывает полный релизный процесс от git-тега до опубликованной версии Application-пакета.

Теория

От git-тега к d8 package build --version

Стандартный релизный процесс Application-пакета начинается с создания git-тега, соответствующего семверу:

1
2

git tag v1.2.0
git push origin v1.2.0

CI-пайплайн (M9 урок 6), реагируя на пуш тега, извлекает версию из имени тега и передаёт её в d8 package build --version:

1

d8 package build --version "${CI_COMMIT_TAG#v}" --repo "$PACKAGE_BUILD_REPOSITORY"

Это прямая связь с полем version в package.yaml, разобранным в M5 уроке 2 — значение инжектится CI из тега, а не прописывается вручную разработчиком в файле (что исключило бы рассинхронизацию между тегом в git и версией в манифесте).

Семантика семвера применительно к Application-пакетам

• MAJOR (v2.0.0) — несовместимые изменения config-values.yaml (пользователь должен явно проверить и обновить свои настройки при переходе), изменения, требующие ручного вмешательства (например, изменение имени PVC, требующее миграции данных).
• MINOR (v1.3.0) — новая функциональность, обратно совместимая с существующими настройками (новые опциональные поля config-values.yaml).
• PATCH (v1.2.1) — исправления багов, не меняющие контракт настроек.

Ручной production-релиз как осознанный gate

В отличие от dev/staging окружений, где публикация может быть полностью автоматической при пуше в ветку, production-релиз Application-пакета обычно требует ручного подтверждения в CI (when: manual в GitLab CI, разбираемый подробно в M9 уроке 6) — осознанное решение человека о том, что именно эта версия готова для пользователей каталога, а не автоматическое следствие пуша тега.

Откат версии (rollback)

Если опубликованная версия оказалась проблемной, откат осуществляется изменением поля spec.packageVersion объекта Application на предыдущую, стабильную версию (детально разобрано в M5 уроке 10 — процесс отражается в условии UpdateInstalled). Важное отличие от «удаления» проблемной версии из registry: сама опубликованная версия обычно не удаляется из каталога (это сломало бы возможность отследить историю и, если понадобится, повторно откатиться на неё later) — откат означает переключение конкретных инстансов Application на другую, уже существующую версию, а не физическое уничтожение проблемного релиза.

Частые ошибки и подводные камни

• Прописывать версию вручную в package.yaml вместо инжекции из CI. Это создаёт риск рассинхронизации между git-тегом и фактической версией в манифесте — стандартная практика требует, чтобы версия всегда бралась из тега автоматически.
• Автоматизировать production-релиз без ручного gate. Даже при полностью зелёном CI (пройденные тесты, чистый pkglint), production-публикация Application-пакета, доступного конечным пользователям каталога, требует человеческого подтверждения как последней линии защиты от случайных ошибок автоматизации.
• Физически удалять проблемную опубликованную версию из registry вместо отката через Application.spec. Удаление версии, на которую всё ещё могут ссылаться существующие инстансы Application, ломает возможность отслеживания истории и потенциального повторного использования этой версии.

Практика в кластере

1

d8 k get application umami -n course-m9-umami -o jsonpath='{.spec.packageVersion}{"\n"}{.status.conditions}'

Смоделируйте откат версии, изменив spec.packageVersion объекта Application на предыдущую опубликованную версию, и проследите за появлением условия UpdateInstalled в статусе.

Практика разработки

Создайте git-тег v0.1.0 для пакета Umami, соберите его через d8 package build --version с версией, извлечённой из тега, и убедитесь, что итоговая опубликованная версия отражена в package.yaml/registry корректно.

Шпаргалка команд урока

1
2

git tag v1.2.0 && git push origin v1.2.0
d8 package build --version "${CI_COMMIT_TAG#v}" --repo "$PACKAGE_BUILD_REPOSITORY"

Полная таблица команд d8 package — 📋 d8 .

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Разработка Application-пакета

Статьи и блоги

• Готовим Gitea со вкусом werf CI/CD в кластере Deckhouse. Часть 3 — Flant на Habr.
• GitLab + K8s + Werf — Habr.
• Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf — Flant на Habr.

Книги

• Gene Kim, Jez Humble, Patrick Debois, John Willis. The DevOps Handbook. 2nd ed., 2021. ISBN 978-1942788003.

Связанные материалы

• Предыдущий урок: M9.04 — dmtlint: практика анализа существующего Module.
• Следующий урок: M9.06 — Полный .gitlab-ci.yml.

✓ Урок пройден — все вопросы самопроверки отвечены верно