Как обрабатывать несколько конфигураций Visual Studio при непрерывной интеграции? - PullRequest
Новая
       7

Как обрабатывать несколько конфигураций Visual Studio при непрерывной интеграции?

1 голос
/ 20 апреля 2011

У меня есть несколько конфигураций, настроенных в Visual Studio, чтобы я мог создать одно решение (содержащее несколько проектов) для одного из множества клиентов.Небольшое количество настроек web.config настраивается в зависимости от клиента, и код создается для другого BuildDir, поэтому я могу его упаковать и доставить.На данный момент все это происходит из Visual Studio Configuration Manager на моем компьютере разработчика в сочетании с несколькими проектами веб-развертывания, и я нахожу это довольно хрупким.

Я хочу реализовать сервер CI (CC.Net или TeamCity), но я не уверен, как наилучшим образом приспособить этот тип конфигурации для каждого клиента (или, если я должен попытаться).Я развиваюсь в ветке и реинтегрируюсь со стволом, когда каждая функция завершена.Правильно ли я считаю, что сервер CI должен интегрировать код в транк, и если да, то как мне работать с отладочными и релизными сборками для каждого клиента?

Мои конфигурации:

  • Разработка (отладка)
  • Проверка (отладка)
  • UAT - Cust.1 (выпуск)
  • Производство - Cust.1 (выпуск)
  • UAT - Cust.2 (выпуск)
  • Производство - Каст.2 (выпуск)
  • и т. Д.

Помимо небольшого количества параметров конфигурации для каждого клиента, продукт практически одинаков для всех.

Я хочу узнать ваши мысли о том, как я могу это настроить, или я думаю об этом неправильно?

Спасибо.

Ответы [ 2 ]

1 голос
/ 20 апреля 2011

Мы придерживались двухэтапной процедуры сборки: первое решение обычно строится с настройкой Debug / Release.Далее (после процедуры завершения сборки) запускается задача для преобразования web.configs (это если для одного файла, но это может быть легко исправлено для обработки нескольких из них): 

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
<Target Name="TransformWebConfig">
    <TransformXml Source="$(WebFolderName)Web.config"
        Transform="$(WebConfigsFolderName)Web.$(WebConfiguration).config"
        Destination="$(WebFolderName)Web.config" />
</Target>

Таким образом
1) У вас есть только две значимые конфигурации в файле решения
2) На сервере сборки вы передаете два свойства: Configuration (например, Release) и WebConfiguration (например, UATCust2)
3) Эта задача выполняется только на сервере сборки, поскольку он является частью более крупного сценария сборки: разработчики всегда работают с конфигурацией отладки / выпуска по умолчанию, конфигурации целевой платформы могут храниться отдельно, например, в защищенном разделе в хранилище или даже на общем сетевом ресурсе.

0 голосов
/ 08 декабря 2011

Я решил это, используя UppercuT , RoundHousE и CC.Net, и изменив способ ветвления и пометки различных конфигураций в SVN.Теперь у меня есть одна «основная линия» кода (транк), которая автоматически создается CC.Net/UppercuT на сервере сборки и затем становится доступной для упаковки и развертывания с помощью UppercuT.Если мне нужно создать источник для конкретного клиента, я могу получить его источник, внести необходимые изменения, а затем отправить обратно в его филиал.Запуск UppercuT в этой ветке затем создает развертываемый пакет для этого клиента.Комбинация UppercuT и NAnt обеспечивает гораздо большую гибкость IMO, чем при использовании Configuration Manager VS2010.

...