Teamcity что это за программа

Введение в TeamCity сервер

Добрый день. Подошел черед рассмотреть такое замечательно средство непрерывной интеграции как TeamCity. В этой статье мы рассмотрим следующий стек технологий: .NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, интеграционные, так и тесты UI).
Об “непрерывной интеграции” существует много материала, повторять эту тему в сотый раз вряд ли нужно.

Ну и для начала – что может TeamCity? А может он следующее: при появлении новых изменений в указанной ветке репозитория (или ином событии) выполнить сценарий, включающий в себя сборку приложения, запуск тестов, заливку файлов на удаленный сервер и т.д.

Важным моментом является то, что “сервер интеграции” и “машина, на которой будет проходить сам процесс”, – обычно (не обязательно) разные серверы. Более того, машин, на которых запускаются сборки и тесты, может быть несколько, и все на разных ОС – в общем, есть, над чем задуматься.

002. Рецепты TeamCity – Эдуард Мацуков

Для запуска процесса сборки используется программа-агент, принимающая команды от самого сервера. И запустить ее можно на любой из основных ОС (благодаря мультиплатформенности Java). На одну машину можно установить несколько агентов и запускать их параллельно, но важно понимать, что один агент единовременно может обрабатывать только один проект. При старте задачи TeamCity выбирает первый подходящий незанятый агент, причем можно устанавливать “фильтрацию”, например, выбирать агентов только по признаку определенной ОС (например, Windows) или только с установленной платформой .NET версии не ниже 4.5 и т.д.

Наш рабочий сценарий будет выглядеть следующим образом:

1. Забрать новые изменения из репозитория с применением триггера;
2. Собрать проект;
3. Если всё прошло успешно на предыдущем шаге – прогнать юнит-тесты для получения быстрого результата, чтобы дать быстрый фидбек девелоперам (смоук-тест);
4. Если всё прошло успешно на предыдущем шаге – прогнать регрессионные тесты тесты;
5. Если всё прошло успешно на предыдущем шаге – прогнать функциональные тесты.

Приступим к выполнению данного сценария, разбив все шаги на отдельные статьи. Кокретно в этом уроке мы создадим новый проект. В качестве тестового проекта возьмем проект, рассмотренный в курсе юнит-тестирования.

Создание нового проекта

Начинается всё с создания проекта.

После этогопереходим в настройки конфигурации сборки.

На втором шаге создания конфигурации необходимо установить используемую VCS, в нашем случае – git.

Добавление нового репозитория производится при нажатии на кнопку кнопкой “A ttach new VCS root”.

[4-1] Школа DevOps: Teamcity знакомство с архитектурой и понятиями / feat Тимур Батыршин

• VCS root ID – уникальный код, который можно не трогать. Генерируется автоматически;
• Fetch URL – адрес, с которого мы будем забирать содержимое репозитория;
• Default branch – ветка, с которой будет браться информация;
• Authentication method – способ аутентификации. Тут может быть и доступ без авторизации (если данные лежат, например, на внутреннем сервере), по ключу, и также по паролю.

Остальные опции можно оставить без изменения.

Источник: autoqa.org

Русские Блоги

Быстрый запуск инструмента непрерывной интеграции TeamCity

Все слышали о знаменитой Intellij IDEA, ее производственная компания Jetbrains не только запустила ряд полезных IDE, но и запустила популярный язык Kotlin. У Jetbrains также есть очень полезный продукт — инструмент непрерывной интеграции, который я представлю сегодня.TeamCity。

установка

Установить под Windows

Установить TeamCity очень просто, сначала зайдите вСтраница загрузкиЗагрузите TeamCity. Поскольку я использую здесь систему Windows, загрузите установочный пакет версии для Windows. После завершения загрузки установите его. Одним из преимуществ установки под Windows является то, что ее можно установить как службу, так что это будет более удобно, если вам понадобится управлять статусом TeamCity в будущем. Чтобы сказать, TeamCity разделен на две службы, одна называется агентом сборки, фактическое построение проекта выполняется через эту службу агента; другая служба — это веб-версия терминала управления TeamCity, поэтому мы можем легко выполнять через веб-страницу управление.

