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

Question

У меня есть установщик NSIS, который мы ранее построили с помощью скриптов nAnt, которые копируют некоторые файлы и запускают файл makensis.exe с помощью задачи exec для сборки exe-установки. После завершения nant-скрипта у меня есть сводная структура для нашего 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 для ветвления/слияния, и я думаю, что концепции ветвления могут быть слишком большими накладными расходами и кривой обучения для этого магазина. Как я уже сказал, истории с другими системами контроля версий будут полезны будущим знаниям для меня.

Заранее спасибо.

Answer 1

Для облегчения этого вам нужна структура ветвления в вашем репозитории. Что-то вроде метода ветвления релиза. Только отдельные люди могут передать эту ветку (или для этого есть релиз/стабильный).Настройте свои ручные CI-запуска, чтобы вытащить из ветки релиза, так как релиз каждую ночь продвигается к этапу или финалу. Мне не нравится идея изменения вручную на вашей машине сборки. Настройте изменения в управлении версиями, в безопасном месте, чтобы подготовить выпуск и позволить CI строить там, но запускается вручную.

Проверьте эти branching patterns. Я предложил C3, codeline-per-release, часто называемый ветвлением разветвления.

Heres a article на ветвление VSS, включающее ссылку на объединение.

Этот question выглядит аналогичным.

Возможно, вы можете перейти к другой системе управления источниками с лучшей поддержкой такого рода вещей. Любые предложения от людей MS там?