# Релизы

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

## Обзор

Мы постоянно выпускаем три основных компонента:
- **Tuist CLI** - инструмент командной строки
- **Tuist Server** - Внутренние службы
- **Приложение Tuist** – приложения для macOS и iOS (приложение для iOS
  постоянно развертывается только в TestFlight, подробнее
  [здесь](#app-store-release))

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

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

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

Мы используем [Conventional Commits](https://www.conventionalcommits.org/) для
структурирования наших сообщений о фиксации. Это позволяет нашему инструментарию
понимать природу изменений, определять переходы на новые версии и генерировать
соответствующие журналы изменений.

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

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

| Тип         | Описание                          | Влияние версии                     | Пример                                              |
| ----------- | --------------------------------- | ---------------------------------- | --------------------------------------------------- |
| `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](https://git-cliff.org/) для:
- Проанализируйте коммиты с момента выхода последнего релиза
- Фильтруйте коммиты по области применения (клиент, приложение, сервер)
- Определите, есть ли изменения, которые можно выпустить
- Автоматическое создание журналов изменений

### 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"](https://github.com/tuist/tuist/releases)
- Вкладка "Действия 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 для создания журнала изменений, но фактический выпуск для
пользователей происходит реже и вручную.