Релизы

Tuist использует систему непрерывного выпуска, которая автоматически публикует новые версии при слиянии значимых изменений с основной веткой. Такой подход гарантирует, что улучшения быстро дойдут до пользователей без ручного вмешательства со стороны сопровождающих.

Обзор

Мы постоянно выпускаем три основных компонента:

• Tuist CLI - инструмент командной строки
• Tuist Server - Внутренние службы
• Приложение Tuist – приложения для macOS и iOS (приложение для iOS постоянно развертывается только в TestFlight, подробнее здесь)

Каждый компонент имеет свой собственный конвейер выпуска, который запускается автоматически при каждом пуше в основную ветку.

Как это работает

1. Принятие условностей

Мы используем Conventional Commits для структурирования наших сообщений о фиксации. Это позволяет нашему инструментарию понимать природу изменений, определять переходы на новые версии и генерировать соответствующие журналы изменений.

Формат: Тип(область): описание

Типы обязательств и их влияние

Тип	Описание	Влияние версии	Пример
feat	Новая функция или возможность	Небольшое изменение версии (x.Y.z)	feat(cli): добавлена поддержка Swift 6
исправить	Исправление ошибок	Обновление версии патча (x.y.Z)	fix(app): устранение сбоя при открытии проектов
docs	Изменения в документации	Нет релизов	Документация: руководство по установке обновлений
стиль	Изменения в стиле кода	Нет релизов	стиль: форматирование кода с помощью swiftformat
рефактор	Рефакторинг кода	Нет релизов	refactor(server): упростить логику авторизации
perf	Улучшение производительности	Увеличение версии патча	perf(cli): оптимизация разрешения зависимостей
тест	Дополнения/изменения в испытаниях	Нет релизов	test: добавить модульные тесты для кэша
работа	Задачи технического обслуживания	Нет релизов	работа: обновление зависимостей
ci	Изменения CI/CD	Нет релизов	ci: добавить рабочий процесс для релизов

Разрывные изменения

Ломающие изменения приводят к переходу на основную версию (X.0.0) и должны быть указаны в теле коммита:

feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.

2. Обнаружение изменений

Каждый компонент использует git cliff для:

• Проанализируйте коммиты с момента выхода последнего релиза
• Фильтруйте коммиты по области применения (клиент, приложение, сервер)
• Определите, есть ли изменения, которые можно выпустить
• Автоматическое создание журналов изменений

3. Выпускной трубопровод

Когда обнаруживаются изменения, поддающиеся освобождению:

1. Расчет версии: Конвейер определяет номер следующей версии
2. Генерация журнала изменений: git cliff создает журнал изменений из сообщений коммита
3. Процесс сборки: Компонент собран и протестирован
4. Создание релиза: Создается релиз на GitHub с артефактами
5. Распространение: Обновления передаются менеджерам пакетов (например, Homebrew для CLI)

4. Фильтрация области действия

Каждый компонент выпускается только тогда, когда в нем происходят соответствующие изменения:

• CLI: Коммиты с диапазоном (cli) или без диапазона
• Приложение: Коммиты с областью применения (app)
• Сервер: Коммиты с охватом (сервер)

Написание хороших сообщений для фиксации

Поскольку сообщения о фиксации напрямую влияют на примечания к выпуску, важно писать ясные, описательные сообщения:

Делайте:

• Используйте настоящее время: "add feature", а не "added feature"
• Будьте краткими, но описательными
• Включите область применения, если изменения зависят от конкретного компонента
• Ссылки на проблемы, когда это применимо: исправление(cli): устранение проблемы с кэшем сборки (#1234)

Не надо:

• Используйте расплывчатые сообщения вроде "fix bug" или "update code"
• Смешивание нескольких несвязанных изменений в одном коммите
• Забудьте включить информацию об изменениях

Разрывные изменения

Для разрывных изменений включите BREAKING CHANGE: в тело коммита:

feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.

Рабочие процессы выпуска

Рабочие процессы выпуска определены в:

• .github/workflows/cli-release.yml - релизы CLI
• .github/workflows/app-release.yml - Релизы приложений
• .github/workflows/server-release.yml - Релизы сервера

Каждый рабочий процесс:

• Запускается при нажатии на кнопку
• Можно запускать вручную
• Использует git cliff для обнаружения изменений
• Дескриптор управляет всем процессом выпуска

Мониторинг релизов

Вы можете отслеживать выпуски через:

• Страница "Релизы GitHub"
• Вкладка "Действия GitHub" для запуска рабочего процесса
• Файлы Changelog в каждом каталоге компонентов

Преимущества

Такой подход к непрерывному выпуску обеспечивает:

• Быстрая доставка: Изменения попадают к пользователям сразу после объединения
• Сокращение "узких мест": Отсутствие необходимости ждать ручных релизов
• Четкая коммуникация: Автоматические журналы изменений из сообщений фиксации
• Последовательный процесс: Одинаковый поток выпуска для всех компонентов
• Гарантия качества: Выпускаются только проверенные изменения

Устранение неполадок

Если освобождение не удается:

1. Проверьте журналы GitHub Actions на предмет неудачного рабочего процесса
2. Убедитесь, что ваши сообщения о фиксации соответствуют общепринятому формату
3. Убедитесь, что все тесты пройдены
4. Проверьте успешность сборки компонента

Для срочных исправлений, требующих немедленного выпуска:

1. Убедитесь, что у вашего обязательства есть четкая сфера применения
2. После объединения контролируйте рабочий процесс выпуска
3. При необходимости запустите ручной спуск

Релиз в App Store

В то время как CLI и сервер следуют процессу непрерывного выпуска, описанному выше, приложение для iOS является исключением, связанным с процессом проверки Apple App Store:

• Ручные релизы: релизы iOS-приложений требуют ручной отправки в App Store
• Задержки с рецензированием: Каждый релиз должен пройти через процесс рассмотрения Apple, который может занять 1-7 дней
• Пакетные изменения: В каждом релизе iOS обычно объединяются несколько изменений
• TestFlight: Бета-версии могут распространяться через TestFlight до выхода в App Store
• Примечания к выпуску: Должны быть написаны специально для руководства App Store

Приложение для iOS по-прежнему следует тем же соглашениям о фиксации и использует git cliff для создания журнала изменений, но фактический выпуск для пользователей происходит реже и вручную.