Введение Сегодня ( Понедельник, 26 апреля 2010 г.
, 8:54 утра? Обратите внимание на перевод ) еще раз написал в Твиттере, что я не фанат систем сборки проектов на основе XML. Да, я понимаю, зачем они нужны.
Да, они были хороши в свое время.
И да, я до сих пор использую их каждый день.
Но, несмотря на все это, я считаю, что есть более эффективные способы решения этой проблемы.
Самый распространенный ответ на мой твит был: «Ну, а какая альтернативаЭ» Одна из самых важных вещей, которой меня научила жизнь, — не следует жаловаться на что-то, пока вам нечего предложить взамен.
Поэтому здесь и сейчас я предложу альтернативное решение.
Проблема
Прежде чем мы с головой погрузимся в дискуссию, позвольте задать вам вопрос.что есть у разработчиков( программисты, ок.
перевод ) у тебя получается лучше всего? Отвечу за себя так: написать код .
В таком случае, зачем нам крутить мозги, запихивая «многобуквы» в чудовищные XML-файлы? Почему мы не можем просто писать код? Обычно говорят, что приложения на основе XML облегчают внесение изменений без перекомпиляции, обладают большей гибкостью и упрощают написание инструментов, поскольку они основаны на формате, понятном каждому.
Но лично я не думаю, что этот инструмент настолько ценен.
Для меня это скорее всего лишь остатки былой истерии по поводу XML, которая имела место в мире программирования несколько лет назад. Те, кто работает с такими системами сборки несколько лет, могут подтвердить, что поначалу они выглядели смешно и глупо.
Люди настолько увлечены прославлением XML, что забывают указать, чего мы упускаем, написав код на XML. Например, как насчет всех тех инструментов, на совершенствование которых наша отрасль потратила так много времени? Мы теряем наши обычные редакторы, отладчики, библиотеки и другие инструменты только для того, чтобы воспользоваться несколькими незначительными преимуществами XML. Не каждую задачу можно описать в XML. В конце концов, XML-файлы — это просто система конфигурации для кода, выполняющегося в фоновом режиме.
В конце концов, мы всё же возвращаемся к написанию скриптов, запускаемых через конфигурацию в XML. Так в чем же преимущества XML? Можем ли мы легко его разобрать? Но как часто вы пишете парсер для файлов сборщика? Вы просто пишете конфигурацию XML и передаете ее в NAnt. Вам не нужно ничего разбирать самостоятельно.
Нет необходимости в компиляции? Ладно, первый достойный аргумент, ведь мы не хотим собирать наш билд-скрипт до сборки самого проекта.
В противном случае нам придется писать скрипт сборки скрипта сборки скрипта сборки.
и т.д. "Курица, яйцо удовлетворения"( Я доволен переводом «Курицы».
<-> Задача «Яйцо», выполненная переводчиком.
google.com, ок.
перевод ).
Ну, это ограничение только некоторых языков.
Как насчет языка, который не требует компиляции, который можно сделать аналогично NAnt и MSBuild, передав исполняемому файлу ссылку на интерпретируемый? Вы понимаете, к чему я клоню.
Существует множество языков, работающих таким образом, некоторые из них работают на платформе .
Net. Если вы следите за моим блогом, то, наверное, заметили, что я фанат Ruby ( и я, ок.
перевод ).
Несмотря на то, что я не занимаюсь им профессионально, я постоянно восхищаюсь простотой и красотой этого языка.
И хотя в мире Ruby компиляция — довольно редко используемая процедура, потребность в процессе сборки проекта так же велика, как и в нашем мире статически компилируемых языков.
Кстати, народ, а вы знаете, что одно из распространенных заблуждений об ассемблере в мире .
Net заключается в том, что ассемблер нужен только для компиляции! Уфф! Вроде бы проще.
В языках типа C#, конечно, при сборке сначала делается компиляция, но после этого еще много работы.
Разработчику часто приходится готовить и запускать модульные тесты, копировать файлы, упаковывать дистрибутив и, возможно, отправлять его для развертывания.
Ассемблер — это скала, на которой строится сложный процесс, повторяющийся снова и снова.
Итак, у нас есть Руби.
Точнее, IronRuby 1.0 (на момент написания перевода актуальна версия 1.1).
И мы можем использовать его для создания коллектора, которым будет легко и приятно пользоваться! Так? Конечно.
Обзор установки IronRuby
Для начала скачайте дистрибутив с официального сайта http://ironruby.net/ .Там же можно скачать дистрибутивы как для .
Net 2.0, так и для .
Net 4.0. Процесс установки не должен зависеть от конкретного выбора.
Загрузите zip-файл.
*** От переводчика: На сайте уже доступен автоматический установщик, который выполнит необходимые операции по настройке системы; Вы также можете загрузить исходные коды интерпретатора и/или библиотеки для встраивания в свое приложение.
Поэтому описание ручной установки опускаю за ненадобностью.
После успешной установки интерпретатора вы можете запустить интерактивный интерпретатор через командную строку (команда «ir») и получить возможность поиграться с Ruby.
puts "CodeThinked.com is awesome!!"
Запустить рейк
Rake — это именно тот инструмент, о котором мы говорили выше.Он не использует XML. Это просто скрипт, полностью написанный на Ruby. Если вы пишете на интерпретируемых языках, то теоретически вам не нужно использовать XML для решения проблемы сборки.
Ты можешь просто напиши код .
IronRuby поставляется с собственной версией Rake, и чтобы убедиться, что все настроено правильно, нам просто нужно ввести «rake» в командной строке.
Через несколько секунд вы должны получить сообщение о том, что rake-файлы не найдены.
Теперь создадим проект и простой rake-файл для него.
Первое, что я сделаю, это создам каталог для проекта (пусть это будет c:\development\RakeTest).
В указанной директории я создам файл Rakefile.rb. Далее вам следует открыть его в вашем любимом текстовом редакторе ( например NotePad++, ок.
перевод ) и вставьте в него следующий код: require 'rake'
task :default => [:congratulate_me]
desc "Tells you that you are awesome"
task :congratulate_me do
puts "Congrats, you have rake running. Wasn't that easy?"
end
После этого вам останется только зайти в командную строку, перейти в каталог с этим файлом и набрать «rake».
В ответ вы должны получить «Поздравляем, у вас запущен рейк.
Разве это не было легкоЭ» И это действительно просто, не так ли? Теперь в вашем распоряжении полноценный коллектор.
В приведенном выше коде вы можете увидеть включение библиотеки Rake, настройку по умолчанию для запуска задачи «congratulate_me», а также определение самой задачи вместе с ее описанием.
Выглядит как простой нант-скрипт, но мы как ёжик написали код. Теперь посмотрим, во что нам обойдется добавить дополнительные задачи и объединить их в одну задачу или начать сборку не с задачи по умолчанию, а с какой-то другой.
Итак, добавим в скрипт пару задач: task :congratulate_team do
puts "Congrats to the team!"
end
task :congratulate_everyone => [:congratulate_me,:congratulate_team] do
puts "Phew, that was a lot of congrats"
end
Вы видите, как все стало немного сложнее.
У нас есть одна задача, которая просто записывает строку в консоль, и есть другая задача, у которой после имени стоит какой-то массив.
Это аналог функционала NAnt, позволяющий назначать зависимость одной задачи от других.
Это позволяет вам запускать другие перед выполнением этой задачи.
Теперь, если мы изменим имя задачи по умолчанию в Rakefile.rb на «congratulate_everyone», мы увидим, что при запуске сценария сборки задача «поздравлять_всех» выполняется после успешного завершения двух других.
И, кстати, нам не обязательно указывать задачу по умолчанию.
Мы можем назвать конкретную задачу по ее имени.
Делается это так: «грабли поздравить_команду».
Мы уже эмулировали многое из того, на что способны платформы NAnt или MSBuild. Это потому, что эти структуры просто позволяют нам объединять несколько задач для выполнения определенного действия.
Также у нас есть набор задач в скрипте и возможность выполнять их в определенной последовательности.
И никаких особых конфигов нам не нужно.
Мы можем просто объявить переменную в скрипте или читать данные откуда захотим.
Кроме того, мы можем подключить к скрипту и другие Ruby-файлы, тем самым получив доступ к настройкам, коду и задачам из разных мест. Кажется, мы смогли сделать многое из того, что позволяет нам XML, но бесплатно.
Осталась только одна проблема – сделать то, что они могут, верно? В конечном итоге мы хотим иметь возможность собирать студийные решения, запускать тесты, получать доступ к системе контроля версий, копировать и архивировать файлы, загружать файлы на FTP и т. д. Может быть, мы что-то упустили? Так сможем ли мы догнать MSBuild и NAnt? Хорошо, что вы спросили.
Дружим с Rake и .
Net Вы можете спросить себя: Так где же мне взять все эти задачи для сценария? Случайно, не придется ли мне убить их всех врукопашную? Может быть, эта проблема уже решена? И угадайте, что я вам отвечу! Конечно, эта проблема уже решена за вас.
Лекарство от головни называется " Альбакор «.
Это небольшой проект на GitHub. Не спешите устанавливать его прямо сейчас.
Я сейчас расскажу вам, как это сделать в кратчайшие сроки.
IronRuby поставляется со специальным инструментом под названием «igem» (похож на «gem» в MRI Ruby).
Этот инструмент позволяет вам устанавливать на ваш компьютер дополнительные пакеты IronRuby. Этот инструмент сам копирует пакет из репозитория на компьютер вместе с его зависимостями.
Итак, одной командой «igem install albacore» в консоли будет установлено все необходимое для работы Albacore. Все, что вам нужно сделать, это добавить всего одну строку в rake-файл: require 'albacore'
Сейчас я собираюсь создать простой проект консольного .
Net-приложения «RakeTestApp» и на его примере посмотреть, как работает сборка через Albacore. Начну с добавления в проекты конфига с именем, например, "AutomatedRelease", а затем в каждом из проектов в решении поменяю рабочий каталог сборки на ".
/build_output".
Таким образом, я могу запустить специальную задачу msbuild, предоставленную Albacore, для обработки файла .
sln и компиляции нашего решения.
Сначала я создам задачу, которая будет последовательно выполнять все остальные: task :full => [:clean,:build_release,:run_tests]
Затем я создам задачу, которая удалит рабочий каталог сборки «build_output», т.е.
выполнит очистку.
task :clean do
FileUtils.rm_rf 'build_output'
end
Как видите, для простого удаления файлов нам не нужны какие-то особые задачи.
Необходимый функционал уже реализован в стандартных библиотеках Ruby. Теперь я создам первую задачу, унаследованную от задачи Альбакора.
Эта задача скомпилирует решение: msbuild :build_release do |msb|
msb.properties :configuration => :AutomatedRelease
msb.targets :Build
msb.solution = "RakeTestApp/RakeTestApp.sln"
end
Итак, вместо «задачи» мы использовали «msbuild» и назвали задачу «build_release».
Эта задача принимает один параметр — конфигурацию.
Здесь мы устанавливаем конфигурацию «AutomatedRelease», указываем нужную цель и путь к дескриптору решения, который необходимо собрать.
Также у нас есть тесты, которые нужно запускать во время сборки.
Мы можем унаследовать задачу от задачи Albacore NUnit. Это будет выглядеть так: nunit :run_tests do |nunit|
nunit.path_to_command = "tools/nunit/nunit-console.exe"
nunit.assemblies "build_output/RakeTestAppTests.dll"
end
Опять же, эта задача принимает один аргумент, с помощью которого мы можем установить некоторые параметры задачи.
Здесь мы просто указываем исполняемый файл и список сборок с тестами (через запятую).
Теперь мы все вместе
require 'rake'
require 'albacore'
task :default => [:full]
task :full => [:clean,:build_release,:run_tests]
task :clean do
FileUtils.rm_rf 'build_output'
end
msbuild :build_release do |msb|
msb.properties :configuration => :AutomatedRelease
msb.targets :Build
msb.solution = "RakeTestApp/RakeTestApp.sln"
end
nunit :run_tests do |nunit|
nunit.path_to_command = "tools/nunit/nunit-console.exe"
nunit.assemblies "build_output/RakeTestAppTests.dll"
endВот и все! Мы создали простой инструмент сборки, используя IronRuby, Rake и Albacore. Но это лишь малая часть того, что может сделать Альбакор.
С помощью этой библиотеки я могу использовать команды ndependent, ncover, sftp, sql, архивировать каталоги с помощью zip, вызывать ssh, распаковывать и многое другое.
Все эти действия легко выполняются с помощью Albacore.
Заключение
Если вы, как и я, устали собирать конфиги через XML, то советую попробовать IronRuby, Rake и Albacore. В худшем случае это будет небольшой промежуток времени.А вот если сгорит, то вы навсегда освободитесь от татаро-монгольского ига гнета XML-конфигов.
Надеюсь, вам понравилось! Вот ссылка на сорта .
Теги: #msbuild #сборка проекта #ironruby #nant #make #разработка сайтов #ruby #.
NET
-
Настоящее, Которое Определит Наше Будущее
19 Oct, 24 -
Arduino-Терминал
19 Oct, 24 -
Очередной Кряк Касперского
19 Oct, 24 -
Шасси = Блок Двигателя + Коробка Передач
19 Oct, 24 -
Правда (Восточная Притча)
19 Oct, 24 -
Лаборатория Данных
19 Oct, 24
