В довольно хорошем обсуждении о стратегиях ветвления, которое мы недавно провели, ответ jgifford25 содержал ссылку на то, что один из разработчиков Subversion назвал гибкой стратегией выпуска и выглядит довольно похоже на то, что предлагают ребята из Plastic - ветвь для каждой функции, сливающаяся с ветвями релиза, а не в ствол.Я не думал, что это хорошая идея, и я не думаю, что это хорошая идея.Я также не думаю, что это совпадение, что в обоих случаях идея выдвигается разработчиком SCM - я думаю, что у этих ребят есть случай «все выглядит как гвоздь», и думаю, что любую проблему процесса можно решить с помощью большего количестваи больше SCM.
Так почему эта идея плоха?Давайте следовать аргументу пластиковых парней.Они строят этот процесс вокруг одной центральной идеи: «сохранить основную линию нетронутой».Все идет нормально.Затем они продвигают силлогизм, который выглядит следующим образом:
- Если вы проверяете неработающий код в транке, то сборки ломаются
- Сломанные сборки плохи
- Поэтому не проверять код в транке
Проблема в том, что он совершенно неправильно понимает , почему сломанные сборки плохие.Сломанные сборки сами по себе неплохие (хотя они бесполезны, потому что они тормозят разработку), они плохие, потому что они означают, что кто-то проверил взломанный код .Это сломанный код, это реальная проблема, а не сломанные сборки - это сломанный код, который действительно может нанести ущерб (потерянные пользовательские данные, потерянные пробники, глобальная термоядерная война и тому подобное).
ИхРешение, таким образом, сводится к тому, что люди проверяют свой неработающий код в другом месте, чтобы оно не нарушало сборку.Это, очевидно, ничего не делает для решения реальной проблемы неработающего кода - напротив, это способ сокрытия неработающего кода.Действительно, мне не ясно, в какой момент обнаруживается поломка - когда ветки задач завершаются и объединяются с веткой выпуска?Это звучит как отличный способ отложить трудную работу до конца цикла выпуска, что является очень плохой идеей.
Реальное решение, скорее, довольно просто вообще не проверять неработающий код .В достижении этой цели сломанная сборка на самом деле хороша , потому что она говорит вам, что есть сломанный код, который позволяет вам его исправить.В этом, собственно, и заключается весь смысл идеи непрерывной интеграции - ваше слияние рано и часто в одну магистраль, являющуюся прототипом того, что на самом деле будет выпущено, поэтому вы обнаружите проблемы с тем, что вы намереваетесь выпустить уже в началевозможный.Для этого абсолютно необходима модель 'нестабильного ствола' или что-то изоморфное ей.
В блоге , в котором ответ orangepips ссылается на идею Ubuntu о процессе как драйвередля этой идеи.Но посмотрите на то, что на самом деле сказал Шаттлворт:
- Сохраняйте ствол нетронутым
- Сохраняйте функции текущими
- Выпуск по требованию
Это мой акцент на последнем пункте, но это конечная цель Шаттлворта: он хочет иметь возможность выпускать релизы в любое время.Процесс, который откладывает слияние и тестирование до процесса выпуска, как это делает модель Plastic, не может этого сделать.
Скорее, если вы хотите увидеть, как выглядит процесс, который может это сделать, посмотрите на что делают худые парни : одна кодовая строка, непрерывная интеграция (в масштабе часов или даже минут, а не дней или недель), без битого кода.
Итак, в заключение: не надосделай это.Имейте одну кодовую строку и проверяйте рабочий код в ней как можно чаще.Просто.
PS Хорошо, так что вы можете захотеть сделать ветки релизов для стабилизации и исправления ошибок в реальных релизах.В идеале вы этого не сделаете, но вам может понадобиться.
PPS И если у вас есть набор тестов CI, который слишком медленный для запуска перед регистрацией (например, функциональные тесты, которые занимают час), то вы можете сделать с любым DVCS два репозитория: грязный, где разработчикислиться с чистым, который выдвигается скриптом, который следит за грязным репозиторием на предмет изменений, создает и тестирует новые версии, поступающие в него, и передает в чистый репозиторий, если они проходят.После этого вы можете запускать выпуски по требованию (для QA и т. Д.) Из чистого репозитория, а разработчики могут обновляться из чистого репозитория, чтобы оставаться в курсе событий в процессе разработки.Однако им, очевидно, придется обновляться из грязного хранилища непосредственно перед слиянием.