Предпочитаемый подход к экологическому строительству с Rake?(Исходя из Msbuild / Nant) - PullRequest
Новая
       50

Предпочитаемый подход к экологическому строительству с Rake?(Исходя из Msbuild / Nant)

1 голос
/ 22 февраля 2012

Я написал и поддерживал много файлов Nant / Msbuild, и у меня есть несколько проблем в текущем проекте, где кажется, что rake сделает мою жизнь намного проще. Однако я немного озадачен первым препятствием, но это может быть потому, что я смотрю на проблему глазами Нанта.

Чтобы дать некоторый контекст здесь, я обычно ожидаю, что мои сборки будут размечены (забывая фактическую физическую структуру, просто посмотрите, каковы ее компоненты): 

- Root
  | - build-scripts
      | - default.build
      | - *.build
  | - build-properties
      | - dev.properties
      | - live.properties
      | - *.properties
  | - tools
      | - Nant
          | - Nant.exe
          | - *.*
      | - Nunit
          | - Nunit.exe
          | - *.*
      | - **/*.*

Теперь, как вы можете видеть выше, основными компонентами сборки являются сценарии сборки, которые содержат действительные инструкции по сборке, свойства сборки, которые представляют собой файлы, содержащие только свойства для каждой среды. * 1006 т.е. *

dev.properties может содержать web.service.url = "http://some.dev.address" live.properties может содержать web.service.url = "http://some.live.address"

Затем существуют инструменты, которые являются внешними исполняемыми файлами, используемыми сценариями сборки, такими как Nant, Nunit, JsTestDriver и т. Д.

Теперь, сконцентрировавшись на моем файле default.build, он, как правило, содержит множество открытых свойств, таких как используемые каталоги (например, libs, output, package, project, tests), так что все они могут быть оценены заранее. Затем другие файлы * .build содержат соответствующие сценарии сборки, такие как tests.build, будут работать с Nunit и запускать тесты Unit / Integration / Acceptance и т. Д.

Основная проблема для меня заключается в том, что у меня есть эти свойства среды, которые настраивают сборку для каждой среды, а затем множество предопределенных свойств, которые переопределяются при вызове из командной строки, т.е. вы передаете environment = live если вы собирали для живого окружения, или если вы оставили его пустым, по умолчанию среда была бы равна dev, а на сервере CI она установила бы окружение ci.

Ни один из примеров, которые я могу найти, кажется, не говорит мне, как иметь свойства / переменные по умолчанию, которые переопределяются командной строкой с помощью Rake. Я знаю, что вы можете установить свойства и получить их через механизм Env [], но чтобы используйте это, мне нужно было бы установить глобальную переменную как обычно, затем выполнить шаг, который проверяет все переданные переменные env и перезаписывает глобальные переменные с этими свойствами, также единственный способ разрешить использование внешних файлов конфигурации - использовать глобальные переменные внутри их и включите в него, что я не против сделать, но я надеялся, что в этой области есть несколько лучших практик, из которых я мог бы извлечь уроки.

И последнее, о чем я подумал, это то, что единственной переменной, которая должна быть передана, будет среда (dev, ci, live и т. Д.), Чтобы я мог сделать так, чтобы задача сборки по умолчанию требовала передачи аргумента в , который поддерживается, но не уверен, что это лучше, так как я хотел бы, чтобы он запускался как «dev», если ничего не было установлено, и это означает, что вам всегда нужно будет устанавливать его (не конец света).

Как вы можете видеть, в этой области довольно много вопросов, использующих мой существующий подход и пытающихся адаптировать его для работы с Rake. Любой совет или информация будут великолепны!

1 Ответ

0 голосов
/ 15 марта 2012

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

$dir["project"] = "c:/Some/Project/Dir"
$dir["tests"] = "c:/Some/Tests/Dir"
$settings["auto-migrate-deltas"] = true

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

...