Как устроен релиз open-source проекта: разбор Firezone
Как устроен релиз open-source проекта: разбор Firezone
Выпустить обновление приложения — это не только собрать бинарник. В зрелых open-source проектах релиз превращается в отлаженный конвейер с проверками, согласованиями и автоматикой. На примере Firezone — открытого решения для защищённого доступа к сети — видно, как такой процесс выглядит изнутри.
Клиенты для сторов — отдельная ветка процесса
Мобильные и десктопные приложения Firezone публикуются через магазины Apple и Google. Для этого запускаются отдельные workflow: сборка для Android уходит в Firebase App Distribution и внутреннее тестирование Google Play, а сборка для Apple — в TestFlight. После проверки QA релиз подаётся на ревью через отдельный workflow, который сначала готовит версию и ждёт ручного подтверждения в защищённом окружении. Примечательная деталь: в окружении app-store намеренно не настраивают обязательных ревьюеров — воротами служит отдельное окружение app-store-review.
Компоненты для Linux, Windows и шлюза
Для настольных и серверных сборок логика другая: инженер открывает черновик релиза, проверяет, что артефакты собраны свежим CI и содержат нужные изменения, и публикует его. Публикация автоматически запускает workflow, который открывает два pull request — один обновляет версию во всём продукте через скрипт bump-versions.sh, второй в отдельном репозитории сайта превращает раздел changelog «Unreleased» в датированную запись и обновляет отображаемые версии. Оба PR нужно проверить и смержить — и только после деплоя сайта он начнёт перенаправлять на новую версию. Авторы честно отмечают возникающий разрыв: GitHub уже знает о релизе, а остальные — ещё нет. Это осознанный компромисс, который можно откатить.
Версии всех публикуемых компонентов задаются централизованно, а не вручную в каждом файле проекта. Такой подход снижает риск рассинхронизации между приложениями, сайтом и документацией. Подробности процесса описаны в гайде для мейнтейнеров.
Что это значит
Для команд, поддерживающих open-source, такой разбор — хороший ориентир: ручные подтверждения там, где ошибка дорого стоит, и полная автоматика там, где нужна скорость. Разделение черновика, публикации и обновления сайта позволяет не смешивать кодовые изменения с релизными и держать историю версий прозрачной. Для пользователей это означает предсказуемые обновления и меньше сюрпризов после установки.
Если вам интересно, как устроены процессы сборки и релизов в современных проектах, изучите материалы о CI/CD и автоматизации — это навык, который пригодится в любой команде. Узнайте больше.
📌 Чтобы не пропустить новые публикации, подписывайтесь там, где вам удобнее: Дзен или MAX.
💛 Если статья оказалась полезной, поддержите автора донатом.
Материал подготовлен на основе информации из открытых источников. Все права на исходные материалы принадлежат их авторам. Если вы являетесь правообладателем и возражаете против использования, свяжитесь с нами по адресу info@11st.press.
