Выбор рабочего процесса

Введение

Lingo.dev CI/CD создан для гибкой интеграции с любыми существующими workflow. На этой странице приведены рекомендуемые варианты рабочих процессов, с которых можно начать.

Примечание: Нет единственно "лучшего" workflow. Каждый вариант имеет свои плюсы и минусы и будет удобен разным пользователям в зависимости от их предпочтений, размера команды и устоявшихся процессов.

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

Вариант 1: Коммит в основную ветку

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

Лучше всего подходит для

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

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

Полная автоматизация — не требуется участие человека
Переводы сразу доступны в основной ветке
Самая простая настройка и поддержка
Не нужно создавать дополнительные ветки или pull request

Компромиссы

Нет процесса ревью переводов
Коммиты переводов могут запускать дополнительные CI-сборки
Изменения появляются сразу в основной ветке без прозрачности, что именно было переведено
Меньше контроля над моментом деплоя переводов

Вариант 2: Pull request из основной ветки

После того как контент попал в основную ветку, переводы генерируются и отправляются как новый pull request из основной ветки.

Лучше всего подходит для

Команд, которым важна прозрачность и возможность ревью переводов, при этом процесс остаётся централизованным в основной ветке.

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

Изменения переводов видны и доступны для ревью до слияния
Чёткая история того, что было переведено
Возможность вручную доработать переводы перед принятием
Чистая история основной ветки с отдельными коммитами переводов

Компромиссы

Требуется ручное одобрение pull request (если не настроен auto-merge)
Небольшая задержка между изменениями контента и появлением перевода
Дополнительные pull request'ы для управления в вашем рабочем процессе

Вариант 3: Коммит в feature-ветку

Когда изменения контента вносятся в feature-ветки, переводы автоматически генерируются и коммитятся прямо в эти же ветки.

Лучше всего подходит для

Команд, которые работают с долгоживущими feature-ветками и хотят, чтобы переводы были частью процесса разработки фичи.

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

Переводы готовы, когда готова сама фича
Не нужно отдельно заниматься переводом во время ревью фичи
Завершённые фичи включают и контент, и переводы
Хорошо работает с деплоем через feature-флаги

Компромиссы

Коммиты с переводами появляются в истории feature-ветки
Возможны конфликты при слиянии, если несколько разработчиков работают в одной ветке
Переводы привязаны к завершению фичи, а не к готовности контента
Могут появиться переводы для экспериментальных фич, которые так и не выйдут в релиз

Вариант 4: Pull request из feature-ветки

Когда изменения контента происходят в feature-ветках, переводы генерируются и отправляются как отдельные pull request'ы из этих веток.

Лучше всего подходит для

Команд, которым нужен максимальный контроль и видимость переводов при сохранении работы с feature-ветками.

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

Полная видимость изменений переводов на уровне фичи
Возможность проверить и скорректировать переводы до завершения фичи
Чистое разделение между разработкой фичи и интеграцией перевода
Гибкое время для принятия обновлений перевода

Компромиссы

Самый сложный рабочий процесс для управления
Несколько pull request'ов на одну фичу (фича + переводы)
Pull request'ы с переводами могут устареть, если фича меняется
Требуется координация между pull request'ами фичи и перевода