Как компенсировать различия в среде между машинами разработки и серверами сборки?

Question

NUnit установлен на моем компьютере в «C: \ Program Files \ NUnit 2.4.8 \», но на моем сервере интеграции (запущенном CruiseControl.Net) он установлен в «D: \ Program Files \ NUnit 2.4». 8 \». Проблема в том, что на моей машине разработки мой сборочный файл NAnt работает правильно, потому что в задаче я использую путь "C: \ Program Files \ NUnit 2.4.8 \ bin \ NUnit.Framework.dll", чтобы добавить ссылку на ' NUnit.Framework.dll 'сборка, но этот же файл сборки не может создать файл на моем сервере интеграции (потому что путь ссылки другой). Должен ли мой NUnit быть установлен в том же месте, что и на моем сервере интеграции? Это решение кажется мне слишком ограничительным. Есть ли лучшие? Каково общее решение этой проблемы?

Answer 1

Обычно я распространяю NUnit и любые другие зависимости с моим проектом в каком-то обычном месте (для меня это каталог libs на верхнем уровне).

/MyApp
  /libs
    /NUnit
    /NAnt
    /etc...
  /src
    /etc...

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

Answer 2

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

Тем не менее, достижение этой цели - серьезная работа.

Answer 3

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

Answer 4

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

Нет, давайте определим <property>, который можно переопределить с помощью -Dname=value. Вы можете использовать это, чтобы иметь местоположение по умолчанию для ваших машин разработки, которое вы переопределяете в своей системе CI.

Вы также можете получить значения переменных среды, используя environment::get-variable для изменения местоположения на машину.

Answer 5

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

Или вы можете настроить свой сценарий так, чтобы переменная окружения NUNIT_HOME была установлена ​​для работы NUNIT. Теперь вместо того, чтобы требовать, чтобы на машине, на которой он работает, nUnit находился в определенном месте, ваш сценарий требует, чтобы nunit присутствовал и был доступен в переменной окружения.

Любой подход позволит вам изменить используемую вами версию nunit без изменения сценария сборки, это то, что вам нужно?

Answer 6

Я бы использовал два подхода:

1) использовать два разных сценария подготовки (сборка разработчика / сборка интеграции) с разными путями.

2) поместите все необходимые исполняемые файлы в вашу папку path и вызовите их напрямую.