Конечно, вы можете видеть, что на странице загрузки есть несколько операционных систем, будь то Windows, macOS или Linux, вы можете запустить TeamCity.

Установить под Docker

Услуги виртуализации сейчас становятся все более популярными, потому что виртуализация действительно удобна. Если вам нужно включить TeamCity в Docker, это так же просто. Страница DockerHub, соответствующая TeamCity, находится вВот。

Первое, что нужно сделать, — это вытащить изображение TeamCity.

docker pull jetbrains/teamcity-server

Сняв зеркало, запустите его экземпляр. Ниже приводится пример, приведенный на официальной странице. Конечно, имена и расположение файлов здесь могут быть изменены по мере необходимости.

docker run -it —name teamcity-server-instance -v :/data/teamcity_server/datadir -v :/opt/teamcity/logs -p :8111 jetbrains/teamcity-server

Используйте TeamCity

инициализация

После завершения установки и запуска TeamCity мы можем получить к нему доступ на веб-странице. Если это система Windows, порт по умолчанию — 80, если это другая система, это порт, который вы установили сами.

Затем зайдите в браузер localhost:80 Вы можете увидеть страницу TeamCity. Вам необходимо настроить и инициализировать пользователя для первого использования, а затем подождать некоторое время.

После этого вы должны увидеть похожий интерфейс, значит, TeamCity установлен. Конечно, я создал два новых проекта, поэтому реальный интерфейс может быть другим.

Снимок экрана TeamCity

База данных конфигурации

Еще один момент, который следует отметить, — это настроить базу данных. По умолчанию TeamCity использует встроенную базу данных, и производительность не очень хорошая. Поэтому, чтобы использовать его в будущем более плавно, TeamCity рекомендует создать собственную базу данных.

Например, если я планирую использовать базу данных MySQL, мне нужно загрузить драйвер MySQL JDBC. mysql-connector-java-5.1.42-bin.jar , А затем поместите его в папку данных TeamCity libjdbc Затем настройте соответствующее имя пользователя и пароль базы данных в TeamCity для доступа к базе данных.

Конечно, это так и в Windows. Если вы используете Docker, вам может не потребоваться самостоятельно настраивать базу данных. Кроме того, после настройки базы данных это еще не все. Иногда TeamCity поможет вам обнаружить проблемы с производительностью базы данных. В этот раз просто следуйте его инструкциям, чтобы изменить конфигурацию базы данных.

Новый проект

Когда вы используете TeamCity в первый раз, вам будет предложено создать новый проект. Если вы хотите создать новый проект позже, щелкните в правом верхнем углу Administration ОК. При создании нового проекта вам необходимо указать URL-адрес кода проекта и инструменты поддержки, такие как Git и SVN. Вот мой простой небольшой проект в качестве примера. Его код находится вВот。

Новый проект

Затем TeamCity проверит введенный адрес и напомнит нам подтвердить.

Подтвердите адрес

Таким образом создается проект.

Настройте этап сборки

Инструменты непрерывной интеграции должны управлять всем жизненным циклом проекта, поэтому простого добавления проектов недостаточно. Следующим шагом является настройка конкретных этапов строительства проекта. В разных проектах могут быть разные процессы сборки, поэтому здесь основное внимание уделяется настройке. В частности, бесплатная версия TeamCity может поддерживать только 20 этапов сборки, поэтому, если вам нужна дополнительная настройка, вам нужно будет заплатить за коммерческую версию.

Кроме того, отсюда мы видим важность строительных инструментов. Если проект является Java-проектом и для управления проектом использует хорошо известный в отрасли инструмент сборки, такой как Maven или Gradle, то TeamCity необходимо только автоматически определять все этапы настройки. Если вы не используете такой инструмент, возможно, вам придется настроить процесс сборки самостоятельно. (Например, моя настольная программа WPF может быть установлена ​​только мной)

Поскольку пример, который я использовал, представляет собой настольную программу WPF, вот конфигурация процесса сборки программы .NET. Если вы используете функцию автоматического обнаружения, TeamCity автоматически добавит вам шаг Visual Studio (sln). Но этого одного шага недостаточно, поэтому нам нужно добавить другие шаги.

