Добрый день, коллеги.
Длинные праздники заканчиваются, и уже завтра, мы снова погрузимся в пучину ежедневной рутины. Сегодня, на стыке еще не закончившихся праздников и еще не начавшейся рабочей недели, я бы хотел немного рассказать о непрерывной интеграции.
Начиная внедрять Agile практики в разработке, многие, прочитав: «Личности и их взаимодействия важнее, чем процессы и инструменты», приходят в восторг. Ведь можно собрать команду, сплотить их, поставить задачи и вот она: «звезда пленительного счастья» (работающее и полезное пользователям ПО). Но, к сожалению, в жизни бывает все намного скучнее и непредсказуемей. Начиная внедрять новомодный Scrum или Kanban, часто забывают, что все достоинства этих методик проявляться только в том случае, если они ложатся на правильные инженерные практики. К таким практикам относят модульное тестирование вообще, и TDD в частности; парное программирование; Code Review; непрерывную интеграцию и многое другое.
Под катом, я попробую показать, как настроить непрерывную интеграцию в рамках TFS 11 и в каких сценариях, какой способ построения проектов будет наиболее оправдан (много картинок и текста).
Итак, предваряя основное содержание, пара слов о том, что необходимо для повторения всего нижеописанного в статье:
1. Установленный TFS 11
2. Visual Studio 11 или 2010.
Скачать TFS 11 и VS 11 можно с сайта Microsoft.
Если у вас нет TFS 11, но есть TFS 2010, то с отличиями в пользовательском интерфейсе, но все описанное в статье вы сможете настроить и в нем.
Настройка Team Foundation Build Service
Если Build Service у вас уже настроен, то сразу переходите ко второй части статьи.
Запустив консоль администрирования TFS и выбрав Build Configuration, вы увидите вот такое приглашение:
Конфигурируем! Мастер достаточно прост, его первый экран сразу пропускаем Next:
На втором шаге, необходимо указать с какой коллекцией проектов и на каком сервере TFS будет работать настраиваемый Build Service. По умолчанию выбирается первая коллекция текущего сервера TFS:
На третьем шаге вам предстоит определиться, сколько агентов будут обслуживать построения в рамках данного сервера. Если вы выберете 1, то все запросы на сборку будут ставиться в очередь, по завершении компиляции одного проекта будет начинаться компиляция следующего запроса из очереди. Главный плюс этого подхода – снижение нагрузки на сервер, минус – если проекты компилируются долго, а очередь бывает велика, то вам придется ждать. При увеличении количества Build Agent-ов очередь будет обслуживаться быстрее, главное, чтобы при их огромном количестве сервер не тратил на переключения между агентами больше времени, чем на саму компиляцию:
На последнем экране, нас попросят указать, с какими учетными данными необходимо запускать Build Service. Если вы планируете только компилировать проекты без развертывания в тестовую и/или рабочую среду, то можно оставить и значение по умолчанию. В противном случае, выбор учетной записи для Build Service должен учитывать, какими правами должна обладать учетная запись для выполнения этих задач.
Собственно настройка на этом заканчивается. Впереди еще два экрана, с тем, что мы навыбирали и проверкой, можно ли сконфигурировать то, что выбрано. Нажав Configure на Readiness Check и дождавшись окончания настройки, увидим:
Если вы последовательно дошли до этого места, то Build Configuration в консоли администрирования TFS у вас будет выглядеть примерно так:
На этом работу с консолью администрирования Team Foundation Server можно заканчивать и переходить в Visual Studio.
Среда для демонстраций
Для наглядности, давайте возьмем простое WPF приложение, которое должно находиться в Source Control. Также добавим проект с модульными тестами, которые будут тестировать функциональность из первого проекта.
Структура папок в TFS для этой статьи у меня имеет вид:
Да, пока не забыл, в качестве папки, куда будут складываться построенные решения должна выступать сетевая папка. В которую, у той учетной записи, под которой запущен Build Service, должен быть доступ.
1. Ручной запрос на построение решения
Сразу оговорюсь, ручной запуск и непрерывная интеграция, это понятия из разных сказок. Непрерывная интеграция подразумевает автоматическое, регулярное построение проектов, без вмешательства человека. Но, т.к. ручные запросы на построение являются самыми простыми, а настройка для всех остальных случаев запуска будет очень напоминать ручные запросы, то давайте с него и начнем.
Сценарий:
У вас есть ветка (Branch), в которой вы ведете разработку. И есть ветка, в которой вы храните ту версию проекта, которая развернута в эксплуатационной среде. Время от времени, в рабочей версии находятся ошибки. Вы загружаете соответствующий проект, исправляете ошибку, проверяете ее на локальном компьютере разработчика, помещаете в Source Control. Тестировщикам и/или специалистам по развертыванию необходимо построить данное решение. Для этого они и будут выполнять ручной запрос.
Настройка:
На домашней странице Team Explorer выбираем Builds и в открывшейся вкладке New Build Definition:
На первом шаге мастера создания нового Build Definition нам необходимо указать имя, по которому мы в дальнейшем будет идентифицировать этот запрос на построение. Для данного примера я добавил к имени, предложенному по умолчанию, суффикс «_manual»:
Второй шаг позволяет настроить, когда Build Agent должен проявлять активность и запускать построение. Значение по умолчанию Manual нас вполне устраивает:
Третий шаг позволяет указать расположение папки решения в Source Control и расположение Build Agent-а на сервере. В большинстве случаев, эти значения можно оставлять по умолчанию.
Четвертый шаг, позволяет задать, при помощи какого контроллера мы будем осуществлять построение, а также папку, в которую необходимо помещать выходной проект (Staging location). Причем, первый вариант размещения (не копировать файлы в выходную папку) оправдан в том случае, если вы просто хотите собрать проект, прогнать на нем все Unit Test-ы, а сами получившиеся exe и dll вам не нужны. Третий вариант (поместить результат построения в Source Control) может быть удобен для разработчиков, с целью не потерять стабильный Build. Но в основном, конечно, применяется второй вариант, когда результаты построения будут копироваться в сетевую папку. Причем для каждого запуска Build Definition создается вложенная папка, а все построения, по умолчанию, сохраняются по схеме: <имя проекта>_<дата построения>.<номер построения за дату построения>.
На предпоследнем шаге, мы задаем общие настройки построения. Обратите внимание, что по умолчанию сразу выбран открытый sln и стоит запуск модульных тестов:
Но, само собой, режим построения можно изменить. Например, изменения конфигурации, в которой компилировать проект:
Сохраняем Build Definition посредством кнопки «Сохранить» из панели инструментов. В Team Explorer появился новый Build Definition:
Для того чтобы запустить его, достаточно открыть на нем контекстное меню и выбрать «Queue New Build…». В открывшемся окне нажимаем «Queue». И видим, что построение у нас идет, ну и по окончании, пиктограмма нам скажет о результате построения:
Двойной клик на построении позволит посмотреть подробную информацию, включая результат выполнения модульных тестов:
Все, с ручным запуском и основными запросами заканчиваю. Давайте быстренько по остальным сценариям пробежимся.
2. Построение решения по каждому помещению кода в Source Control
Сценарий:
Разработчики пишут код, модульные тесты. Помещая все это в хранилище кода. Мы хотим быть уверены, что это все собирается и проходят все тесты.
Настройки:
Настройка нового Build Definition будет отличаться только на первом шаге (необходимо дать другое имя) и на 2 шаге мастера. В качестве триггера указываем второй вариант:
Для старта построения, достаточно внести изменения в код проектов или модульных тестов и поместить изменения в Source Control. По окончании Check In, если мы перейдем во вкладку Builds в панели Team Explorer-а, то сразу увидим что наше построение запущено. Я, кстати, добавил в проект новый тест, который не прошел:
Мы также можем открыть подробности данного построения и проанализировать, что пошло не так.
При данном сценарии построения, есть существенный недостаток. Если разработчиков много, они работают по TDD (частые Check-in), а полное построение проекта и прогон тестов занимают 5-10 минут, то очередь построения при 1 Build Agent-е будет очень длинной и поместив изменения в Source Control вам придется долго ждать результата построения.
3. Построение по Check-In но не чаще чем…
Сценарий:
Сценарий тот же, что и в варианте 2, но сервер TFS с ним не справляется, а руководство денег на отдельный Build Server не дает.
Настройка:
Аналогично ручной, на втором шаге выбираем третий вариант построения:
Исправляем проект, чтобы проходил добавленный в предыдущем пункте тест, Check-In. И видим, что у нас запустилось сразу два построения. То, которое нужно запускать на каждый Check-In и то, которое нужно запускать по Ckeck-In-ам, но не чаще чем раз в час (обратите внимание на пиктограмму, указывающую, что построение стоит в очереди):
Правда при следующем Check-In, если он произойдет раньше чем через 60 минут, наше новое построение запускаться не будет.
Применяя эти два вида построений, мы можем, например, на каждый Check-In билдить проект без запуска тестов, а не реже чем раз в час билдить с запуском тестов.
4. Нельзя поместить код в Source Control, если он не компилируется
Сценарий:
У вас в команде новый разработчик, который забывает перед помещением кода в Source Control проверить, а он хоть компилируется?
Настройка:
Создаем новый Build Definition, задаем ему имя, и выбираем 4 вариант триггера на запуск построения:
Вносим изменения в код (само собой, чтобы он перестал компилироваться) и при попытке Check In вот такое уведомление:
А после запуска компиляции, в Team Explorer нам недвусмысленно напомнят, о том, что нужно дождаться окончания построения, а по окончании компиляции еще и выскочит уведомление:
Удобно, черт побери!
5. Ежедневные билды
Сценарий:
Как у вас еще нет ежедневных билдов? Тогда срочно читать 3 пункт теста Джоэла Спольски (http://russian.joelonsoftware.com/Articles/TheJoelTest.html).
Настройка:
Ну, вы уже наверно в курсе, создаем новый Build Definition, меняем имя и на втором шаге задаем в какие дни и, в какое время компилировать:
Все, каждую ночь, будет приходить злобный Build Agent и компилировать, компилировать, компилировать.
Вместо заключения
Вы все еще живете в мире без непрерывной интеграции? Если да, то зря!
Как видите, настройка занимает не так уж и много времени, а вот результат от того, что ваш проект регулярно компилируется, подвергается проверке модульными тестами и т.д., вы почувствуете практически сразу.
Ну и последнее, новая версия дизайна VS мне нравится. Уж очень все удобно и наглядно:
