У меня есть установщик NSIS, который мы ранее создали с использованием сценариев nAnt, которые копируют некоторые файлы и запускают makensis.exe через задачу exec для создания exe установщика. После завершения скрипта nant у меня есть структура compelte для нашего CD, а также наша загрузка.
Я просто делал переход от sourcesafe на неиспользуемый рабочий стол и использовал его в качестве сборки для компиляции. Иногда в этом исправлении мы проверяли пару файлов, что-то критичное. В этих случаях я бы пошел в окно сборки и очень избирательно получал только эти файлы, чтобы избежать получения других измененных файлов, которые мы еще не готовы выпустить. По сути, я могу позволить продолжить разработку и выборочно включать определенные измененные файлы в установщик для выпуска.
Теперь у нас больше нет бесплатного ящика, и нам нужно строить с нашего сервера. Поэтому я настраиваю CI Factory так, чтобы разработчик мог запустить сборку без удаленного взаимодействия с сервером. Единственная проблема, с которой я борюсь, - это лучший способ и впредь позволять этому избирательному контролю изменений происходить. Концепция по умолчанию CI, которую реализует CI Factory, подходит для внутреннего развития. Однако я также хочу настроить проект CCNet, который запускается только по требованию с помощью Force Build для этого типа «публичного выпуска».
Это то, о чем я до сих пор штурмовал, не зная, насколько хорошо это будет работать, если вообще будет (все еще выясняя, что такое CCNet и CI Factory). Конфигурация / сборка проекта CCNet «публичного выпуска» будет настроена таким образом, чтобы , а не , получалось самым последним. Модификации не вызовут сборку. Так как другой проект CCNet, использующий методологию CI по умолчанию (мы будем называть его «проектом CI»), получает последние данные при обнаружении изменений, тогда эти два проекта не могут использовать один и тот же рабочий каталог. Поэтому для «публичного выпуска» потребуется другая рабочая копия, чтобы его файлы не обновлялись при запуске сборки CI-проекта. Разработчику потребуется удаленно подключиться к серверу, одному VSS, выборочно получить рабочую копию «публичного релиза», а затем форсировать сборку с помощью CI Factory.
С этим я сталкиваюсь с недостатком
1) Необходимость удаленного доступа для выборочного получения.
2) Я понятия не имею, как разрешить одному проекту CI Factory иметь две разные рабочие копии папки Product, чтобы у каждого блока конфигурации проекта была своя собственная.
3) Я боюсь какой странности это может вызвать. Я пока не совсем уверен, как указать блок управления исходным кодом в блоке конфигурации проекта CCNet, но мешаю ему получить последнюю версию при сборке. Я все еще постепенно выясняю, что находится в сценариях и может быть легко удалено, не нарушая другие вещи, по сравнению с тем, что не предназначено для того, чтобы быть обманутым и / или не настраиваемым.
Мне бы очень хотелось услышать о том, как другие решают проблему выборочного выпуска изменений, если у вас похожая ситуация. Я ограничен VSS, поэтому моя непосредственная потребность - решить это с учетом этого, но в то же время мне было бы интересно услышать, как вы управляете этим с другими системами контроля версий. Я предполагаю, что у вас, вероятно, будет ветвь, которая является вашей последней веткой разработок, и затем сливать изменения в ствол всякий раз, когда вы хотите выпустить их? Я действительно не доверяю VSS для ветвления / слияния, и я думаю, что концепции ветвления могут быть слишком большими накладными расходами и кривой обучения для этого магазина. Как я уже сказал, истории с другими системами контроля версий будут полезны для меня в будущем.
Заранее спасибо.