Несколько вопросов относительно TeamCity

Question

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

У меня был опыт работы с CC.NET, но только в небольших проектах и ​​ради изучения основ Это. В последнее время было немного больше свободного времени, поэтому решил попробовать TeamCity и установить его для большого проекта.

Есть, однако, две проблемы выскакивают на меня, когда дело со ссылками:

1) При работе с несколькими проектами, я стараюсь не делать большие решения, содержащие все из них (плюс не всегда возможно) , так как я также работаю с SVN, я использую относительные пути, которые указывают на скомпилированные сборки из других проектов (например .: .... \ Library A \ trunk \ Library \ bin \ release \ LibraryA.dll). Это всегда хорошо работало для меня и коллег, которые участвовали в проекте, но у меня возникли трудности с тем, чтобы проект TC забрал его, как мне настроить мои зависимости?

2) Одна из библиотек сделана другой компанией, а репозиторий SVN поделился с ними. Недавно им пришлось добавить доступ к БД Oracle, и они работают с поставщиком данных Oracle, который, похоже, работает со сборкой, зарегистрированной в GAC, но при создании решения он выводит другую аналогичную сборку, но с другой версией сборки (исправьте меня, если я ошибаюсь, я всегда работал со встроенным поставщиком Oracle, так как его было более чем достаточно). В моей компании мы работаем с этой «сборкой», и проект компилируется и работает отлично, но мы ранее должны были изменить ссылку, и изменение файла проекта в репозитории было бы невозможным, есть ли какая-нибудь работа для этого?

Спасибо за ваши ответы.

Answer 1

Спасибо за все ответы, выучил пару новых вещей.

Вчера можно было немного поиграть с ТС, узнать больше о правилах проверки VCS и узнать, что # 1 можно легко решить с помощью артефактов (с таким именем я не понял сначала, какими они были), поэтому Я использую это, и мои проекты построены без проблем.

Что вы думаете об этом подходе? Библиотеки дают мне проблемы, когда «основные» библиотеки одного и того же проекта, поэтому я уже создал для них проект.

Answer 2

Для 1) вы можете использовать Svn externals для захвата сборок и других зависимостей от других проектов, когда ваш проект построен TC.

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

Я потратил много времени на то, чтобы запустить CI-сервер на нашем месте, и он действительно окупился. Потребовалось немного времени, чтобы все было в порядке, но серьезно порекомендовало бы вам что-то запускать.

Извините, что не может помочь вам с 2).

Answer 3

Решено # 2 путем изменения ссылочных свойств и установки его не для поиска конкретной версии. Другая компания, похоже, приняла это.

Еще не успели проверить правила VCS Checkout для # 1.

Answer 4

Для 1) Вы можете установить ReferencePath для проектов и указать на каталоги с собранными сборками.

В нашей Конфигурации TC мы загружаем все зависимости TeamCity в SubDirectory под названием «Зависимости» и устанавливаем для компилятора в этот каталог.

С MSBuild Runner это очень просто:

В логове .proj для сборки необходимо определить свойство (мы называем его ReferencePath)

<PropertyGroup> 
    <ReferencePath>$(MSBuildProjectDirectory)\Dependencies\</ReferencePath> 
</PropertyGroup> 

И затем вызвать MSBuild Задача с ним :

<MSBuild Projects="$(ProjectFiles)" Properties="Configuration=Release;ReferencePath=$(ReferencePath)" Targets="Rebuild" /> 

@ (ProjectFiles) является простой ItemGroup, который собирает все .csproj -Files.

<ItemGroup> 
    <ProjectFiles Include="$(MSBuildProjectDirectory)\**\*.csproj" /> 
</ItemGroup>