Автоматически определять шаги сборки

Сначала учтите, что в проекте могут использоваться различные сторонние библиотеки, а сторонние библиотеки на платформе .NET обычно получаются NuGet. Итак, нам нужно добавить шаг NuGet. Сначала нажмите на configure build steps manually И выберите NuGet Installer Введите, установите соответствующие параметры во всплывающем интерфейсе.

Шаги сборки NuGet

Затем вам нужно установить шаг сборки, просто выберите Visual Studio (sln).

Построить шаги

Таким образом настраиваются этапы построения проекта.

Настройка процесса сборки завершена 2

Построить проект

После настройки шагов сборки вы можете начать сборку проекта на следующем шаге. Щелкните вверху страницы Projects Чтобы вернуться к просмотру проекта. Затем нажмите на правую сторону предмета Run ОК.

Запустить проект

В это время пустое поле справа от агента сборки также станет синим, указывая на то, что проект находится в стадии сборки. Подождите, и проект будет построен. Задача сборки завершена.

Удачная сборка

Тестовые задания

Успешный проект должен иметь полный процесс тестирования. Опять же, если в проекте используются зрелые инструменты сборки, TeamCity автоматически обнаружит и использует эти функции. Но если TeamCity не определяется автоматически, вам нужно установить его вручную.

Сначала щелкните ссылку «Сборка» соответствующего проекта, затем щелкните «Параметры сборки» («Параметры») и найдите этапы сборки в нижней части страницы.

Настройки сборки

Мы добавили два шага ранее, и мы продолжим добавлять тестовый шаг ниже. Создайте новый шаг и выберите в качестве типа тесты Visual Studio. В тестах Visual Studio есть два типа: MSTest и VSTest. Разница в том, что VSTest требует, чтобы на сервере агента сборки TeamCity был установлен Visual Studio или Visual Studio Test Agent.

Затем имена тестовых файлов нужно заполнить здесь сборкой тестового проекта, просто укажите относительный путь. Местоположение и имя конкретной сборки необходимо определить в соответствии с проектом.Ситуация моего тестового проекта показана на рисунке. Наконец, если вам нужно проверить тестовое покрытие, вы также можете установить окончательный инструмент .NET Coverage.

Испытательная установка

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

Результаты теста

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

Запустить подробные результаты теста

Автоматическая сборка

Все предыдущие операции нажимаются вручную, чтобы выполнить сборку. Конечно, TeamCity также поддерживает автоматическую сборку.По умолчанию каждый проект будет добавлять триггер для запуска сборки при обновлении системы управления версиями, в которой находится проект. Конечно, это условие тоже можно изменить.

Как показано на рисунке ниже, настройки триггера находятся в настройках проекта. Если вам нужны другие настройки триггера, вы можете изменить их здесь.

Триггер сборки

Уведомление по электронной почте

Если сборка завершится неудачно, TeamCity может отправить электронное письмо на вашу учетную запись, чтобы напомнить вам о статусе, но для этого вам потребуется настроить SMTP-сервер в TeamCity. Если это компания, вы должны иметь возможность использовать для настройки корпоративный почтовый ящик компании. Лично я предлагаю не использовать внутреннюю электронную почту, потому что некоторые внутренние почтовые серверы часто рассылают спам, который может блокироваться другими электронными письмами, что делает невозможным получение электронной почты.

Источник: russianblogs.com

TeamCity

TeamCity предназначен для разработчиков и инженеров DevOps, которые стремятся поднять производительность своей команды на новый уровень и сократить расходы на дополнительные инструменты, которые им больше не нужны.

Детали продукта

TeamCity — это готовое полнофункциональное решение для непрерывной интеграции и последовательного развертывания. TeamCity позволяет быстрее создавать, тестировать и внедрять новые функции на любой платформе и с помощью любого языка программирования. Создавайте и автоматизируйте конвейеры DevOps любой сложности и любого масштаба, обеспечивая полную видимость ваших сборок и тестов.

