Comments 12
Отличный туториал, я считаю.
Порадовали остроумные «фишечки»: запуск браузера из фикстуры функциональных тестов (идеально подходит для простых веб-приложений) и установка заглушки с автообновлением, которая рано или поздно приведёт в обновлённый веб-сервис.
Порадовали остроумные «фишечки»: запуск браузера из фикстуры функциональных тестов (идеально подходит для простых веб-приложений) и установка заглушки с автообновлением, которая рано или поздно приведёт в обновлённый веб-сервис.
Возникло несколько вопросов:
1. У Вас вот в конфигах скрипты из папки DeployScripts берутся, эта папка в самом проекте находится, в том же репозитории что и основной проект? (У нас для скриптов отдельный репозиторий, но и проектов много, для избегания дублирования выделили все скрипты и инфраструктурные штуки туда)
2. А в чем преимущество автоматического рестора пакетов перед отдельным шагом рестора? (на мой взгляд нагляднее это делать отдельным шагом, так как в build result появляется информационная вкладка о установленных в проекте пакетах)
3. Селениум. На каком браузере происходит тестирование? И тестируете ли различные браузеры? У нас регулярно тесты проходят под хромом, но sheduler trigger стоит и ночью другие браузеры тоже гоняют тесты, удобно.
4. Пользуетесь ли «Branch specification» для многоветочнисти? Или как Вы организовали тестирование фича веток?
1. У Вас вот в конфигах скрипты из папки DeployScripts берутся, эта папка в самом проекте находится, в том же репозитории что и основной проект? (У нас для скриптов отдельный репозиторий, но и проектов много, для избегания дублирования выделили все скрипты и инфраструктурные штуки туда)
2. А в чем преимущество автоматического рестора пакетов перед отдельным шагом рестора? (на мой взгляд нагляднее это делать отдельным шагом, так как в build result появляется информационная вкладка о установленных в проекте пакетах)
3. Селениум. На каком браузере происходит тестирование? И тестируете ли различные браузеры? У нас регулярно тесты проходят под хромом, но sheduler trigger стоит и ночью другие браузеры тоже гоняют тесты, удобно.
4. Пользуетесь ли «Branch specification» для многоветочнисти? Или как Вы организовали тестирование фича веток?
- Да, в том же. Не было резона выделять в отдельный репозиторий, у нашей команды это был первый проект, использующий TC, пока ничего принципиально общего, что стоило бы выносить там нет. Когда будут новые проекты, тогда будет смысл.
- Мне кажется, этот процесс не частый и достаточно «фоновой», что бы выделять его в отдельный шаг, статистика по пакетам — не очень критичная информация, хотя и любопытная. Благодарю за идею!
- Тесты проводим в Firefox, спасибо за идею по ночам отдельно запускать тесты на других браузерах.
- Нет, не пользуемся. Ветки с фичами мы на TC не запускаем, после того, как фича готова — она просто вливается в dev, и будет протестирована уже в комплексе со всеми последними изменениями.
По 4-ому пункту — у нас бывает что кто нибудь хочет отрефакторить жутко сильно, и, предположим, делает это на протяжении недели, не спеша, планомерно, а основная ветка сама по себе развивается. Проект довольно сложный и так сразу сложно понять, все ли нюансы учтены при рефакторинге, и хотят видеть сразу тесты как проходят. А так, спасибо за ответ)
А вообще, мне, почему то, не очень с msbuild понравилось работать, то ли я его не понял в полной мере. Управляющие скрипты пишу на Powershell, ну дико удобно.
А вообще, мне, почему то, не очень с msbuild понравилось работать, то ли я его не понял в полной мере. Управляющие скрипты пишу на Powershell, ну дико удобно.
Отвечу про свой вариант по пункту 4. У нас структура в TFS немножко проще, редко нужны отдельные ветки для фич — поэтому вполне достаточно сделать две конфигурации. Вообще, не вижу труда быстро клонировать конфигурацию и слегка подправить VCSRoot.
У нас платформа, на которой пишутся остальные модули. Есть конечные проекты и есть куча мелких модулей(не то чтобы куча, штук 30). Все это имеет кучу версий, где для разной версии платформы, где для функционала совсем нового. В общем, если для каждого проекта и версии вводить билды — будет полный ад. Простые модули поставляются в конечные — Nuget пакетами, как и сама платформа, да и друг от друга иногда имеют зависимости.
А вообще, клонировать конфигурации — плохо. Вот надо где то массово все поменять, перенастроить, обязательно что то где то будет упущено. Советую писать шаблоны, завязаться в билд степах на параметры и вуаля, надо билд — от шаблона сделал, уже подсвечено что и где надо вписать, чтоб все заработало. Ну и правки вносить — в шаблоне.
Жаль, но с TFS не работал и тем более на настраивал, сказать особо по нему нечего.
А вообще, клонировать конфигурации — плохо. Вот надо где то массово все поменять, перенастроить, обязательно что то где то будет упущено. Советую писать шаблоны, завязаться в билд степах на параметры и вуаля, надо билд — от шаблона сделал, уже подсвечено что и где надо вписать, чтоб все заработало. Ну и правки вносить — в шаблоне.
Жаль, но с TFS не работал и тем более на настраивал, сказать особо по нему нечего.
Туториал вполне хороший.
Выбор release/debug осуществляем через переменную env.Configuration = Release, а не через ключ для command-line.
Из возможностей ТС, которые используются — добавляем отдельный шаг «поиск дубликатов в коде» (Runner type = Duplicates finder (.Net), настройка runner'а тривиальна)
Выбор release/debug осуществляем через переменную env.Configuration = Release, а не через ключ для command-line.
Из возможностей ТС, которые используются — добавляем отдельный шаг «поиск дубликатов в коде» (Runner type = Duplicates finder (.Net), настройка runner'а тривиальна)
Ага, а еще StyleCop, FxCop, NDepend…
уточнение:
все property вида env.* и system.* доступны внутри msbuild скрипта
задали property system.Configuration
а внутри msbuild можете получить значение $(Configuration)
ну и ещё нюанс вдогонку. если property например такое system.A.B.C то переменная будет ${A_B_C}
все property вида env.* и system.* доступны внутри msbuild скрипта
задали property system.Configuration
а внутри msbuild можете получить значение $(Configuration)
ну и ещё нюанс вдогонку. если property например такое system.A.B.C то переменная будет ${A_B_C}
Покритикую немного конечно же :)
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 проекта. У меня есть подозрение что это вам больше подойдёт.
А вообще очень полезная статья для новичков, спасибо вам за труд.
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 проекта. У меня есть подозрение что это вам больше подойдёт.
А вообще очень полезная статья для новичков, спасибо вам за труд.
1) при настройке VCS Root очень удобно в поле default branch подставить какое-нибудь property %system.BranchName%
таким образом в разных конфигурациях можно использовать повторно один и тот же VCS Root
просто задавая через property имя нужного бранча
2) если у вас стоит Checkout mode = on server, то удобно использовать VCS Checkout Rules отфильтровывая всё лишнее.
Если репозитори большой, а собирается маленькая часть, то за счёт этого clean checkout будет банально быстрее.
3) кажется этот плагин confluence.jetbrains.com/display/TW/Deployer+plugin вам пригодится в фазе заливки на сервер
PS: список плагинов confluence.jetbrains.com/display/TW/TeamCity+Plugins
таким образом в разных конфигурациях можно использовать повторно один и тот же VCS Root
просто задавая через property имя нужного бранча
2) если у вас стоит Checkout mode = on server, то удобно использовать VCS Checkout Rules отфильтровывая всё лишнее.
Если репозитори большой, а собирается маленькая часть, то за счёт этого clean checkout будет банально быстрее.
3) кажется этот плагин confluence.jetbrains.com/display/TW/Deployer+plugin вам пригодится в фазе заливки на сервер
PS: список плагинов confluence.jetbrains.com/display/TW/TeamCity+Plugins
Sign up to leave a comment.
Настройка TeamCity для новичков