Постановочные фото: 8 фото с негром, «хозяйка на кухне», «я читаю закинув ногу на ногу» — фальшиво же, не надо такое.
Плюс фото комнаты в общаге на 5 человек не представлено — наверно далеко не так инновационно выглядит.
Никогда не слышал о гостинице уровня 3 звезды, где 5 койко-мест в комнате.
Данный паттерн хорошо отражает естественный порядок возрастания готовности релиза при сортировке пакетов по версии
По мне так понятие кросс-фичной сортировки вообще не определено.
То что одна фича называется feature1 а другая feature2 вообще не даёт никаких гарантий по сортировке.
Может быть feature2 вышла в октябре, а feature1 после нового года.
В идеале мне видится на фичу надо заводить отдельный nuget-feed, время жизни которого равно времени жизни фича-ветки.
То что вы написали работать будет, это бесспорно.
Но блин, неужели вам самому не кажется, что решить задачу «задеплоить сайт на IIS» можно лишь только написав на C# кастомный таск для MSBuild, который через WMI дёргает IIS?
Линуксоиды прочитают вашу статью и подумают «на дворе 2015 год, а в винде до сих пор по-человечески сайты даже деплоить нельзя, вот идиоты».
Начать нужно с того, что использовать MSBuild для автоматизации deploy — не нужно.
Right tool for the right job, понимаете.
Для всякой DevOps темы в виндах изобрели PowerShell.
Есть PowerShell, в нём есть модуль WebAdministration, там эта задача решается так просто, что даже недостойна статьи на хабре.
Извините если сильно грубо пишу, просто я считаю что хабр не должен учить людей костылям и велосипедам, а в вашем решении явно просматривается велосипед.
Вы ограничились в требованиях прогоном юнит тестов, а на этом мир не заканчивается.
Continuous Integration на F# вы построите, а Continuous Delivery — не построите.
Как только появятся требования вида «скопировать на удалённый комп», «сконфигурировать IIS под web сайт», «развернуть в Azure», «перезапустить SQL Server», то F# станет бесполезен, а полезен станет powershell.
Для SQL Server, IIS, SharePoint есть стандартные powershell модули от microsoft, надо будет их использовать для автоматизации процесса развёртывания.
F# тут всегда будет в догоняющих.
На крупном проекте от powershell всё равно уйти не получится, не проще ли сразу взять psake?
Думаю, для решения задач администрирования и управления инфраструктурой язык C# плохо подходит.
Убеждён, что язык powershell был изобретён в Microsoft именно для решения таких задач, как раз потому что C# плохо подходит.
Там есть много встроенных вещей которые облегчают жизнь — powershell remote management, desired state configuration, например.
Я сам разработчик на C#, но я убеждён что пихать C# везде не надо, есть задачи где powershell справляется лучше.
И ваша задача как раз из таких.
1. Enable Nuget Package Restore начиная с NuGet 2.7 уже не нужен. Здесь подробнее написано (поиск по «Automatic Package Restore»). Выставлять environment variable в TeamCity в этом случае не требуется.
Вообще лучше использовать отдельный шаг «NuGet Installer», как тут уже писали, он даёт няшный отчёт по используемым nuget-пакетам.
2. MSBuild Community Tasks не нужно ставить на билд-агента, давно уже есть nuget-пакет
Референсите его из deploy.xml и всё будет работать.
На будущее лучше посмотрите в сторону psake — там всё что нужно пишется руками на PowerShell очень быстро, не нужны никакие third-party task library.
Писать руками MSBuild скрипты это очень громозко, сплошной копипаст, высокий порог вхождения, поддерживать и развивать тяжело.
3. Выкладку на FTP можно писать не руками, а используя механизм publish profiles.
Попробуйте на любом web проекте правой кнопкой нажать и выбрать «Publish...» — это встроенный механизм деплоя web проектов, FTP там тоже есть.
На будущее откажитесь от FTP в сторону MSDeploy — там есть из коробки и offline page и много чего другого.
4. Выставлять Configuration=Local не требуется если использовать publish profiles. Configuration это нечто глобальное на уровне всего решения, а publish profile это локальная вещь для отдельного web проекта. У меня есть подозрение что это вам больше подойдёт.
А вообще очень полезная статья для новичков, спасибо вам за труд.
Статья очень, очень хорошая, но не могу не вставить свои пять копеек.
— Про версии сборок. Хочу обратить внимание, что у Microsoft термины Revision и Build поменяны местами. То есть семантически всё верно: закоммитил исходники — изменилась третья цифра, сбилдил на CI — изменилась четвёртая цифра. В документации с точки зрения смысла всё правильно, но названия параметров поменяны местами. Начинающему CI-мастеру легко запутаться.
— Про миграции базы данных. Если используется SQL Server (что для .NET частое явление), то можно использовать SMO. Через SMO можно управлять всем функционалом SQL Server, а не только alter на таблички делать. В статье упомянуть об SMO стоило.
— Про публикацию служб. Для доставки бинарников на сервер подходит тот же MSDeploy. Если в проекте уже используется MSDeploy для публикации web-приложений, то одной командой sync в MSDeploy можно скопировать все бинарники сервиса на целевой сервер. Шаред-папка и FTP это уже не модно :).
— Параметры в TeamCity. Учите людей плохому. Кучу аргуметов через /P указывать в TeamCity не надо — работать будет, но будут warnings. Специально для этого есть Build Parameters, они прозрачно транслируются в MSBuild скрипт.
Ну а в целом, если поговорить по душам, меня немного напрягает декларативный синтаксис MSBuild. Если стоит задача после билда сделать пару нетривиальных приседаний, то надо искать сторонные библиотеки с тасками для MSBuild, либо писать эти таски самому.
Я больше склоняюсь к использованию PowerShell и конкретно psake. Это императивные скрипты, а не декларативный XML как в MSBuild, их не надо компилировать, можно легко править и можно отдать поддержку этих скриптов админам (от них сейчас знание PowerShell стали требовать).
Александр, я не совсем понял вашу идею про встроенный nuget-сервер в TeamCity.
Зачем своим сервером заменять стандартный сервер nuget.org?
«Залить в svn всё необходимые пакеты» — у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Очевидно же — если, например, выйдет новая версия jQuery, то первым делом она появится на nuget.org, в официальном репозитории.
Пакет не обновится в вашем личном уютном репозитории, пока вы сами не зальёте новую версию в svn.
По сути вам nuget и не нужен — в svn вместо nuget пакетов заливайте сразу dll и референсите на них — фактически у вас именно это и сделано, только с тонкой nuget-прослойкой.
Nuget-пакеты в svn заливать однозначно не надо.
Надо личный nuget-репозиторий использовать строго в дополнение к официальному, не заменяя его.
Пресекать же бесконтрольное добавление зависимостей в solution надо другим способом — введением контроля.
Например, перед добавлением новой зависимости советоваться с teamlead или архитектором.
Стороняя либа может не проходить по лицензии — вон у вас на скриншоте EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте.
Принимать решения о включении в проект сторонних либ должен человек наделённый соответствующими правами и ответственностью, вот и всё.
Действительно, marker interface это не ваш случай.
Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?
А строковые имена хороши для usecase типа ResolveAll. Чтобы вернулся массив всех объектов, реализующих IPersistence. Здесь мне кажется лучше без них.
Я переводил в тестовых целях один мелкий проект — все работает.
https://oren.codes/2016/02/08/project-json-all-the-things/
Вырастет, покажу ему его первый комментарий на хабре.
Постановочные фото: 8 фото с негром, «хозяйка на кухне», «я читаю закинув ногу на ногу» — фальшиво же, не надо такое.
Плюс фото комнаты в общаге на 5 человек не представлено — наверно далеко не так инновационно выглядит.
Никогда не слышал о гостинице уровня 3 звезды, где 5 койко-мест в комнате.
А в целом круто, да.
1.2.0-a2feature2
По мне так понятие кросс-фичной сортировки вообще не определено.
То что одна фича называется feature1 а другая feature2 вообще не даёт никаких гарантий по сортировке.
Может быть feature2 вышла в октябре, а feature1 после нового года.
В идеале мне видится на фичу надо заводить отдельный nuget-feed, время жизни которого равно времени жизни фича-ветки.
"… проектирование и дизайн..."
Я скажу страшную вешь — слово «дизайн» в переводе это и означает «проектирование»!
Посмотрел на английском, там «design and deploy», то есть «проектирование и внедрение».
И что я должен думать о качестве перевода книги, если вижу на обложке такое?
Но блин, неужели вам самому не кажется, что решить задачу «задеплоить сайт на IIS» можно лишь только написав на C# кастомный таск для MSBuild, который через WMI дёргает IIS?
Линуксоиды прочитают вашу статью и подумают «на дворе 2015 год, а в винде до сих пор по-человечески сайты даже деплоить нельзя, вот идиоты».
Начать нужно с того, что использовать MSBuild для автоматизации deploy — не нужно.
Right tool for the right job, понимаете.
Для всякой DevOps темы в виндах изобрели PowerShell.
Есть PowerShell, в нём есть модуль WebAdministration, там эта задача решается так просто, что даже недостойна статьи на хабре.
Извините если сильно грубо пишу, просто я считаю что хабр не должен учить людей костылям и велосипедам, а в вашем решении явно просматривается велосипед.
Вы ограничились в требованиях прогоном юнит тестов, а на этом мир не заканчивается.
Continuous Integration на F# вы построите, а Continuous Delivery — не построите.
Как только появятся требования вида «скопировать на удалённый комп», «сконфигурировать IIS под web сайт», «развернуть в Azure», «перезапустить SQL Server», то F# станет бесполезен, а полезен станет powershell.
Для SQL Server, IIS, SharePoint есть стандартные powershell модули от microsoft, надо будет их использовать для автоматизации процесса развёртывания.
F# тут всегда будет в догоняющих.
На крупном проекте от powershell всё равно уйти не получится, не проще ли сразу взять psake?
Убеждён, что язык powershell был изобретён в Microsoft именно для решения таких задач, как раз потому что C# плохо подходит.
Там есть много встроенных вещей которые облегчают жизнь — powershell remote management, desired state configuration, например.
Я сам разработчик на C#, но я убеждён что пихать C# везде не надо, есть задачи где powershell справляется лучше.
И ваша задача как раз из таких.
Погуглите про powershell и модуль WebAdminisration, там всё на раз делается
technet.microsoft.com/en-us/library/ee790599.aspx
1. Enable Nuget Package Restore начиная с NuGet 2.7 уже не нужен. Здесь подробнее написано (поиск по «Automatic Package Restore»). Выставлять environment variable в TeamCity в этом случае не требуется.
Вообще лучше использовать отдельный шаг «NuGet Installer», как тут уже писали, он даёт няшный отчёт по используемым nuget-пакетам.
2. MSBuild Community Tasks не нужно ставить на билд-агента, давно уже есть nuget-пакет
Референсите его из deploy.xml и всё будет работать.
На будущее лучше посмотрите в сторону psake — там всё что нужно пишется руками на PowerShell очень быстро, не нужны никакие third-party task library.
Писать руками MSBuild скрипты это очень громозко, сплошной копипаст, высокий порог вхождения, поддерживать и развивать тяжело.
3. Выкладку на FTP можно писать не руками, а используя механизм publish profiles.
Попробуйте на любом web проекте правой кнопкой нажать и выбрать «Publish...» — это встроенный механизм деплоя web проектов, FTP там тоже есть.
На будущее откажитесь от FTP в сторону MSDeploy — там есть из коробки и offline page и много чего другого.
4. Выставлять Configuration=Local не требуется если использовать publish profiles. Configuration это нечто глобальное на уровне всего решения, а publish profile это локальная вещь для отдельного web проекта. У меня есть подозрение что это вам больше подойдёт.
А вообще очень полезная статья для новичков, спасибо вам за труд.
— Про версии сборок. Хочу обратить внимание, что у Microsoft термины Revision и Build поменяны местами. То есть семантически всё верно: закоммитил исходники — изменилась третья цифра, сбилдил на CI — изменилась четвёртая цифра. В документации с точки зрения смысла всё правильно, но названия параметров поменяны местами. Начинающему CI-мастеру легко запутаться.
— Про миграции базы данных. Если используется SQL Server (что для .NET частое явление), то можно использовать SMO. Через SMO можно управлять всем функционалом SQL Server, а не только alter на таблички делать. В статье упомянуть об SMO стоило.
— Про публикацию служб. Для доставки бинарников на сервер подходит тот же MSDeploy. Если в проекте уже используется MSDeploy для публикации web-приложений, то одной командой sync в MSDeploy можно скопировать все бинарники сервиса на целевой сервер. Шаред-папка и FTP это уже не модно :).
— Параметры в TeamCity. Учите людей плохому. Кучу аргуметов через /P указывать в TeamCity не надо — работать будет, но будут warnings. Специально для этого есть Build Parameters, они прозрачно транслируются в MSBuild скрипт.
Ну а в целом, если поговорить по душам, меня немного напрягает декларативный синтаксис MSBuild. Если стоит задача после билда сделать пару нетривиальных приседаний, то надо искать сторонные библиотеки с тасками для MSBuild, либо писать эти таски самому.
Я больше склоняюсь к использованию PowerShell и конкретно psake. Это императивные скрипты, а не декларативный XML как в MSBuild, их не надо компилировать, можно легко править и можно отдать поддержку этих скриптов админам (от них сейчас знание PowerShell стали требовать).
Что думаете по этому поводу?
Зачем своим сервером заменять стандартный сервер nuget.org?
«Залить в svn всё необходимые пакеты» — у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Очевидно же — если, например, выйдет новая версия jQuery, то первым делом она появится на nuget.org, в официальном репозитории.
Пакет не обновится в вашем личном уютном репозитории, пока вы сами не зальёте новую версию в svn.
По сути вам nuget и не нужен — в svn вместо nuget пакетов заливайте сразу dll и референсите на них — фактически у вас именно это и сделано, только с тонкой nuget-прослойкой.
Nuget-пакеты в svn заливать однозначно не надо.
Надо личный nuget-репозиторий использовать строго в дополнение к официальному, не заменяя его.
Пресекать же бесконтрольное добавление зависимостей в solution надо другим способом — введением контроля.
Например, перед добавлением новой зависимости советоваться с teamlead или архитектором.
Стороняя либа может не проходить по лицензии — вон у вас на скриншоте EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте.
Принимать решения о включении в проект сторонних либ должен человек наделённый соответствующими правами и ответственностью, вот и всё.
По наивным предположениям руководства, она не должна была выйти в широкие интернеты.
И это, не судите по версии 0.3 — ведь понятно, что там не шедевр программистской мысли.
Что с Новосибирском?
Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?
А строковые имена хороши для usecase типа ResolveAll. Чтобы вернулся массив всех объектов, реализующих IPersistence. Здесь мне кажется лучше без них.
Небольшая критика.
Я слышал, что разрешение зависимостей по строковому имени — это каг бы не правильно.
Правильно это marker interface.
Что вы об этом думаете?
Но работа в направлении клиента для mac и iphone активно ведётся.