Контакты

Czech Republic

Стоимость

Стоимость TeamCity начинается от 299$ в год. Есть бесплатная версия.

Характеристики

Стартовая стоимость

Бесплатная версия
Пробный период

Операционные системы

Cloud, SaaS, Web

Обучение

Документация
Персонально

Поддержка

Рабочее время

Возможности

Автоматизированное тестирование

Иерархическое представление
Обзоры Тестовых Сценариев
Параметризованное тестирование
Переместить и Копировать
Поддерживает параллельное выполнение

Применение Unicode
Тестирование безопасности
Тестирование на основе требований

Непрерывная интеграция

Журнал сборки
Непрерывная подача
Непрерывное развертывание
Управление изменениями
Управление конфигурацией
Управление обеспечением качества
Управление разрешениями
Управление тестированием
Устранение ошибок
Выберите самые важные функции

Бесплатная консультация по подбору ПО от наших специалистов
Бесплатная консультация
Заполните небольшой опрос и наши специалисты подберут для вас ПО
Подобрать ПО

Аналоги TeamCity

ElectroNeek RPA

от ElectroNeek Robotics

RPA-платформа для автоматизации процессов в организации любых размеров. «ElectroNeek» является простой в использовании R.

DeployBot

от SaaS.tech

Решение позволяет организовать сборку и развертывание приложений как постоянный процесс для всей вашей команды.

Buddy

Самый простой инструмент CI/CD из когда-либо созданных, рекомендованный ведущими разработчиками по всему миру.

Bitbucket

от Atlassian

Bitbucket — это не только управление репозиторием кода, но и общее пространство для совместной работы над проектом, его .

GitLab

Облачная DevOps платформа для оптимизации и улучшения бизнес-процессов через соответствие нормативным требованиям и тп.

Q.DevOp

от Diasoft

Q.DevOps – это объединенный в конвейер (pipeline) набор инструментов и технологий для процессов непрерывной интеграции, .

UiPath

UiPath — это платформа программной роботизации процессов, представляет собой интеллектуальную многозадачную систему для .

Rapise

от Inflectra

Мощная платформа автоматизации тестирования программного обеспечения без скриптов, которая поможет вам повысить качество.

aida

от Cathedral
Решение для организации автотестов.

Популярные сравнения с TeamCity

от JetBrains
Популярные сравнения с TeamCity

от JetBrains

от SaaS.tech

Решение позволяет организовать сборку и развертывание приложений как постоянный процесс для всей вашей команды.

UiPath — это платформа программной роботизации процессов, представляет собой интеллектуальную многозадачную систему для создания роботов, автоматизирующих бизнес-процессы.

от Cathedral
Решение для организации автотестов.

от Inflectra

Мощная платформа автоматизации тестирования программного обеспечения без скриптов, которая поможет вам повысить качество приложений и сократить время выхода на рынок.

от Tryon Solutions

Мощный инструмент для организации непрерывного тестирования и обеспечения эффективного развёртывания новых версий продукта.

от BlazeMeter

Программное обеспечение для тестирования производительности с открытым исходным кодом для тестирования API, веб- и мобильных приложений на любом этапе жизненного цикла разработки программного обеспечения.

от Solution-Soft

Предназначен для облегчения тестирования и моделирования заданных системных дат/времени без модификации или сброса часов.

от SmartBear

SoapUI создан для сквозного тестирования REST и SOAP API, веб-сервисов, микросервисов и многого другого.

от Indigo Software Technologies

Система тестирования INDIGO – это профессиональный инструмент автоматизации процесса тестирования и обработки результатов.

TeamCity с DeployBot

TeamCity с UiPath

TeamCity с aida

TeamCity с Rapise

TeamCity с Cycle

TeamCity с BlazeMeter

TeamCity с Time Machine

TeamCity с SoapUI

TeamCity с INDIGO

TeamCity с Axe

TeamCity с ElectroNeek RPA

TeamCity с Mailosaur

TeamCity с PreFlight

TeamCity с Online Test Pad

TeamCity с T-Plan

TeamCity с UserTest.io

TeamCity с Winautomation

