Пара вопросов относительно TeamCity

Question

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

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

Однако при работе со ссылками у меня возникают две проблемы:

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

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

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

Answer 1

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

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

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

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

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

А затем вызовите задачу MSBuild с ней:

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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