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

Question

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

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

Теперь у нас больше нет бесплатного бокса, и нужно собирать со своего сервера.Поэтому я настраиваю 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 создавать оттуда, но запускать вручную.

Посмотрите эти шаблоны ветвления.Я предложил C3, кодовую строку для каждой версии, которую часто называют ветвлением выпуска.

Вот статья о ветвлении VSS, которое включает ссылку на слияние.

Этот вопрос выглядит похоже.

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