Комментарии 14
А в чем смысл вызывать msbuild при помощи руби?
В самом мсбилд скрипте есть и вызов msbuild и вызов exec.
И работает он очень гибко ( если кто-то не удосужился изучить — это конечно же серьезный повод изобретать очередные велосипеды, но в общем ССЗБ).
А тут вам надо ставить интерпретатор руби на билдсервер, наверное патчить его неплохо было бы, настроить изначально ( не рубист — не могу представить что требуется для установки). Да и гем тоже нужен…
Только если ради синтаксиса, ну так XML в общем не так уж и плох, несмотря на «океан галочек».
А вот самое большое достоинство мсбилда так это то, что можно делать все, что умеет студия. Вышел новый вид проекта — если студия умеет его билдить — вы сможете сбилдить его и скриптом. Почти все, что умеет делать разработчик при помощи студии — можно сделать из мсбилд скрипта.
Этого, как мне кажется, более чем достаточно для любой задачи.
Просто надо разобраться немного, а не бросаться на «модный велосипед» у соседей.
В самом мсбилд скрипте есть и вызов msbuild и вызов exec.
И работает он очень гибко ( если кто-то не удосужился изучить — это конечно же серьезный повод изобретать очередные велосипеды, но в общем ССЗБ).
А тут вам надо ставить интерпретатор руби на билдсервер, наверное патчить его неплохо было бы, настроить изначально ( не рубист — не могу представить что требуется для установки). Да и гем тоже нужен…
Только если ради синтаксиса, ну так XML в общем не так уж и плох, несмотря на «океан галочек».
А вот самое большое достоинство мсбилда так это то, что можно делать все, что умеет студия. Вышел новый вид проекта — если студия умеет его билдить — вы сможете сбилдить его и скриптом. Почти все, что умеет делать разработчик при помощи студии — можно сделать из мсбилд скрипта.
Этого, как мне кажется, более чем достаточно для любой задачи.
Просто надо разобраться немного, а не бросаться на «модный велосипед» у соседей.
Спасибо за детальный ответ. На самом деле, мы выбрали Rake за возможность легко менять параметры сборки, собирать отдельные части проекта независимо от других. Над проектом работает несколько десятков человек, и не всем нужно его просто собирать целиком. В случае с build скриптами, нужно было бы иметь большой набор этих самых скриптов, учитывающих все возможные варианты. Используя Rake мы просто задаем необходимые параметры в консоли и получаем необходимый результат.
Примеры можно, чтобы дискуссия была предметной?
Не то что бы я намерен отговорить вас от Rake, но мне, с относительно неплохим пониманием механики MSBuild скриптов, искренне интересны сценарии, ради которых люди пишут и используют всякие внешние сторонние конструкции. Особенно уже в свете выхода MSbuild 4.0 с огромным количеством плюшек
Не то что бы я намерен отговорить вас от Rake, но мне, с относительно неплохим пониманием механики MSBuild скриптов, искренне интересны сценарии, ради которых люди пишут и используют всякие внешние сторонние конструкции. Особенно уже в свете выхода MSbuild 4.0 с огромным количеством плюшек
Я прекрасно понимаю вашу позицию. Мне тоже сначала показалось лишним вводить дополнительную прослойку над msbuild.
Но объясню ситуацию. У нас в проекте около 10 солюшенов, каждый из которых состоит в среднем из 20 проектов. Есть достаточно четкое распределение ролей, каждая команда работает с 2-3 солюшенами. Как правило, нет необходимости пересобирать весь проект целиком, если вносишь мелкие изменения. Следовательно, у всех разные требования к процессу сборки и запуску тестов. Охватить столь большой объем разнообразных задач с помощью build-скриптов очень сложно. В случае с Rake мы создали набор основных тасков, определили зависимости и теперь сборка проекта в абсолютно любой конфигурации запускается вводом нескольких слов в консоли. Для конечного разработчика получилось очень удобно.
Но объясню ситуацию. У нас в проекте около 10 солюшенов, каждый из которых состоит в среднем из 20 проектов. Есть достаточно четкое распределение ролей, каждая команда работает с 2-3 солюшенами. Как правило, нет необходимости пересобирать весь проект целиком, если вносишь мелкие изменения. Следовательно, у всех разные требования к процессу сборки и запуску тестов. Охватить столь большой объем разнообразных задач с помощью build-скриптов очень сложно. В случае с Rake мы создали набор основных тасков, определили зависимости и теперь сборка проекта в абсолютно любой конфигурации запускается вводом нескольких слов в консоли. Для конечного разработчика получилось очень удобно.
т.е. вы не используете CI системы, собирающие эти цепочки зависимостей за вас, а собираете все командами из консоли?
А можно пример более явный — я не вижу в чем проблема пересобрать проект целиком с обновленными библиотеками. Цепочки проектов\задач по сбору и тестированию можно точно также создавать из зависимостей target'ов
Я бы написал «Охватить… мы не пробовали» ;)
А можно пример более явный — я не вижу в чем проблема пересобрать проект целиком с обновленными библиотеками. Цепочки проектов\задач по сбору и тестированию можно точно также создавать из зависимостей target'ов
Охватить столь большой объем разнообразных задач с помощью build-скриптов очень сложно
Я бы написал «Охватить… мы не пробовали» ;)
Как нам это знакомо… Запилил мелоч и нужно весь солюшен пересобирать. Иногда ожидание выносит мозг. Особенно при большом солюшене и при загаженной файловой системе рабочей станции.
Была такая статья на CodeThinked
«Say Goodbye to NAnt and MSBuild for .NET Builds With IronRuby»
Там подробнее тема раскрыта. Лучше б ее перевел автор. Там и аргументы коекакие были.
«Say Goodbye to NAnt and MSBuild for .NET Builds With IronRuby»
Там подробнее тема раскрыта. Лучше б ее перевел автор. Там и аргументы коекакие были.
Вот она. Никуда не делась.
www.codethinked.com/say-goodbye-to-nant-and-msbuild-with-ironruby
www.codethinked.com/say-goodbye-to-nant-and-msbuild-with-ironruby
Прочитал статью. Кстати читал ее и раньше. Довольно поверхностная и очень активно использующая риторику, вместо серьезных аргументов. Вся цель — порекламировать очередной продукт, а не обосновать почему же Rake лучше MSbuild.
Основной аргумент всей статьи «ААА мне больно пользоваться XML, я не хочу его». И далее перефразируя, идет вот такое рассуждение:
Вот мне нравится синтаксис Ruby — давайте выпилим этот же велосипед и при помощи Ruby. А чтобы нас никто не обвинил в велосипедах и в том, что под руби надо еще раз выпиливать все те же таски что выпилены под msbuild — давайте сделаем чтобы наш велосипед умел крепиться к чужим велосипедам и своими колесами крутить их педали. И после этого мы будем ездить на своем велосипеде стоящем всегда на велосипедах MSBuild. И всем расскажем что у нас есть свой велосипед, который ни разу не msbuild.
Я могу сказать только одно ( это перефразированный ответ Sayed Ibrahim Hashimi sedodream.com/) — люди, которые считают что билд продукта надо делать через msbuild.exe ProductSolution.sln — просто не понимают что они делают. Даже если это в примерах — это карго культ.
Да, XML как скриптовый язык — не очень удобен. Да возможно базовые концепции MSBuild в виде Properties и Items — не самые интуитивные. Да, многие считают — зачем тратить время и разбираться с билд процессом ( они кстати не сильно ушли от «деплоя с машины разработчика») — можно сделать как написано в интернетах и все заработает.
Но не надо рассказывать, что «что-то» где-то является более гибким, чем X если использование этого что-то сводится к вызову X другим способом. И плюс набор выпиленных оберток X или других консольных утилит.
Еще раз повторю — Мсбилд скрипты (при неудобстве XML синтаксиса) обладают очень большими возможностями в плане сборки .NET, а понимание принципов их работы дает вам возможность изменять процесс билда так как вам надо, и в студии и при интеграции в CI системы. По сути — это возможность изменить любой участок в процессе сборки приложения. И все что выходит сейчас в виде новых проектов для студии — поставляется именно в виде тасков и таргетов для msbuild.
А через сколько времени выходит например новый gem, умеющий деплоить схему бд в Azure из проекта SQLProj?
Основной аргумент всей статьи «ААА мне больно пользоваться XML, я не хочу его». И далее перефразируя, идет вот такое рассуждение:
Вот мне нравится синтаксис Ruby — давайте выпилим этот же велосипед и при помощи Ruby. А чтобы нас никто не обвинил в велосипедах и в том, что под руби надо еще раз выпиливать все те же таски что выпилены под msbuild — давайте сделаем чтобы наш велосипед умел крепиться к чужим велосипедам и своими колесами крутить их педали. И после этого мы будем ездить на своем велосипеде стоящем всегда на велосипедах MSBuild. И всем расскажем что у нас есть свой велосипед, который ни разу не msbuild.
Я могу сказать только одно ( это перефразированный ответ Sayed Ibrahim Hashimi sedodream.com/) — люди, которые считают что билд продукта надо делать через msbuild.exe ProductSolution.sln — просто не понимают что они делают. Даже если это в примерах — это карго культ.
Да, XML как скриптовый язык — не очень удобен. Да возможно базовые концепции MSBuild в виде Properties и Items — не самые интуитивные. Да, многие считают — зачем тратить время и разбираться с билд процессом ( они кстати не сильно ушли от «деплоя с машины разработчика») — можно сделать как написано в интернетах и все заработает.
Но не надо рассказывать, что «что-то» где-то является более гибким, чем X если использование этого что-то сводится к вызову X другим способом. И плюс набор выпиленных оберток X или других консольных утилит.
Еще раз повторю — Мсбилд скрипты (при неудобстве XML синтаксиса) обладают очень большими возможностями в плане сборки .NET, а понимание принципов их работы дает вам возможность изменять процесс билда так как вам надо, и в студии и при интеграции в CI системы. По сути — это возможность изменить любой участок в процессе сборки приложения. И все что выходит сейчас в виде новых проектов для студии — поставляется именно в виде тасков и таргетов для msbuild.
А через сколько времени выходит например новый gem, умеющий деплоить схему бд в Azure из проекта SQLProj?
А ваш комментарий тоже своего рода риторика. В статье автор рассказывает почему ему удобно использовать Ruby. Но не про то, что
" «что-то» где-то является более гибким, чем X если использование этого что-то сводится к вызову X другим способом. И плюс набор выпиленных оберток X или других консольных утилит."
Так что не стоит подменять понятие: «Мне удобнее просто писать код»
на «А мой язык гибше, круче и т.п.» не надо. Автор писал именно про удобство. А вы как раз:
" «что-то» где-то является более гибким, чем X если использование этого что-то сводится к вызову X другим способом. И плюс набор выпиленных оберток X или других консольных утилит."
Так что не стоит подменять понятие: «Мне удобнее просто писать код»
на «А мой язык гибше, круче и т.п.» не надо. Автор писал именно про удобство. А вы как раз:
Еще раз повторю — Мсбилд скрипты (при неудобстве XML синтаксиса) обладают очень большими возможностями в плане сборки .NET, а понимание принципов их работы дает вам возможность изменять процесс билда так как вам надо, и в студии и при интеграции в CI системы...
ну автор Хабратопика сказал как раз, что ему не хватило гибкости MSBuild. При этом из примеров приведены только вызов самого же msbuild и вызов стандартного exe
Действительно, пока проект небольшой, ее возможностей вполне хватает. Но со временем количество кода растет, структура продукта становится все более сложной и запутанной, и начинаешь задумываться о поиске более гибкого решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rake + Albacore. Сборка .Net проекта с помощью Ruby