Отзывы TeamCity

Отзывов ещё нет — ваш может стать первым.

Смежные категории к Автоматизированное тестирование

Сравнить 0 продуктов категории Автоматизированное тестирование
О компании

• Наша история
• Юридические документы

Пользователям
115419, г.Москва, ул.Шаболовка, д.34, стр.5

Все сведения, содержащиеся на страницах сайта (информационные материалы, каталоги, статьи и пр.), носят ознакомительный характер. Информация не является исчерпывающей. Информация на сайте не является публичной офертой, определяемой положениями Статьи 437 Гражданского кодекса РФ. Все права интеллектуальной собственности принадлежат компаниям — производителям программного обеспечения, как и товарные знаки и логотипы. Все ссылки на дистрибутивы, а так же выложенные статьи, товарные знаки и логотипы носят в себе только ознакомительный характер и не претендуют на интеллектуальную собственность, а так же ее нарушение

Источник: picktech.ru

Настройка TeamCity для новичков

2013-12-10 в 2:58, admin , рубрики: .net, ASP.NET, Git, msbuild, nunit, teamcity, Блог компании СКБ Контур, непрерывная интеграция, метки: ASP.NET, c++, Git, msbuild, nunit, teamcity, непрерывная интеграция

Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.

Что такое «непрерывная интеграция», отлично рассказано здесь и вот здесь, повторять эту тему в сотый раз вряд ли нужно.

Ну и для начала – что может TeamCity (далее – просто TC)? А может он следующее: при появлении изменений в указанной ветке репозитория (или ином событии) выполнить сценарий, включающий в себя, например, сборку приложения, прогон тестов, выполнение других сценариев, заливку файлов на удаленный сервер и т.п.

Важным моментом является то, что «сервер интеграции» и «машина, на которой будет проходить этот процесс», – обычно (не обязательно) разные серверы. Более того, машинок, на которых запускаются сборки и тесты, может быть несколько, даже много, и все на разных ОС – в общем, есть, где развернуться.

Для запуска процесса сборки используется программа-агент, принимающая команды от TC-сервера, запустить ее можно на любой из основных ОС (слава мультиплатформенности Java). На один компьютер можно установить несколько агентов и запускать их параллельно, но важно помнить, что один агент единовременно может обрабатывать только один проект. При старте задачи TC выбирает первый подходящий незанятый агент, причем можно устанавливать «фильтры», например, выбирать агента только с ОС Windows или только с установленным .NET версии не ниже 4.0 и т.п.

Теперь нужно придумать сценарий работы. Мы используем в работе следующие ветки:

1. release – содержит актуальный код, рабочую версию, которая находится на боевом сервере;
2. dev – в неё идут все новые фичи, позже вливается в release;
3. отдельная ветка на каждую фичу, которая отпочковывается от dev и в неё же возвращается.

В общем, практически стандартный git-flow, о котором более подробно можно прочитать, например, здесь.

В связи с этим наш сценарий будет выглядеть так:

1. забрать свежие изменения из репозитория ветки dev;
2. скомпилировать проект;
3. если всё прошло успешно на предыдущем шаге – прогнать юнит-тесты;
4. если всё прошло успешно на предыдущем шаге – прогнать функциональные тесты;
5. если всё прошло успешно на предыдущем шаге – залить изменения на тестовый сервер.

Для релизной ветки делаем всё то же самое, но на время заливки новых данных приостанавливаем сервер и показываем заглушку.

А теперь вперёд – реализовывать сценарий!

Забрать свежие изменения из репозитория

Начинается всё с немудрёного создания проекта.

После – создание «build configuration» (конфигурации сборки). Конфигурация определяет сценарий сборки.

На втором же шаге создания конфигурации нас спросят об использованной VCS, так что отвечаем честно, что у нас тут git. У вас может быть другая VCS – не теряйтесь. Добавление нового репозитория производится кнопкой Create and attach new VCS root.

Итак, ключевые настройки:

