Различные решения/файлы проектов для локальных и сборочных сред

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

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

Кроме того, ссылочные пути находятся в файлах csproj.user, что означает, что они должны быть зафиксированы в системе управления версиями, поэтому все должны использовать одни и те же настройки.

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

У него есть очевидные недостатки, такие как накладные расходы на поддержку этих отдельных файлов и связанного с ними процесса, который необходимо определить и соблюдать, но у него есть преимущества, заключающиеся в том, что мы будем лучше контролировать ТОЧНО то, что происходит в производственную среду.

Чего я не смог найти, так это ничего по этому вопросу - не могу поверить, что мы единственные, кто думает об этом, - поэтому приветствуются любые мысли.


person Duncan    schedule 18.08.2008    source источник


Ответы (6)


Я знаю, что это анахронизм. Но единственный лучший способ, который я нашел для решения проблемы со ссылками, — это сопоставить папку с буквой диска, такой как R:, а затем все проекты встраиваются или копируют выходные данные в эту папку. Тогда все ссылки будут R:\SomeFile.dll и т. д. Это избавит вас от проблемы, заключающейся в том, что иногда ссылки добавляются по абсолютному пути, а иногда — относительно. (есть что-то связанное с "HintPath", чего я не могу вспомнить)

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

person Shaun Austin    schedule 21.08.2008

В нашем крупнейшем проекте (система, состоящая из множества приложений) у нас есть следующая структура

/3rdPartyAssemblies
/App1
/App2
/App3
/.....

Все внешние сборки добавляются в 3rdPartyAssemblies/Vendor/Version/...

У нас есть файл CoreBuild.sln, который действует как сценарий MSBuild для всех совместно используемых сборок, чтобы обеспечить построение в порядке зависимости (т. е. убедитесь, что App1.Interfaces собран до App2, поскольку App2 имеет ссылку на App1.Interfaces).

Все ссылки между приложениями нацелены на папку /bin (мы не используем bin/debug и bin/release, только bin, таким образом, ссылки остаются прежними, и мы просто меняем конфигурацию выпуска в зависимости от цели сборки).

Cruise Control создает основное решение для любых зависимостей перед созданием любого другого приложения, а поскольку папка 3rdPartAssemblies присутствует на сервере, мы гарантируем, что компьютеры разработчика и сервер сборки имеют одинаковую схему разработки.

person DavidWhitney    schedule 21.08.2008

Обычно вы создаете проекты/скрипты сборки в той или иной форме для вашего производства, поэтому сборка другого файла решения не входит в картину.

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

person Vaibhav    schedule 18.08.2008

Мы изменили структуру нашего проекта (используя SVN Externals), где каждый проект теперь полностью автономен. То есть никакие ссылки никогда не выходят за пределы каталога проекта (например, если проект A ссылается на ASM X, то ASM X существует во вложенной папке ProjectA).

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

person Duncan    schedule 21.08.2008

@David - верьте или нет, это то, что у нас есть на самом деле сейчас, и все же это все еще вызывает у нас проблемы!

Однако мы вносим некоторые изменения, которые навязаны нам из-за перехода на TeamCity и несколько агентов сборки, поэтому у нас не может быть ссылок на каталоги вне текущего проекта, как я упоминал в своем предыдущем ответе.

Посмотрите раздел «Внешние» этой ссылки, чтобы понять, что я имею в виду — http://www.dummzeuch.de/delphi/subversion/english.html

person Duncan    schedule 21.08.2008

Я бы настоятельно рекомендовал против этого.

  1. Ссылочные пути хранятся не только в файле .user. Путь подсказки хранится в самом файле проекта. Вам никогда не придется проверять файл .user в системе управления версиями.

  2. Пусть будет один набор (хорошо, возможно, версии) файлов решения/проекта, которые используют все разработчики, и конфигурации выпуска, которые вы в конечном итоге создаете в рабочей среде. Наличие отдельных файлов проекта вызовет путаницу в будущем, когда некоторые настройки проекта будут изменены, не перенесены и отправлены в производство.

Вы также можете проверить это:

http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html

person Community    schedule 18.08.2008