Ссылка на артефакты сборки из svn: external build в проекте .Net

Это вопрос-продолжение из предыдущего вопроса, я задал

Теперь у меня есть каталог / externals в корне дерева моего проекта. Внутри у меня есть ссылка на другой проект. Я могу записать сборку всех моих внешних компонентов в основной проект NAnt script. Результат этих сборок следующий:

/ externals / external-project1 / build / buildartifacts / {библиотеки DLL | HTML | js}

/ externals / external-project2 / build / buildartifacts / {библиотеки DLL | HTML | js}

Это все хорошо, но теперь мне любопытно, как мой основной проект должен ссылаться на эти артефакты сборки. Например, предположим, что внешний проект создает DLL, от которой зависит часть моей кодовой базы. Должен ли я просто ссылаться на DLL в каталоге артефактов сборки или мне следует реализовать другую задачу NAnt, которая копирует их в папку / thirdparty / libs /?

Это означает, что моя сборка теперь зависит от возможности сборки этого внешнего проекта (который может быть внутренним или сторонним). Стоит ли проверять последний набор артефактов сборки, чтобы гарантировать, что основная сборка не сломается из-за поломки зависимых сборок?

Надеюсь, это достаточно ясно. Просто запись этого как минимум прояснила для меня проблему :-).

--Редактировать--

Спасибо, парни. Думаю, я собираюсь реализовать «проверку ревизии», но, поскольку сборки выполняются очень быстро, я не собираюсь проверять какие-либо артефакты сборки. Также нужно будет выяснить, как бороться с зависимостями внешнего проекта (например, прототипа, swfobject и т. Д.).


svn build-process nant
person Scott Muc    schedule 02.10.2008    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы сказал, создайте их один раз и проверьте артефакты сборки в / public / ext / some_dependency / ref (очевидно, название этой папки зависит от вас :-)) и ссылайтесь на них оттуда.

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

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

person Franci Penov    schedule 02.10.2008

arrow_upward
1
arrow_downward

Одна из моих рекомендаций (которая, как мне кажется, пришла из книги «Прагматический контроль версий» Майка Мейсона) относится к конкретной ревизии во внешней версии, чтобы вы всегда получали одну и ту же версию внешней зависимости, пока вы явно не решите ее изменить.

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

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

person marcj    schedule 02.10.2008