Контролируемая интеграция изменений с непрерывной интеграцией

У меня есть установщик NSIS, который мы ранее построили с помощью сценариев nAnt, которые копируют некоторые файлы и запускают makensis.exe через задачу exec для сборки exe установщика. После завершения сценария nant у меня есть структура compelte для нашего CD, а также для загрузки.

Я просто делал get из sourcesafe на неиспользуемый рабочий стол и использовал его как поле сборки, компилируя там. Иногда мы проверяли пару файлов, которые исправляли что-то критическое. В таких случаях я бы пошел и очень выборочно получить только те файлы, чтобы избежать получения других измененных файлов, которые мы еще не готовы выпустить. В основном я могу позволить разработке продолжаться и выборочно включать определенные измененные файлы в установщик для выпуска.

Теперь у нас больше нет свободного ящика, и нужно строить с нашего сервера. Поэтому я настраиваю CI Factory, чтобы разработчик мог запустить сборку, не удаляясь на сервер. Единственный вопрос, с которым я борюсь, это лучший способ продолжать позволять этому выборочному контролю изменений происходить. Концепция по умолчанию CI, которую реализует Фабрика CI, хороша для внутренней разработки "головы". Однако я также хочу настроить проект CCNet, который выполняется только по требованию через принудительную сборку для этого типа сборки" public release".

Это то, что я штурмовал мозг до сих пор, не будучи уверенным, насколько хорошо это будет работать, если вообще (все еще выясняя, что такое CCNet и CI Factory). CCNet" public release" проект config / build будет настроен таким образом, что он будет не получать последнюю версию. Модификации не запускают сборку. Поскольку другой проект CCNet, использующий методологию CI по умолчанию (мы будем называть его "проектом CI") получения последней версии при обнаружении изменений, то эти два проекта не могут совместно использовать один и тот же рабочий каталог. Таким образом," публичный релиз " будет нуждаться в другой рабочей копии, чтобы его файлы не обновлялись при запуске сборки проекта CI. То разработчик должен был бы удаленно войти в сервер, один VSS, выборочно сделать вход в рабочую копию "public release", а затем принудительно построить через Фабрику CI.

Недостаток, который я вижу в этом, - это
1) наличие удаленного в выборочной не бывает.
2) я понятия не имею, как разрешить одному проекту фабрики CI иметь две разные рабочие копии папки продукта, чтобы каждый блок конфигурации проекта имел свой собственный.
3) я боюсь, что за странность эта может привести. Я еще не совсем уверен, как указать блок управления версиями в блоке конфигурации проекта CCNet, но не позволяйте ему делать get latest при сборке. Я все еще постепенно выясняю, какие вещи находятся в скриптах и могут быть легко удалены, не нарушая другие вещи, по сравнению с тем, что не предназначено для того, чтобы быть испорченным и/или не настраивается.

Я бы очень хотел услышать о том, как другие справляются с этой проблемой выборочного выпуска изменений, если у вас есть похожий ситуация. Я ограничен VSS, поэтому моя непосредственная потребность состоит в том, чтобы решить эту проблему с учетом этого, но в то же время мне было бы интересно услышать, как вы управляете этим с другими системами управления версиями. Я предполагаю, что вы, вероятно, будете иметь ветвь, которая является вашей последней ветвью разработок, а затем объединять изменения в ствол всякий раз, когда вы хотите их выпустить? Я действительно не доверяю VSS для ветвления / слияния, и я думаю, что концепции ветвления могут быть немного слишком большими накладными расходами и кривой обучения для этот магазин. Как я уже сказал, истории с другими системами управления версиями будут полезны для меня в будущем.

Заранее благодарю.