• VCS root ID можно не трогать – уникальный код, как ни крути. Если оставить пустым, генерируется автоматически;
• Fetch URL – тот адрес, с которого мы будем забирать содержимое репозитория;
• Default branch – ветка, с которой будет браться информация;
• Authentication method – самое интересное – способ аутентификации. Тут может быть и доступ без авторизации (если данные лежат на внутреннем сервере, например), и по ключу, и по паролю. Для каждого варианта дополнительные поля будут свои, сами понимаете.

Остальное многообразие опций – на ваш вкус и цвет.

Далее, нужно настроить автоматический запуск задания. Идём в «Build Triggers» (условия сборки) и выбираем условие VCS Trigger – при настройках по умолчанию он будет раз в минуту проверять наличие новых коммитов в репозитории, а если таковые найдутся – запустит задание на выполнение.

Скомпилировать проект

Поскольку у нас проект на ASP.NET в виде Solution’а из Visual Studio – тут тоже было всё просто.

Идём в меню «Build Steps» (Шаги сборки), выбираем runner type (а их тут действительно много) и останавливаемся на MSBuild. Почему именно на нём? Он даёт достаточно простой способ описать процесс сборки, даже достаточно сложный, добавляя или удаляя различные шаги в простом XML-файле.

Далее всё элементарно.

Build file path – путь к sln-файлу.
MSBuild version, MSBuild ToolsVersion и Run platform выбираем под требования своего проекта.

Если в проекте несколько конфигураций, то можно использовать опцию Command line parameters для ввода примерно такого ключа:

/p:Configuration=Production

где Production заменить на нужный конфиг.

Включить скачивание NuGet-пакетов

Важный пункт, в случае если вы используете NuGet-пакеты; если нет – можно переходить сразу к следующему пункту.

Поскольку NuGet-пакеты весят немало, да и хранить в репозитории бинарники библиотек без особой необходимости не хочется, можно использовать замечательную опцию NuGet Package Restore:

В этой ситуации бинарники библиотек в репозиторий не включаются, а докачиваются по мере необходимости в процессе сборки.

Но MSBuild – настоящий джентльмен и не будет без разрешения делать лишних телодвижений, поэтому и докачивать пакеты просто так не будет – ему сей процесс нужно разрешить. Для этого придется либо на клиенте установить переменную окружения Enable NuGet Package Restore в значение true, либо пойти в меню Build Parameters и выставить его там.

Прогнать юнит-тесты

У нас юнит-тесты являются отдельным проектом внутри решения. Так что на предыдущем шаге они уже скомпилированы – осталось их запустить.

Добавляем новый шаг, только теперь Runner – это NUnit. Обратите внимание на параметр Execute step: он указывает, при каких условиях нужно выполнять шаг, и имеет 4 значения:

• If all previous steps finished successfully (zero exit code) – если все предыдущие шаги завершились без ошибок. При этом проверка выполняется чисто на агенте;
• Only if build status is successful – аналогично предыдущему, но при этом агент ещё и уточняет у сервера TC статус билда. Нужно для более тонкого управления логикой задания, например, если нулевой код возврата конкретного шага для нас является ошибкой;
• Even if some of the previous steps failed – даже если какой-то из предыдущих шагов завершился с ошибкой;
• Always, even if build stop command was issued – выполнять шаг, даже если подана команда на отмену выполнения сборки.

Здесь самое важное – указать верный путь к сборке с тестами внутри проекта в графе Run tests from. У нас, например, он выглядит вот так:

%teamcity.build.checkoutDir%projectproject.FuncTestsbinDevproject.FuncTests.dll

%teamcity.build.checkoutDir% – это переменная, указывающая на папку, в которую скачиваются данные из репозитория. В принципе, она не обязательна для указывания, т.к. по умолчанию путь идёт именно относительно этой директории, поэтому путь можно было бы сократить до:

projectproject.FuncTestsbinDevproject.FuncTests.dll

Отдельно отмечу опцию Run recently failed test first – если в предыдущем прогоне какие-то тесты упали, то в следующем запуске первыми запустятся именно они, и вы быстро узнаете об успешности последних изменений.

Прогнать тесты интерфейса (функциональные тесты)

