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

Введение

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

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

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

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

Компромиссы

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