Comments 4
Fake не плохой, просто он базируется от части на nant и прочих пережитках эпохи, отсюда и лимиты. TFS 2015 обещает совершенно иной подход к построению приложений, он будет больше ориентирован на облако и будет поддерживать задачи различной природы и типа. Не хочу вас огорчать но все что вы сделали потеряет актуальность, осталось только набраться терпения и подождать.
0
Зря не взяли psake.
Вы ограничились в требованиях прогоном юнит тестов, а на этом мир не заканчивается.
Continuous Integration на F# вы построите, а Continuous Delivery — не построите.
Как только появятся требования вида «скопировать на удалённый комп», «сконфигурировать IIS под web сайт», «развернуть в Azure», «перезапустить SQL Server», то F# станет бесполезен, а полезен станет powershell.
Для SQL Server, IIS, SharePoint есть стандартные powershell модули от microsoft, надо будет их использовать для автоматизации процесса развёртывания.
F# тут всегда будет в догоняющих.
На крупном проекте от powershell всё равно уйти не получится, не проще ли сразу взять psake?
Вы ограничились в требованиях прогоном юнит тестов, а на этом мир не заканчивается.
Continuous Integration на F# вы построите, а Continuous Delivery — не построите.
Как только появятся требования вида «скопировать на удалённый комп», «сконфигурировать IIS под web сайт», «развернуть в Azure», «перезапустить SQL Server», то F# станет бесполезен, а полезен станет powershell.
Для SQL Server, IIS, SharePoint есть стандартные powershell модули от microsoft, надо будет их использовать для автоматизации процесса развёртывания.
F# тут всегда будет в догоняющих.
На крупном проекте от powershell всё равно уйти не получится, не проще ли сразу взять psake?
0
Во-первых, вообще-то не ограничился «прогоном юнит тестов», у нас довольно много шагов выходящих за рамки юнит тестов. Я упоминаю об этом в описании «идеального» процесса.
Во-вторых, Вы справедливо разделили Continuous Integration и Continuous Delivery. И из того, что PowerShell хорошо подходит для delivery, не следует, что и все другие задачи тоже следует решать с его помощью. В наших задачах PowerShell сильно проигрывал F#.
Кстати, оба подхода вполне могут «жить дружно» — не вижу ничего плохого, в том, что delivery будет описываться отдельным ps-скриптом и выполняться в рамках своего build definition-а в TFS-е. И даже, если очень хочется, чтобы это был один скрипт, то можно поднять PowerShell host внутри AnFake-а и вызвать стандартные PowerShell модули от Microsoft.
Во-вторых, Вы справедливо разделили Continuous Integration и Continuous Delivery. И из того, что PowerShell хорошо подходит для delivery, не следует, что и все другие задачи тоже следует решать с его помощью. В наших задачах PowerShell сильно проигрывал F#.
Кстати, оба подхода вполне могут «жить дружно» — не вижу ничего плохого, в том, что delivery будет описываться отдельным ps-скриптом и выполняться в рамках своего build definition-а в TFS-е. И даже, если очень хочется, чтобы это был один скрипт, то можно поднять PowerShell host внутри AnFake-а и вызвать стандартные PowerShell модули от Microsoft.
0
Sign up to leave a comment.
Используем сборочные скрипты на F# / C# в TFS 2012