Непрерывное построение и развертывание

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

Непрерывная интеграция (continuous integration, CI) — это методика, предполагающая как можно более частую интеграцию кода в общее хранилище. В процессе интеграции кода прерывание построения или ошибка тестирования своевременно указывают на ошибку в коде.

Мартин Фаулер (Martin Fowler) замечательно сформулировал принципы непрерывной интеграции.

• Нужно вести один репозиторий исходного кода.

• Нужно автоматизировать построение.

• Нужно сделать построение самоподдерживающимся.

• Нужно возвращать код не реже одного раза в день.

• Построение каждого возврата должно выполняться на сервере непрерывной интеграции.

• Построение нужно выполнять быстро.

• Тестирование нужно проводить в клоне рабочей среды.

• Каждый участник команды должен иметь беспрепятственный доступ к последнему исполняемому файлу.

• Всегда нужно быть в курсе происходящего.

• Нужно автоматизировать развертывание.

Дополнительные сведения см. на странице Continuous Integration веб-сайта Мартина Фаулера.

Visual Studio Application Lifecycle Management (ALM) помогает управлять комплексным процессом разработки программного обеспечения и поддерживает непрерывную интеграцию. Используя возможности Visual Studio ALM, можно избежать непредвиденных задержек, превышения запланированных затрат и рисков, связанных с выполнением.

В этом разделе

• Управление зависимостями

• Непрерывная интеграция в Visual Studio 2010

• Подготовка и начало работы

• Управление версиями

• Построение

• Тестирование и развертывание

• Интеграция проекта и обмен информацией

Управление зависимостями

Интеграция кода представляет собой сложный процесс из-за существующих между частями кода зависимостями. Например, библиотека, рисующая круг на экране, взаимосвязана с методом Sqrt() системных математических библиотек. Если меняется метод Sqrt(), необходимо соответственно обновлять библиотеку. Оборудование и операционные системы меняются гораздо реже, чем командные проекты. Однако абсолютное игнорирование этих изменений может иметь пагубные последствия. Можно интегрировать код уже на начальных этапах проекта, чтобы проверить правильность работы кода и верность допущений, на которых он основан.

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

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

В первом шаге изменяется блок кода h, что может потенциально повлиять на все зависимые блоки кода — a, b, d, e и f. Во втором шаге изменяются блоки кода a и b. Если команда не выполняет интеграцию кода после первого шага, блоки a и b могут перестать функционировать как нужно. В третьем шаге изменяется блок кода f. Допустим, команда не выполнила интеграцию кода после второго шага — тогда к этому моменту блок кода b был один раз изменен и дважды оказался затронутым изменениями других блоков. В результате исправление ошибок в блоке кода b может вызвать много сложностей.

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

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

Во-первых, Team Foundation (подсистема контроля версий) можно использовать для управления ветвями, наборами изменений и их интеграцией. Каждый участник команды может использовать рабочие области для самостоятельной работы. Дополнительные сведения см. в разделах Ветвление и объединение и Создание рабочей области для работы с командным проектом.

Во-вторых, Team Foundation Build можно использовать для компиляции, тестирования и развертывания программного обеспечения в автоматизированной распределенной системе. Как видно из рисунка выше, в Team Foundation Build имеется два вида построений. Один вид использует для построения ветви разработки построение непрерывного типа. Другой вид использует для построения основной ветви тип построения с возвратом. В Visual Studio Team Foundation Server поддерживается пять типов построений: ручные, непрерывные (активируемые при каждом возврате кода), последовательные (с накоплением возвратов до завершения предыдущего построения), с условным возвратом и по расписанию. Дополнительные сведения см. в разделах Создание базового определения построения, Основные сведения о системе построения Team Foundation Build и Возврат ожидающих изменений под управлением построения с условным возвратом.

В-третьих, предусмотренные в Visual Studio ALM возможности управления лабораториями позволяют определять и развертывать построения в физических и виртуальных лабораторных средах. Для перехвата ошибок интеграции во время выполнения в заданной среде можно развернуть построение в лабораторной среде, а затем запустить наборы тестов в этом построении. Дополнительные сведения см. в разделе Использование виртуальной лабораторной среды в жизненном цикле приложения.

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

Примечание

Выполнение тестов позволяет получить показатели покрытия кода, помогающие понять, какая часть код охвачена тестовыми случаями.Однако покрытие кода не следует использовать для измерения полноты или качества тестов.Дополнительные сведения см. в разделе Практическое руководство. Настройка покрытия кода с помощью параметров тестирования для автоматических тестов.

В-четвертых, Visual Studio Team Foundation Server — это хранилище рабочих элементов. Можно создавать и отслеживать рабочие элементы, такие как ошибки или задачи, назначенные участникам команды, а также управлять этими рабочими элементами. Если в процессе интеграции кода построение прерывается, команда должна как можно скорее устранить проблему. Можно настроить Team Foundation Server для создания рабочих элементов для прерываний построений. Дополнительные сведения см. в разделе Отслеживание ошибок, задач и прочих рабочих элементов.

И, наконец, базы данных в хранилище Team Foundation Server и служб анализа SQL Server выполняют сведение и связывание всех данных, предоставленных подсистемами в Team Foundation Server. Эти подсистемы включают управление версиями, построение, тестирование, развертывание и отслеживание рабочих элементов. Следовательно, команда может визуализировать комплексный процесс непрерывной интеграции. Дополнительные сведения см. в разделе Создание отчетов с использованием реляционной базы данных хранилища для Visual Studio ALM.

