Наш проект был преобразован от svn к git. Разработчики сейчас используют git-svn, но хотели бы перейти к использованию большей мощности под капотом. Список желаний:
- мощное ветвление, например, тематические / функциональные ветки
- изоляция основной и промежуточной работы над релизами, иногда несколько параллельных.
- компактная, средняя и стабильная установка Jenkins-CI - минимальное обслуживание (по сравнению с изменением конфигурации задания после каждого выпуска)
- короткие итерации, команда разработчиков выпускает QA каждые 2 недели; не обязательно снаружи
- несколько продуктов (P1..P3), созданных из одних и тех же источников, выпущенных независимо; с переменным давлением
- иметь больше случайных пользователей, не связанных с git, в "большой команде" ... они S&U :) .. но мы должны предоставить им svn доступ как минимум к 1 ветке (транку). Их вклад ограничен несколькими каталогами, поэтому здесь нет большого риска конфликта.
Сработает ли следующая стратегия?
- develop: основная ветка, в которой происходит разработка, a'la git-flow
- стабильные продуктовые отрасли: product1 .. product3. Один или несколько из них будут объединены с основной линией после выпуска разработчика. Похоже на «начало выпуска 1.4.3» в git flow, но это будут постоянные ответвления. Релизы будут помечены здесь, а затем объединены для разработки. На данный момент было бы стабильно, как master в git-flow, всего несколько из них.
- прекратить использовать git-svn напрямую - вместо этого подталкивать / тянуть к зеркалу. При необходимости также можно использовать ветки функций.
- объединить svn / trunk -> разработать. Svn будет получать случайные и отдельные проверки; поэтому планируем автоматизировать его с помощью задания Jenkins, уведомляя людей, если он не удался, чтобы его можно было объединить вручную
- merge develop-> svn / trunk: регулярно (например, ежедневно) в пакетном режиме. Это, наверное, самая шаткая часть (по крайней мере, для новичков). Планирование чего-то вроде перебазирования или какого-нибудь волшебного средства сброса
- Настройка CI будет простой, например, тестирование и разработка строятся вне основной ветки, официальный продукт строится из своих собственных веток продукта.
Git-Flow заманчиво - в основном потому, что он хорошо описан и автоматизирован. . Но это не кажется идеальным вариантом для моего случая; в основном из-за потенциально параллельных выпусков, нескольких линеек продуктов и CI аспекты.
Будем очень признательны за любые информированные мнения.