Здесь все гораздо интереснее, чем с юнит-тестами. Кэп тут подсказывает, что, чтобы протестировать проект в браузере, его, т.е. проект, необходимо запустить. Но тут мы схитрили, запуская веб-сервер прямо из кода тестов Selenium:

[SetUpFixture] class ServerInit < private const string ApplicationName = «justtest»; private Process _iisProcess; private string GetApplicationPath(string applicationName) < var tmpDirName=AppDomain.CurrentDomain.BaseDirectory.TrimEnd(»); var solutionFolder = Path.GetDirectoryName(Path.GetDirectoryName(Path.GetDirectoryName(tmpDirName))); string result = Path.Combine(solutionFolder, applicationName); return result; >[SetUp] public void RunBeforeAnyTests() < […] var applicationPath = GetApplicationPath(ApplicationName); var programFiles = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles); _iisProcess = new Process < StartInfo = < FileName = string.Format(«/IIS Express/iisexpress.exe», programFiles), Arguments = string.Format(«/path:»» /port:», applicationPath, UrlProvider.Port) > >; _iisProcess.Start(); > [TearDown] public void RunAfterAnyTests() < […] if (_iisProcess.HasExited == false) < _iisProcess.Kill(); >> >]

А сам запуск выглядит абсолютно точно так же, как на шаге с юнит-тестами.

Залить изменения на тестовый сервер

Сервер, на котором находится агент TC, и сервер, на котором установлен IIS, – разные серверы, причем, более того, находятся они в разных сетях. Поэтому файлы нужно как-то на конечный сервер доставить. И вот тут решение выбрано, может, не очень элегантное, зато крайне простое. Используем заливку через FTP, причем делает сие за нас MSBuild.

1. настраиваем на сервере FTP аккаунт для заливки файлов. Для дополнительной безопасности можно запретить заливку для всех IP, кроме внутреннего, если TC-сервер лежит во внутренней сети, конечно;
2. устанавливаем на агента MSBuild Community Tasks, чтобы получить возможность использовать задачу «Залить по FTP». Качать тут;
3. подготовить файл-сценарий для MSBuild, который будет производить следующие действия:

1. сборка приложения во временной папке;
2. подмена конфигурационного файла;
3. заливка файлов по FTP.

Вот так будет выглядеть этот файл (deploy.xml)

bin ../output Dev ..projectprojectWeb.template.config ..projectprojectWeb.$(Configuration).config ..projectoutputWeb.config False WebProjectOutputDir=$(PublishDir);OutputPath=$(OutputDir);Configuration=Dev dev.example.com ЛОГИН ПАРОЛЬ ..projectoutput

А так – задание по его вызову:

Недостаток решения – заливаются ВСЕ файлы, а не только новые изменившиеся. На проекте с кучей файлов верстки или множеством модулей это может стать проблемой из-за затрачиваемого на заливку времени.

Ещё один замеченный недостаток – при встрече файла с нелатиницей в названии падает с ошибкой. Латиница и буквы/цифры обрабатываются нормально. Ноги этой проблемы, похоже, растут из специфики протокола FTP: тот основан на ASCII, но, как именно кодировать не ASCII-символы, он не описывает, предлагая «делать так, как будет понимать ваш сервер». Соответственно, чтобы вылечить проблему, не меняя схему, нужно пропатчить MSBuild Community Tasks, благо, исходники открыты. Ну, или воспользоваться альтернативным способом заливки файлов, например через WinSCP.

Остановка и запуск сервера для релизного сценария

Мы её решаем чуть диким, но симпатичным способом. У IIS’а есть особенность: если в корень сайта положить файл с именем app_offline.html, то сайт отрубается, при обращении ко всем файлам будет выдаваться содержимое этого файла.

Минус – обращение именно что КО ВСЕМ файлам, включая статичные. Так что, если хочется сделать заглушку с оформлением, CSS и картинками, используйте инлайн-стили и data:url, ну, или как вариант – выложите их на отдельном сервере.

Включаем-отключаем мы сервер через WinSCP-сценарий и такие вот файлики:

server_off.cmd

winscp.exe /console /script=server_off.txt

Источник: www.pvsm.ru