Подготовка и начало работы

Чтобы начать использовать непрерывную интеграцию и другие функции Team Foundation Server, команде разработчиков необходимо выполнить следующую последовательность шагов.

1. С помощью Team Foundation (подсистема контроля версий) интегрируйте код в единую базу кода.

2. В Team Foundation Build создайте построение ручного типа.

3. Запустите автоматические тестовые случаи, чтобы проверить качество построения. Если подходящий набор тестов отсутствует, создайте заполнитель набора тестов и импортируйте несколько автоматических тестовых случаев. Этот набор будет служить прототипом для будущих тестов.

4. Убедитесь, что результирующие двоичные файлы из построения помещаются в общее расположение. Это поможет диагностировать проблемы, появляющиеся в ходе тестирования.

5. Для перехвата ошибок интеграции во время выполнения в заданной среде используйте Microsoft Test Manager.

Управление версиями

Система управления версиями предоставляет общее хранилище для кода. Небольшая команда может работать с одной ветвью. Однако более целесообразно работать с двумя или более ветвями, поскольку обычно приходится создавать несколько версий кода и выпускать проект на разных этапах. Дополнительные сведения о создании и слиянии ветвей кода см. на странице Team Foundation Server Branching Guide 2.0 веб-сайта CodePlex.

Построение

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

В Team Foundation Build предусмотрены следующие типы построений:

• ручные — построения ставятся в очередь участниками команды;

• непрерывные — построения ставятся в очередь по возврату кода в ветвь подсистемы управления версиями;

• последовательные — возвраты кода накапливаются до завершения предыдущего построения;

• с условным возвратом — возвраты принимаются только при условии успешного слияния и построения переданных изменений;

• по расписанию — построения выполняются по заданному расписанию.

Дополнительные сведения см. в разделе Создание базового определения построения.

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

Участники команды должны организовывать исходный код так, чтобы построение занимало не более 10 минут. В больших проектах это не всегда возможно. С помощью Team Foundation Server команда может настроить различные определения построений, каждое из которых будет служить для построения отдельного подмножества базы кода. Если построения занимают длительное время, используйте последовательные построения для непрерывного формирования двоичных файлов из неизменяемого кода.

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

Количество построений в день

При непрерывной интеграции кода можно выполнять непрерывное построение для каждого возврата в каждой ветви. Можно также запустить последовательное построение, которое не зависит от вновь возвращенного кода. Дополнительные сведения см. в разделах Создание базового определения построения и Наблюдение за ходом построения.

Ускорение построений кода с помощью Team Foundation Server

Повысить скорость построений поможет настройка определения построения для выполнения инкрементных построений. С помощью журналов построений можно идентифицировать "медленные" части построения и возможные области для улучшения. Дополнительные сведения см. в разделе Настройка Team Foundation Build для добавочного построения.

Масштабирование непрерывной интеграции с помощью Team Foundation Build

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

Дополнительные сведения см. в разделе Основные сведения о системе построения Team Foundation Build.

Тестирование и развертывание

Место тестирования и развертывания в непрерывной интеграции

На следующем рисунке показано, как функции тестирования и развертывания в Visual Studio ALM используются в непрерывной интеграции.

Во-первых, при непрерывной интеграции кода можно обнаружить проблемы с кодом в самом построении. Компиляция построения может завершиться либо успешно, либо с ошибкой в зависимости от используемого компилятора. Можно создать отчет о построении, содержащий ошибки и предупреждения компилятора. В отчете о построении Visual Studio ALM также указываются исправленные в построении ошибки, включенные в построение наборы изменений, а также выполнялся ли в ходе построения анализ кода. С помощью Visual Studio ALM можно проверить, соответствует ли структура кода определенным командой правилам. Дополнительные сведения см. в разделе Практическое руководство. Проверка кода .NET по схеме слоев.

Во-вторых, проблемы с кодом можно выявить при выполнении модульных тестов. В ходе таких тестов проблемы выявляются иначе, чем при использовании компиляторов. По правилам, определенным компилятором, проверяются такие аспекты кода, как синтаксис и использование языковых конструкций. В отличие от этого модульные тесты (которые могут выполняться после завершения построения) позволяют проверить любой функциональный аспект кода. В ходе таких модульных тестов формируются различные показатели, такие как покрытие кода в построении, по набору модульных тестов. Дополнительные сведения см. в разделе Практическое руководство. Настройка покрытия кода с помощью параметров тестирования для автоматических тестов.

С помощью Microsoft Test Manager можно настроить конкретную среду, в которой могут выполняться тесты. Выполнение тестов в изоляции обеспечивает определенный уровень проверки функциональности. Однако виртуальные среды имеют следующие важные особенности.

• Варьирование среды может повлиять на работу кода. Например, параметры и топологию сети может быть сложно протестировать без лабораторной среды.

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

Дополнительные сведения см. в разделах How to: Create an Environment from Virtual Machine Templates и Настройка тестовых компьютеров для выполнения тестов или сбора данных.

Организация наборов тестов для непрерывной интеграции

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

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

Влияние непрерывной интеграции на команду по тестированию

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

Интеграция проекта и обмен информацией

Внедрение непрерывной интеграции может потребовать значительных трудозатрат в зависимости от размера проекта. Команда должна определить объем работ по непрерывной интеграции и спланировать работу в течение первого спринта проекта.

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