Pull to refresh
6
0
Максим Пашук @pashuk

Пользователь

Send message
Связка .csproj+project.json работает уже прямо сейчас в 2015 студии.
Я переводил в тестовых целях один мелкий проект — все работает.

https://oren.codes/2016/02/08/project-json-all-the-things/
Я так понял что project.json останется, но будет использоваться только для зависимостей, как замена для файла packages.config.
Извините, ребенку 8 месяцев, добрался до клавиатуры.
Вырастет, покажу ему его первый комментарий на хабре.
Всё хорошо, но чувствуется фальшь.

Постановочные фото: 8 фото с негром, «хозяйка на кухне», «я читаю закинув ногу на ногу» — фальшиво же, не надо такое.

Плюс фото комнаты в общаге на 5 человек не представлено — наверно далеко не так инновационно выглядит.
Никогда не слышал о гостинице уровня 3 звезды, где 5 койко-мест в комнате.

А в целом круто, да.
Хмм, согласен.
1.2.0-a1feature1
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, там эта задача решается так просто, что даже недостойна статьи на хабре.

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

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

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 справляется лучше.
И ваша задача как раз из таких.
Я возможно поздно пишу, но блин, рецепт простой.
Погуглите про 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-сервер в TeamCity.
Зачем своим сервером заменять стандартный сервер nuget.org?

«Залить в svn всё необходимые пакеты» — у меня никогда бы рука не поднялась, это в корне убивает идею nuget.
Очевидно же — если, например, выйдет новая версия jQuery, то первым делом она появится на nuget.org, в официальном репозитории.

Пакет не обновится в вашем личном уютном репозитории, пока вы сами не зальёте новую версию в svn.
По сути вам nuget и не нужен — в svn вместо nuget пакетов заливайте сразу dll и референсите на них — фактически у вас именно это и сделано, только с тонкой nuget-прослойкой.
Nuget-пакеты в svn заливать однозначно не надо.

Надо личный nuget-репозиторий использовать строго в дополнение к официальному, не заменяя его.

Пресекать же бесконтрольное добавление зависимостей в solution надо другим способом — введением контроля.
Например, перед добавлением новой зависимости советоваться с teamlead или архитектором.
Стороняя либа может не проходить по лицензии — вон у вас на скриншоте EPPlus — а ведь она до третьей версии шла по GPLv2 и вы не могли её использовать в коммерческом проекте.
Принимать решения о включении в проект сторонних либ должен человек наделённый соответствующими правами и ответственностью, вот и всё.
Вообще, это была бета-версия только для сотрудников компании.

По наивным предположениям руководства, она не должна была выйти в широкие интернеты.

И это, не судите по версии 0.3 — ведь понятно, что там не шедевр программистской мысли.
Не могу не спросить.

Что с Новосибирском?
Действительно, marker interface это не ваш случай.

Если реализция может изменяться в runtime, то можно повторно вызывать RegisterType/RegisterInstance — это затрёт предыдушее значение в IoC контейнере. Так не пробовали?

А строковые имена хороши для usecase типа ResolveAll. Чтобы вернулся массив всех объектов, реализующих IPersistence. Здесь мне кажется лучше без них.
Спасибо за статью.

Небольшая критика.
Я слышал, что разрешение зависимостей по строковому имени — это каг бы не правильно.
Правильно это marker interface.

Что вы об этом думаете?
Конкретно на скрине — вайновский костыль (Winebottler если точнее).

Но работа в направлении клиента для mac и iphone активно ведётся.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Works in
Date of birth
Registered
Activity