Непрерывная интеграция — обзор

Непрерывная интеграция была впервые представлена ​​в 2000 году с помощью программного обеспечения, известного как Cruise Control . На протяжении многих лет непрерывная интеграция стала ключевой практикой в ​​любой организации программного обеспечения. Это практика разработки, призывающая команды разработчиков обеспечивать сборку и последующее тестирование для каждого изменения кода, вносимого в программное обеспечение. Эта концепция предназначалась для устранения проблемы обнаружения поздних случаев возникновения проблем в жизненном цикле сборки. Вместо разработчиков, работающих изолированно и недостаточно интегрированных, была введена Continuous Integration, чтобы гарантировать, что изменения и сборки кода никогда не делались изолированно.

Почему непрерывная интеграция?

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

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

• Является ли код слишком сложным для целей интеграции? — Если процесс непрерывной интеграции продолжает давать сбой, возможно, что код слишком сложный. И это может быть сигналом к ​​применению правильных шаблонов проектирования, чтобы сделать код менее сложным и более понятным.

• Соответствует ли код установленным стандартам кодирования? — Большинство тестовых случаев всегда проверяют, что код придерживается надлежащих стандартов кодирования. Выполнение автоматического теста после автоматической сборки позволяет проверить, соответствует ли код всем требуемым стандартам кодирования.

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

• Были ли все тесты успешными после последнего изменения? — Если тест не пройден, нет смысла продолжать развертывание кода, поэтому это хороший момент, чтобы проверить, готов ли код перейти к этапу развертывания или нет.

Все ли программные компоненты работают вместе, как они должны? — Иногда системы могут стать настолько сложными, что для каждого компонента имеется несколько интерфейсов. В таких случаях всегда важно убедиться, что все программные компоненты работают без сбоев друг с другом.

Является ли код слишком сложным для целей интеграции? — Если процесс непрерывной интеграции продолжает давать сбой, возможно, что код слишком сложный. И это может быть сигналом к ​​применению правильных шаблонов проектирования, чтобы сделать код менее сложным и более понятным.

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

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

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

Workflow

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

Таким образом, на основе вышеуказанного рабочего процесса, как правило, работает непрерывный процесс интеграции.

• Во-первых, разработчик передает код в хранилище контроля версий. Между тем, сервер Continuous Integration на машине сборки интеграции опрашивает хранилище исходного кода на предмет изменений (например, каждые несколько минут).

• Вскоре после того, как происходит фиксация, сервер Continuous Integration обнаруживает, что в репозитории управления версиями произошли изменения, поэтому сервер Continuous Integration извлекает самую последнюю копию кода из репозитория и затем выполняет сценарий сборки, который интегрирует программное обеспечение

• Сервер Continuous Integration генерирует обратную связь, отправляя результаты сборки по электронной почте указанным участникам проекта.

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

• Сервер непрерывной интеграции продолжает запрашивать изменения в хранилище управления версиями, и весь процесс повторяется.

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

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

Сервер Continuous Integration генерирует обратную связь, отправляя результаты сборки по электронной почте указанным участникам проекта.

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

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

Непрерывная интеграция — программное обеспечение

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

Репозиторий исходного кода

Хранилище исходного кода используется для поддержки всего исходного кода и всех изменений, внесенных в него. Два самых популярных из них для управления хранилищем исходного кода — это subversion, а Git с Git является самой последней популярной системой. Теперь мы рассмотрим, как установить Git в системе.

Системные Требования

объем памяти	2 ГБ ОЗУ (рекомендуется)
Дисковое пространство	200 МБ HDD для установки. Для хранения исходного кода проекта требуется дополнительное хранилище, и это зависит от добавляемого исходного кода.
Версия операционной системы	Может быть установлен на Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Установка Git

Шаг 1 — Официальный сайт для Git https://git-scm.com/ . Если вы нажмете на ссылку, вы попадете на домашнюю страницу официального сайта Git, как показано на следующем снимке экрана.

Шаг 2. Чтобы загрузить Git, просто прокрутите экран вниз, перейдите в раздел «Загрузки» и нажмите «Загрузки».

Шаг 3 — Нажмите на ссылку Windows, и загрузка для Git начнется автоматически.

Шаг 4 — Нажмите загруженный файл .exe для Git. В нашем случае мы используем файл Git-2.6.1-64-bit.exe. Нажмите Run, который появляется, появится на следующем экране.

Шаг 5 — Нажмите кнопку Далее, которая появляется на следующем экране.

Шаг 6 — Нажмите Далее на следующем экране, чтобы принять Генеральное лицензионное соглашение.

Шаг 7 — Выберите место для вашей установки Git.

Шаг 8 — Нажмите Далее, чтобы принять компоненты по умолчанию, которые необходимо установить.

Шаг 9 — Выберите опцию «Использовать Git из командной строки Windows», так как мы собираемся использовать Git из Windows.

Шаг 10 — На следующем экране примите настройку по умолчанию «Оформить заказ в стиле Windows, зафиксируйте окончания строк в стиле Unix» и нажмите «Далее».

Шаг 11 — На следующем экране выберите опцию «Использовать окно консоли Windows по умолчанию», так как мы используем Windows в качестве системы для установки Git.

Теперь начнется установка, и после настройки можно будет выполнить последующие шаги для настройки Git.

Конфигурирование Git

После установки Git необходимо выполнить шаги по настройке для начальной настройки Git.

Первое, что нужно сделать, это настроить личность в Git, а затем настроить имя пользователя и адрес электронной почты. Это важно, потому что каждая фиксация Git использует эту информацию, и она неизменно заполняется коммитами, которые вы начинаете создавать. Это можно сделать, открыв командную строку, а затем введя следующие команды:

git config –global user.name “Username”
git config –global user.email “emailid”

Следующий скриншот является примером для лучшего понимания.

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

git config --list

Пример вывода показан на следующем скриншоте.

Сервер непрерывной интеграции

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

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

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

• Atlassian Bamboo — это еще одно популярное программное обеспечение для непрерывной интеграции, предоставляемое компанией Atlassian Pvt. Ltd.

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

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

Atlassian Bamboo — это еще одно популярное программное обеспечение для непрерывной интеграции, предоставляемое компанией Atlassian Pvt. Ltd.

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

Установка TeamCity

Ниже приведены шаги и системные требования для установки Jet Brains TeamCity на ваш компьютер.

Системные Требования

объем памяти	4 ГБ ОЗУ (рекомендуется)
Дисковое пространство	1 ГБ HDD для установки. Для хранения рабочей области сборки для каждого проекта требуется дополнительное хранилище.
Версия операционной системы	Может быть установлен на Windows, Linux, Mac OS X.

Монтаж

Шаг 1 — Официальный сайт TeamCity — https://www.jetbrains.com/teamcity/ . Если вы нажмете указанную ссылку, вы перейдете на домашнюю страницу официального сайта TeamCity, как показано на следующем снимке экрана. Вы можете просмотреть страницу, чтобы загрузить необходимое программное обеспечение для TeamCity.

Шаг 2 — Загруженный .exe-файл используется для выполнения TeamCity-9.1.6.exe . Дважды щелкните исполняемый файл, а затем нажмите «Выполнить» на следующем всплывающем экране.

Шаг 3 — Нажмите Далее, чтобы начать настройку.

Шаг 4 — Нажмите кнопку «Я согласен», чтобы принять лицензионное соглашение и продолжить установку.

Шаг 5 — Выберите место для установки и нажмите Далее.

Шаг 6 — Выберите компоненты по умолчанию для установки и нажмите Далее

Это запустит процесс установки. После завершения процесс настройки будет следовать.

Шаг 7 — Выберите номер порта для запуска сервера. Лучше всего использовать другой порт, например 8080 .

Шаг 8 — Затем он спросит, для какой учетной записи TeamCity необходимо запустить. Выберите учетную запись SYSTEM и нажмите «Далее».

Шаг 9 — Затем он попросит службы, которые должны быть запущены. Примите значения по умолчанию и нажмите «Далее».

Настройка TeamCity

После завершения установки следующим шагом будет настройка TeamCity. Это программное обеспечение можно открыть, перейдя по следующему URL-адресу в браузере:

Http: // locahost: 8080

Шаг 1 — Первый шаг — указать расположение сборок, которое будет выполнено TeamCity. Выберите нужное место и нажмите кнопку «Продолжить».

Шаг 2 — Следующий шаг — указать базу данных для хранения всех артефактов TeamCity. Для целей учебника можно выбрать Внутреннюю (HSQLDB) , которая является внутренней базой данных, которая лучше всего подходит для использования продуктов в целях тестирования.

TeamCity обработает все необходимые шаги, чтобы запустить его.

Шаг 3 — Далее вам будет предложено принять лицензионное соглашение. Примите то же самое и нажмите «Продолжить».

Шаг 4 — Вам необходимо создать учетную запись администратора, которая будет использоваться для входа в программное обеспечение TeamCity. Введите необходимые данные и нажмите кнопку «Создать учетную запись».

Теперь вы войдете в TeamCity.

Инструмент сборки

Инструмент Build — это инструмент, который гарантирует, что программа построена определенным образом. Инструмент обычно выполняет список задач, которые необходимы для правильной сборки программы. Поскольку в нашем примере мы будем рассматривать программу .Net , мы будем рассматривать MSBuild как инструмент сборки. Инструмент MSBuild просматривает файл сборки, который содержит список задач, которые используются для сборки проекта. Давайте посмотрим на типичный файл сборки для проекта веб-конфигурации.

Ниже приведены ключевые разделы файла сборки, которые необходимо учитывать.

Настройки IIS

Следующие настройки используются для определения того, какой номер порта, каков путь на веб-сервере и какой тип аутентификации требуется при запуске приложения. Это важные настройки, которые будут изменены с помощью команды MSBuild, когда мы узнаем, как развертывание будет выполнено позже в руководстве.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

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

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

Версия .Net Framework

TargetFrameworkVersion сообщает, какая версия .Net должна присутствовать для работы проекта. Это абсолютно необходимо, потому что, если на сервере сборки этого нет, сборка завершится неудачно.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Среда развертывания — Amazon

В этом руководстве мы обеспечим возможность развертывания нашего приложения в Amazon на сервере Continuous Integration. Для этого нам необходимо убедиться в наличии следующих артефактов.

Сервер базы данных

Выполните следующие шаги, чтобы убедиться, что сервер баз данных установлен в Amazon для развертывания.

Шаг 1. Перейдите на консоль Amazon — https://aws.amazon.com/console/.

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

Шаг 2 — Перейдите в раздел RDS, чтобы создать базу данных.

Шаг 3 — Нажмите Экземпляры на следующем всплывающем экране.

Шаг 4 — Выберите опцию Launch DB на следующем появившемся экране.

Шаг 5. Выберите вкладку SQL Server, а затем выберите параметр «Выбрать» для SQL Server Express.

Шаг 6. Убедитесь, что введены следующие данные, чтобы подтвердить, что вы используете бесплатный уровень баз данных, доступных на Amazon.

Шаг 7 — Нажмите кнопку «Следующий шаг» после заполнения всех полей.

Шаг 8 — На следующем появившемся экране примите все настройки по умолчанию и нажмите Launch DB Instance .

Шаг 9 — Затем вам будет представлен экран с сообщением об успешном запуске БД. На этой же странице будет кнопка для просмотра экземпляра БД. Нажмите на ссылку, чтобы увидеть, как настраивается ваш экземпляр БД .

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

Веб сервер

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

Шаг 1. Перейдите в консоль Amazon — https://aws.amazon.com/console/ .

Войдите с вашими учетными данными. Обратите внимание, что вы можете подать заявку на бесплатный идентификатор на сайте Amazon , что позволит вам иметь бесплатный уровень, который позволит вам использовать некоторые ресурсы на Amazon бесплатно.

Шаг 2 — Перейдите в раздел EC2, чтобы создать свой веб-сервер.

Шаг 3 — На следующем экране нажмите Launch Instance.

Шаг 4 — Нажмите Windows — Microsoft Windows Server 2010 R2 Base .

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

Шаг 6 — Примите настройки по умолчанию на следующем появившемся экране и затем выберите опцию Далее: Добавить хранилище .

Шаг 7 — Примите настройки по умолчанию на следующем экране и выберите опцию Next: Tag Instance .

Шаг 8 — Примите настройки по умолчанию на следующем экране и выберите опцию Далее: Настроить группу безопасности .

Шаг 9 — Примите настройки по умолчанию на следующем экране и выберите опцию « Просмотр и запуск» .

Шаг 10 — Нажмите Launch на следующем появившемся экране.

Шаг 11 — На следующем появившемся экране вам будет предложено создать пару ключей. Это будет использоваться для входа на сервер позднее. Просто создайте пару ключей и нажмите Launch Instance .

Теперь экземпляр будет настроен в Amazon.

Непрерывная интеграция — снижение рисков

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

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

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

Риск 1 — отсутствие развертываемого программного обеспечения

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

• Мало или нет уверенности в том, сможем ли мы даже создать программное обеспечение.

• Длительные этапы интеграции перед поставкой программного обеспечения внутренне (т. Е. Группой тестирования) или извне (т. Е. Клиентом), в течение которого больше ничего не делается.

• Невозможность производить и воспроизводить тестируемые сборки.

Мало или нет уверенности в том, сможем ли мы даже создать программное обеспечение.

Длительные этапы интеграции перед поставкой программного обеспечения внутренне (т. Е. Группой тестирования) или извне (т. Е. Клиентом), в течение которого больше ничего не делается.

Невозможность производить и воспроизводить тестируемые сборки.

Решение

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

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

«Невозможность синхронизации с базой данных». Иногда разработчики не могут быстро воссоздать базу данных во время разработки, и, следовательно, им трудно вносить изменения. Часто это происходит из-за разделения между командой разработчиков базы данных и командой разработчиков. Каждая команда будет сосредоточена на своих собственных обязанностях и будет мало сотрудничать друг с другом. Эта проблема имеет следующие три побочных эффекта —

• Страх внесения изменений или рефакторинга базы данных или исходного кода.

• Сложность в заполнении базы данных различными наборами тестовых данных.

• Трудности в поддержке сред разработки и тестирования (например, Разработка, Интеграция, Контроль качества и Тестирование).

Страх внесения изменений или рефакторинга базы данных или исходного кода.

Сложность в заполнении базы данных различными наборами тестовых данных.

Трудности в поддержке сред разработки и тестирования (например, Разработка, Интеграция, Контроль качества и Тестирование).

Решение

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

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

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

Риск 2 — обнаружение дефектов в конце жизненного цикла

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

Решение

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

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

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

Риск 3 — Отсутствие видимости проекта

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

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

Решение

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

Риск 4 — Низкое качество программного обеспечения

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

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

Решение

Существуют программные компоненты для проверки качества кода, которые можно интегрировать с программным обеспечением CI. Это может быть выполнено после того, как код собран, чтобы гарантировать, что код фактически соответствует надлежащим правилам кодирования.

Непрерывная интеграция — контроль версий

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

Первой популярной системой контроля версий был проприетарный UNIX-инструмент под названием SCCS (Система контроля исходного кода), который датируется 1970-ми годами. Это было заменено RCS , системой контроля версий, а затем CVS , системой параллельных версий.

В настоящее время наиболее популярными системами контроля версий являются Subversion и Git . Давайте сначала посмотрим, почему нам нужно использовать систему контроля версий, а затем давайте рассмотрим размещение нашего исходного кода в системе репозитория исходного кода Git .

Назначение системы контроля версий

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

Разработчики должны использовать его для исходного кода — по умолчанию весь исходный код должен храниться в системе контроля версий

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

Разработчики должны использовать его для исходного кода — по умолчанию весь исходный код должен храниться в системе контроля версий

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

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

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

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

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

Работа с Git для системы контроля версий исходного кода

Этот раздел теперь будет посвящен тому, как Git может использоваться в качестве системы управления версиями. Он будет посвящен тому, как вы можете загрузить свой код в систему контроля версий и управлять изменениями в нем.

Наше демо-приложение

Для целей всего этого руководства мы рассмотрим простое приложение Web ASP.Net, которое будет использоваться для всего процесса непрерывной интеграции. Нам не нужно сосредотачиваться на деталях всего кода для этого упражнения, просто иметь представление о том, что делает проект, достаточно для понимания всего процесса непрерывной интеграции. Это приложение .Net было построено с использованием интегрированной среды разработки Visual Studio .

На следующем снимке экрана показана структура решения в среде Visual Studio. Это очень простое веб-приложение с основным кодом в файле Demo.aspx .

Код в файле Demo.aspx показан в следующей программе —

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Код очень прост и просто выводит строку «Непрерывная интеграция» в браузер.

Когда вы запустите проект в Google Chrome, результат будет таким, как показано на следующем снимке экрана.

Перемещение исходного кода в Git

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

Шаг 1 — Инициализируйте репозиторий Git . Перейдите в командную строку, перейдите в папку вашего проекта и введите команду git init . Эта команда добавит необходимые файлы Git в папку проекта, чтобы Git мог их распознать, когда его необходимо загрузить в репозиторий.

Шаг 2 — Добавление ваших файлов, которые необходимо добавить в репозиторий Git. Это можно сделать, введя команду git add . Опция точка сообщает Git, что все файлы в папке проекта необходимо добавить в репозиторий Git.

Шаг 3 — Последний шаг — зафиксировать файлы проекта в репозитории Git. Этот шаг необходим для того, чтобы все файлы теперь были частью Git. Команда для выдачи приведена на следующем снимке экрана. Опция –m — предоставить комментарий к загрузке файлов.

Ваше решение теперь доступно в Git.

Непрерывная интеграция — Особенности

Ниже приведены некоторые основные функции или методы непрерывной интеграции.

• Поддерживать один исходный репозиторий — весь исходный код поддерживается в одном репозитории. Это позволяет избежать разброса исходного кода по нескольким местам. Такие инструменты, как Subversion и Git, являются наиболее популярными инструментами для поддержки исходного кода.

• Автоматизация сборки . Сборка программного обеспечения должна выполняться таким образом, чтобы его можно было автоматизировать. Если необходимо выполнить несколько шагов, инструмент сборки должен быть в состоянии это сделать. Для .Net MSBuild является инструментом сборки по умолчанию, а для приложений на основе Java у вас есть такие инструменты, как Maven и Grunt .

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

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

• Держите сборку быстро — Сборка должна произойти за считанные минуты. Сборка не должна занять несколько часов, потому что это будет означать, что шаги сборки настроены неправильно.

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

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

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

Поддерживать один исходный репозиторий — весь исходный код поддерживается в одном репозитории. Это позволяет избежать разброса исходного кода по нескольким местам. Такие инструменты, как Subversion и Git, являются наиболее популярными инструментами для поддержки исходного кода.

Автоматизация сборки . Сборка программного обеспечения должна выполняться таким образом, чтобы его можно было автоматизировать. Если необходимо выполнить несколько шагов, инструмент сборки должен быть в состоянии это сделать. Для .Net MSBuild является инструментом сборки по умолчанию, а для приложений на основе Java у вас есть такие инструменты, как Maven и Grunt .

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

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

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

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

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

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

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

Ниже приведен список наиболее важных требований для непрерывной интеграции.

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

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

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

  Обычно в Continuous Integration проводится 3 типа тестов, а именно модульные тесты, тесты компонентов и приемочные тесты .

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

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

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

  • Люди перестанут делать полную сборку и будут запускать тесты до регистрации. Вы начнете получать больше неудачных сборок.

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

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

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

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

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

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

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

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

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

Обычно в Continuous Integration проводится 3 типа тестов, а именно модульные тесты, тесты компонентов и приемочные тесты .

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

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

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

Люди перестанут делать полную сборку и будут запускать тесты до регистрации. Вы начнете получать больше неудачных сборок.

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

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

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

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

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

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

Непрерывная интеграция — построение решения

Для различных языков программирования доступно множество инструментов сборки. Некоторые из самых популярных инструментов сборки включают Ant для Java и MSBuild для .NET . Использование инструмента сценариев, разработанного специально для сборки программного обеспечения, вместо пользовательского набора сценариев оболочки или пакетных сценариев является наиболее эффективным способом разработки согласованного, повторяемого решения для сборки.

Так зачем нам начинать процесс сборки. Начнем с того, что для сервера Continuous Integration процесс сборки должен быть простым и легко реализованным.

Давайте рассмотрим простой пример того, как может выглядеть файл сборки для .Net —

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

В отношении приведенного выше кода необходимо отметить следующие аспекты:

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

• В нашей цели мы сохраняем опционное сообщение, которое будет отображаться при запуске процесса сборки.

• Задача MSBuild используется для указания того, какой проект .Net необходимо построить.

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

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

Задача MSBuild используется для указания того, какой проект .Net необходимо построить.

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

Построение решения в .Net

Инструментом сборки по умолчанию для .Net является MSBuild, и он поставляется с платформой .Net. В зависимости от платформы в вашей системе вам будет доступна соответствующая версия MSbuild. Например, если у вас установлена ​​платформа .Net в папке по умолчанию, вы найдете файл MSBuild.exe в следующей папке:

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Давайте посмотрим, как мы можем построить наш пример проекта. Давайте предположим, что наш пример проекта находится в папке с именем C: \ Demo \ Simple .

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

msbuild C:\Demo\Simple\Simple.csproj

В приведенном выше примере csproj — это файл проекта, специфичный для .Net. Файл csproj содержит всю соответствующую информацию, чтобы обеспечить наличие необходимой информации для правильной сборки программного обеспечения. Ниже приведен скриншот вывода команды MSBuild.

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

Непрерывная интеграция — создание сценариев

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

Сценарии сборки используются для построения решения, которое станет частью всего непрерывного цикла интеграции. Давайте рассмотрим общий сценарий сборки, который создается как часть Visual Studio в .Net для нашего примера решения. Скрипт сборки довольно большой, даже для простого решения, поэтому мы рассмотрим самые важные его части. По умолчанию сценарий сборки будет храниться в файле с тем же именем, что и основное решение в Visual Studio. Так что в нашем случае, если вы откроете файл Simple.csproj , вы увидите все настройки, которые будут использованы для построения решения.

• Зависимость от используемой версии MSBuild — в следующих настройках будут использоваться файлы MSBuild, установленные на сервере CI.

Зависимость от используемой версии MSBuild — в следующих настройках будут использоваться файлы MSBuild, установленные на сервере CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == 
   ''">10.0</VisualStudioVersion>

<VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" />

<Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

• Какие файлы необходимы для правильного построения решения — тег ItemGroup будет содержать все необходимые .Net-файлы, необходимые для успешного построения проекта. Эти файлы должны будут находиться на сервере сборки соответственно.

Какие файлы необходимы для правильного построения решения — тег ItemGroup будет содержать все необходимые .Net-файлы, необходимые для успешного построения проекта. Эти файлы должны будут находиться на сервере сборки соответственно.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

• Какие настройки веб-сервера следует использовать? Когда мы посетим нашу тему «Непрерывное развертывание», вы увидите, как MSBuild будет использоваться для переопределения этих настроек и развертывания на нашем выбранном сервере.

Какие настройки веб-сервера следует использовать? Когда мы посетим нашу тему «Непрерывное развертывание», вы увидите, как MSBuild будет использоваться для переопределения этих настроек и развертывания на нашем выбранном сервере.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

CI — построение на сервере

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

Шаг 1 — Скопируйте весь файл решения на сервер. Мы создали сервер экземпляров Amazon, который будет использоваться в качестве нашего сервера сборки. Итак, сделайте ручное копирование на сервер всего решения .Net на сервер.

Шаг 2 — Убедитесь, что фреймворк присутствует на сервере. Если вы скомпилировали свое приложение в .Net framework 4.0 на своем клиентском компьютере, вы должны убедиться, что оно установлено и на сервере. Так что перейдите в папку C: \ Windows \ Microsoft.NET \ Framework на вашем сервере и убедитесь, что желаемый каркас присутствует.

Шаг 3 — Теперь давайте просто запустим MSBuild на сервере и посмотрим, что произойдет.

Итак, похоже, что мы совершили ошибку. В непрерывной интеграции есть один важный урок: вам нужно убедиться, что Build работает на сервере сборки. Для этого вам необходимо убедиться, что на сервере сборки установлено все необходимое программное обеспечение.

Для .Net нам нужно установить компонент с именем Visual Studio Redistributable package . Этот пакет содержит все необходимые файлы, необходимые для построения приложения .Net на сервере. Итак, давайте выполним следующие шаги установки на сервере сборки.

Шаг 4 — Дважды щелкните исполняемый файл, чтобы начать установку.

Шаг 5 — На следующем шаге согласитесь с условиями лицензии и нажмите «Установить».

Шаг 6 — Теперь при запуске MSBuild нам нужно убедиться, что при вызове MSBuild мы добавили дополнительный параметр, который — p: VisualStudioversion = 12.0 . Это гарантирует, что MSBuild ссылается на те файлы, которые были загружены на предыдущем шаге.

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

CI — проверка в исходном коде

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

Шаг 1 — Инициализируйте репозиторий, чтобы его можно было загрузить в Git. Это делается с помощью команды git init. Поэтому вам нужно перейти в папку вашего проекта и выполнить команду git init .

Шаг 2 — Следующий шаг называется подготовкой файлов в Git. Это подготовит все файлы в папке проекта, которые необходимо добавить в Git. Вы делаете это с помощью команды git add, как показано на следующем снимке экрана. «.» нотация используется, чтобы сказать, что все файлы в каталоге и подкаталоге должны быть включены в коммит.

Шаг 3 — Последний шаг — зафиксировать файлы в Git-репозитории, чтобы он стал полноценным Git-репозиторием.

CI — Создание проекта в TeamCity

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

Шаг 1 — Войдите в систему TeamCity. Перейдите по ссылке на вашем сервере непрерывной интеграции — http: // localhost: 8080 / login.html .

Введите учетные данные администратора и войдите на сервер.

Шаг 2 — После входа в систему вы увидите домашний экран. Нажмите Создать проект, чтобы начать новый проект.

Шаг 3 — Дайте имя проекту и нажмите «Создать», чтобы запустить проект. В нашем случае мы присваиваем нашему проекту имя «Demo», как показано на следующем снимке экрана.

Шаг 4 — Следующий шаг — упомянуть Git-репозиторий, который будет использоваться в нашем проекте. Помните, что в среде непрерывной интеграции сервер CI должен получить код из репозитория с поддержкой Git. Мы уже включили нашу папку проекта в Git-репозиторий на предыдущем шаге. В TeamCity вам нужно создать корень VCS. Для этого щелкните Корни VCS на главном экране проекта.

Шаг 5 — На следующем экране нажмите « Создать корень VCS», как показано на следующем снимке экрана.

Шаг 6 — На следующем экране, который появляется, выполните следующие шаги —

• Укажите тип VCS как Git.

• Дайте имя для корня VCS, это может быть любое дружественное имя. Мы дали название как приложение .

• Присвойте URL-адрес Fetch как C: \ Demo \ Simple — это git- репозиторий без поддержки.

• Если вы прокрутите экран вниз, вы увидите кнопку «Проверить соединение». Щелкните по нему, чтобы убедиться, что вы можете успешно подключиться к репозиторию с поддержкой Git.

Укажите тип VCS как Git.

Дайте имя для корня VCS, это может быть любое дружественное имя. Мы дали название как приложение .

Присвойте URL-адрес Fetch как C: \ Demo \ Simple — это git- репозиторий без поддержки.

Если вы прокрутите экран вниз, вы увидите кнопку «Проверить соединение». Щелкните по нему, чтобы убедиться, что вы можете успешно подключиться к репозиторию с поддержкой Git.

Шаг 7 — Нажмите «Создать», и вы увидите, что ваш репозиторий зарегистрирован, как показано на следующем рисунке.

Шаг 8 — Следующий шаг — создать конфигурацию сборки, которая будет использоваться для сборки проекта. Перейдите на экран своего проекта в TeamCity → Общие настройки . Нажмите Создать конфигурацию сборки.

Шаг 9 — На следующем экране дайте имя для конфигурации сборки. В нашем случае мы назвали его DemoBuild, а затем нажмите «Создать».

Шаг 10 — На следующем появившемся экране вам будет предложено выбрать репозиторий VCS, который был создан на предыдущих этапах. Поэтому выберите название «Приложение» и нажмите «Вложить».

Шаг 11 — Теперь на следующем всплывающем экране нам нужно настроить шаги сборки. Поэтому нажмите на ссылку « настроить шаги сборки вручную ».

Шаг 12 — На следующем экране сборки нам нужно ввести следующие детали —

• Выберите тип Runner как MSBuild.

• Дайте необязательное имя для имени шага.

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

• Выберите версию MSBuild как «Microsoft Build Tools 2013».

• Выберите MSBuild ToolsVersion как 12.0.

• Прокрутите страницу вниз, чтобы сохранить настройки.

Выберите тип Runner как MSBuild.

Дайте необязательное имя для имени шага.

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

Выберите версию MSBuild как «Microsoft Build Tools 2013».

Выберите MSBuild ToolsVersion как 12.0.

Прокрутите страницу вниз, чтобы сохранить настройки.

Шаг 13 — На следующем экране нажмите Run.

Вы увидите, что сборка вашего приложения сейчас выполняется.

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

Вы также можете перейти в журнал сборки, чтобы увидеть все шаги, которые были выполнены сервером Continuous Integration, как показано на следующем снимке экрана.

Непрерывная интеграция — определение задач

Теперь, когда у нас есть базовый код в Git и ссылка на сервер Continuous Integration, пришло время увидеть первый шаг Continuous Integration в действии. Это делается путем определения задач на сервере непрерывной интеграции, таких как триггеры, что делает весь процесс непрерывной интеграции максимально бесшовным. Давайте внесем изменения в наш код в Visual Studio.

Шаг 1. Перейдите на страницу Demo.aspx в Visual Studio и внесите изменения в заголовок страницы.

Шаг 2 — Если мы запросим наш репозиторий Git с помощью команды git status , вы фактически увидите, что файл Demo.aspx был изменен.

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

Шаг 3 — Перейдите на панель управления проектом, щелкните раздел триггеров и нажмите « Добавить новый триггер» .

Шаг 4 — На следующем появившемся экране выберите триггер VCS , который будет использоваться для создания триггера, чтобы при регистрации в хранилище была запущена сборка.

Шаг 5 — Нажмите Показать дополнительные параметры и убедитесь, что выбраны параметры, показанные на следующем снимке экрана.

Шаг 6 — Нажмите Сохранить. Теперь вы увидите, что триггер успешно зарегистрирован, как показано на следующем снимке экрана.

Шаг 7 — Теперь пришло время проверить наш код в репозитории Git и посмотреть, что произойдет. Итак, давайте перейдем к нашей командной строке и выполним команду git add, чтобы подготовить измененные файлы.

Шаг 8 — Теперь введите команду git commit , и она внесет изменения в репозиторий Git.

Шаг 9. Если вы сейчас перейдете на экран «Обзор проектов», вы увидите, что новая сборка будет запущена и запущена.

Если вы видите вкладку «Журнал изменений» , вы увидите комментарий git, который запустил сборку.

Давайте попробуем это еще раз. Давайте сделаем еще одно изменение в файле Demo.aspx . Давайте выполним команду git add и команду git commit со следующим сообщением commit.

Теперь вы увидите, что сборка автоматически запускается на панели мониторинга проекта в TeamCity.

Сборка покажет сообщение об успехе.

Теперь вы увидите сообщение «Second commit», которое использовалось, когда изменение было зафиксировано в репозитории git .

Теперь мы успешно завершили первую часть процесса непрерывной интеграции.

CI — Уведомления о сбое сборки

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

Ниже приведены шаги по настройке уведомлений по электронной почте в TeamCity.

Шаг 1 — В TeamCity перейдите на панель управления проектом, нажмите Администрирование в правом верхнем углу. Вы увидите ссылку Email Notifier в левой части. Нажмите на эту ссылку, чтобы открыть общие настройки электронной почты.

Шаг 2 — Следующий шаг — ввести информацию о действительном SMTP-сервере . Gmail предоставляет бесплатное средство SMTP, которое может использовать любой. Таким образом, мы можем ввести эти подробности на следующем экране, как показано на следующем снимке экрана.

• SMTP-хост — smtp.gmail.com
• SMTP порт № 465
• Отправлять сообщения электронной почты от и SMTP логин — это должен быть действительный идентификатор Gmail
• Пароль SMTP — действительный пароль для этого идентификатора Gmail
• Безопасное соединение — укажите это как SSL

Шаг 3 — Нажмите Test Connection, чтобы убедиться, что настройки работают правильно. Затем нажмите Сохранить, чтобы сохранить настройки.

Шаг 4 — Следующий шаг — включить уведомления о сборке для пользователя. Первая задача — создать пользователя, который будет получать эти уведомления о сборке. Перейдите на панель управления проектом и выберите опцию «Пользователи» .

Шаг 5 — Создать нового пользователя. Введите требуемое имя пользователя и пароль. Затем нажмите кнопку «Создать пользователя», которая будет расположена внизу экрана.

Шаг 6 — Теперь войдите в систему TeamCity с этим новым идентификатором пользователя и паролем.

Шаг 7 — После входа в систему вам будут представлены общие настройки пользователя. В разделе «Уведомление по электронной почте» нажмите «Изменить».

Шаг 8 — На следующем появившемся экране нажмите Добавить новое правило .

Шаг 9. В разделе «Добавить новое правило» выберите следующие два параметра и нажмите «Сохранить».

• Сборки из выбранных проектов — выберите демонстрационный проект.

• Включите флажок «Сбой сборки».

Сборки из выбранных проектов — выберите демонстрационный проект.

Включите флажок «Сбой сборки».

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

Шаг 10 — Теперь давайте запустим неправильную сборку, чтобы увидеть это в действии. В Visual Studio перейдите в файл demo.aspx.cs и добавьте неверную строку кода.

Шаг 11 — Теперь верните код из Git, выполнив git add и git commit .

Теперь на панели инструментов проекта сборка будет автоматически запущена, и вы увидите, что сборка не удалась, как показано на следующем снимке экрана.

Если вы войдете в Gmail-идентификатор демоузера , вы увидите уведомление об ошибке сборки , как показано на следующем снимке экрана.

CI — Документация и обратная связь

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

Каковы преимущества наличия этих показателей?

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

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

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

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

  Географически рассредоточенные системы и ненадежное аппаратное или программное обеспечение также могут вызывать проблемы с производительностью. Изучите и улучшите любые ресурсы инфраструктуры, чтобы сократить время сборки.

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

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

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

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

Географически рассредоточенные системы и ненадежное аппаратное или программное обеспечение также могут вызывать проблемы с производительностью. Изучите и улучшите любые ресурсы инфраструктуры, чтобы сократить время сборки.

метрика

Ниже приведены некоторые показатели, доступные на сервере непрерывной интеграции.

Давайте посмотрим, что может предложить TeamCity —

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

TeamCity имеет возможность увидеть, действительно ли на сервере CI возникают какие-либо проблемы с инфраструктурой. На панели администратора в TeamCity можно щелкнуть « Использование диска», чтобы увидеть, сколько дискового пространства используется каждой сборкой.

Если требуется дополнительная информация, то в TeamCity есть кнопка диагностики , которая может предоставить дополнительную информацию о ЦП и памяти , используемых сервером CI.

Детальный просмотр метрик сборки

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

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

Одной из ключевых особенностей Continuous Integration является обеспечение того, чтобы текущее тестирование содержало весь код, созданный сервером CI. После того, как CI Server выполняет сборку, необходимо убедиться в наличии тестовых случаев для проверки необходимого кода. Каждый сервер CI имеет возможность запускать модульные тесты как часть набора CI . В .Net модульное тестирование — это функция, которая встроена в платформу .Net, и то же самое можно включить и в CI Server.

В этой главе будет показано, как мы можем определить тестовый пример в .Net, а затем позволить нашему серверу TeamCity выполнить этот тестовый пример после завершения сборки. Для этого нам сначала нужно убедиться, что для нашего примера проекта определен модульный тест.

Чтобы сделать это, мы должны следовать последующим шагам с максимальной осторожностью.

Шаг 1 — Давайте добавим новый класс в наше решение, которое будет использоваться в нашем модульном тесте. Этот класс будет иметь переменную имени, которая будет содержать строку «Непрерывная интеграция». Эта строка будет отображаться на веб-странице. Щелкните правой кнопкой мыши Простой проект и выберите пункт меню Добавить → Класс .

Шаг 2 — Дайте имя классу как Tutorial.cs и нажмите кнопку «Добавить» в нижней части экрана.

Шаг 3 — Откройте файл Tutorial.cs и добавьте в него следующий код. Этот код просто создает строку с именем Name , а в конструкторе присваивает имя строковому значению как Continuous Integration .

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Шаг 4 — Давайте внесем изменения в наш файл Demo.aspx.cs, чтобы использовать этот новый класс. Обновите код в этом файле следующим кодом. Таким образом, этот код теперь создаст новый экземпляр класса, созданного выше.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Шаг 5 — В нашем файле demo.aspx теперь давайте обратимся к переменной tp.Name , которая была создана в файле aspx.cs.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

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

Шаг 6 — Теперь пришло время добавить наши модульные тесты в проект. Щелкните правой кнопкой мыши Решение и выберите пункт меню Добавить → Новый проект .

Шаг 7 — Перейдите к Test и в правой части выберите Project Unit Project . Дайте имя как DemoTest и затем нажмите OK.

Шаг 8 — В вашем проекте Demo Test вам нужно добавить ссылку на проект Simple и необходимые сборки для тестирования . Щелкните правой кнопкой мыши по проекту и выберите пункт меню Добавить ссылку .

Шаг 9 — На следующем появившемся экране перейдите в Projects, выберите Simple Reference и нажмите OK.

Шаг 10 — Нажмите Добавить ссылку еще раз, перейдите к Сборкам и введите Web в поле поиска. Затем добавьте ссылку на System.Web .

Шаг 11 — В файле модульного теста добавьте следующий код. Этот код гарантирует, что у класса Tutorial есть переменная имени строки. Это также подтвердит тот факт, что Имя должно равняться значению «Непрерывная интеграция». Это будет наш простой тестовый пример.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Шаг 12. Теперь давайте запустим наш тест в Visual Studio, чтобы убедиться, что он работает. В Visual Studio выберите пункт меню « Тест» → «Выполнить» → «Все тесты» .

После запуска теста вы увидите, что тест успешно запущен в левой части Visual Studio.

Включение непрерывного тестирования в TeamCity. Теперь, когда все тестовые примеры созданы, пришло время интегрировать их в наш сервер Team City.

Шаг 13 — Для этого нам нужно создать шаг сборки в конфигурации нашего проекта. Перейдите к домашней странице своего проекта и нажмите «Изменить настройки конфигурации».

Шаг 14 — Затем перейдите в Шаг сборки → MS Build и нажмите Добавить шаг сборки, как показано на следующем скриншоте.

На следующем экране добавьте следующие значения —

• Выберите тип бегуна в качестве тестов Visual Studio.

• Введите необязательное имя шага теста.

• Выберите тип тестового двигателя как VSTest .

• Выберите версию Test Engine как VSTest2013 .

• В имени файла Test укажите местоположение как DemoTest \ bin \ Debug \ DemoTest.dll. Помните, что DemoTest — это название нашего проекта, который содержит наши модульные тесты. DemoTest.dll будет сгенерирован нашим первым шагом сборки.

• Нажмите кнопку Сохранить, которая будет доступна в конце экрана.

Выберите тип бегуна в качестве тестов Visual Studio.

Введите необязательное имя шага теста.

Выберите тип тестового двигателя как VSTest .

Выберите версию Test Engine как VSTest2013 .

В имени файла Test укажите местоположение как DemoTest \ bin \ Debug \ DemoTest.dll. Помните, что DemoTest — это название нашего проекта, который содержит наши модульные тесты. DemoTest.dll будет сгенерирован нашим первым шагом сборки.

Нажмите кнопку Сохранить, которая будет доступна в конце экрана.

Теперь у вас будет 2 этапа сборки для вашего проекта. Первый — это шаг Build, который создаст код вашего приложения и ваш тестовый проект. А следующий будет использоваться для запуска ваших тестовых случаев.

Шаг 15. Теперь пришло время зарегистрировать весь ваш код в Git, чтобы можно было запустить весь процесс сборки. Единственное отличие состоит в том, что на этот раз вам нужно запустить команды git add и git commit из родительской папки Demo, как показано на следующем снимке экрана.

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

Шаг 16. Если вы щелкнете по результату «Тест пройден» и перейдете на вкладку «Тест», вы увидите, что UnitTest1 был выполнен и что он прошел.

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

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

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

Непрерывная проверка сокращает время между обнаружением и исправлением. Доступен ряд инструментов непрерывного контроля. В этом примере мы будем использовать NCover 3.x, который интегрирован с TeamCity. Давайте посмотрим, как мы можем проводить постоянные проверки и что они могут сделать для нас.

Скачать и установить NCover

NCover — это отдельный продукт, который необходимо загрузить и установить. Чтобы загрузить NCover, перейдите по следующей ссылке и загрузите 32-разрядный установщик — http://www.ncover.com/info/download.

Запустите загруженный установщик и нажмите «Далее» после запуска установщика.

Примите лицензионное соглашение и нажмите кнопку Далее.

Примите компоненты по умолчанию и нажмите «Далее».

Нажмите на кнопку Установить, чтобы начать установку.

Нажмите кнопку Готово, чтобы завершить установку.

Запустите установку NCover в первый раз, перейдя в C: \ Program Files (x86) \ NCover \ NCover.Explorer.exe . Вам просто нужно будет установить пробный ключ в первый раз, что является простым процессом.

Настройте проект в TeamCity для использования NCover

Шаг 1. Перейдите на начальный экран проекта и нажмите «Изменить настройки конфигурации».

Шаг 2 — Перейдите к шагу сборки и нажмите «Изменить» для TestStep . Непрерывная проверка должна выполняться вместе с определенными модульными тестами.

Шаг 3 — В разделе .Net Coverage, нажмите .Net Coverage Tool . А затем выберите следующие настройки.

• Выберите инструмент .Net Coverage в качестве NCover (3.x)
• Платформа как x86
• Версия как v4.0
• Путь к NCover как C: \ Program Files (x86) \ NCover
• Оставьте остальные настройки такими, какие они есть.

Шаг 4 — Нажмите Сохранить.

Шаг 5 — Теперь перейдите на главный экран вашего проекта и нажмите Run.

Шаг 6 — Как только сборка будет запущена, нажмите «Тест пройден». Теперь вы увидите экран покрытия кода и много метрических индикаторов.

Шаг 7. Теперь вы можете перейти на вкладку «Покрытие кода», чтобы получить дополнительную информацию об анализе кода.

Шаг 8 — Нажмите на fullcoveragereport.html . Теперь вы получите полный исчерпывающий отчет о проверке кода .Net .

Непрерывная интеграция — база данных

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

В интеграции баз данных, как правило, все артефакты, связанные с интеграцией базы данных —

• Должен находиться в системе контроля версий.
• Может быть проверен на строгость и проверен на соответствие политике.
• Может быть сгенерирован с использованием ваших скриптов сборки.

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

Удаление базы данных — удаление базы данных и удаление связанных данных, чтобы вы могли создать новую базу данных с тем же именем

Создать новую базу данных — создать новую базу данных, используя язык определения данных (DDL).

Вставьте исходные данные — вставьте любые исходные данные (например, таблицы поиска), которые ваша система должна содержать при доставке.

Миграция базы данных и данных — Миграция схемы базы данных и данных на периодической основе (если вы создаете систему на основе существующей базы данных).

Изменить атрибуты столбца — Изменить атрибуты столбца таблицы и ограничения на основе требований и рефакторинга.

Изменить тестовые данные — Изменить тестовые данные по мере необходимости для нескольких сред.

Итак, в нашем примере с Continuous Database мы собираемся сделать следующие шаги:

• Мы создадим базу данных MS SQL Server и соответствующую таблицу.

• Мы создадим скрипт из SQL Server Management Studio. Этот скрипт базы данных будет использоваться для настройки нашей таблицы в базе данных.

• Мы напишем код в нашем проекте ASP.Net для доступа к этой базе данных.

• Мы создадим шаг в нашем проекте в TeamCity для запуска этого скрипта.

• Мы проверим наш скрипт в Git.

Мы создадим базу данных MS SQL Server и соответствующую таблицу.

Мы создадим скрипт из SQL Server Management Studio. Этот скрипт базы данных будет использоваться для настройки нашей таблицы в базе данных.

Мы напишем код в нашем проекте ASP.Net для доступа к этой базе данных.

Мы создадим шаг в нашем проекте в TeamCity для запуска этого скрипта.

Мы проверим наш скрипт в Git.

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

Шаг 1 — Создайте базу данных MS SQL Server и соответствующую таблицу. Давайте откроем SQL Server Management Studio и создадим простую базу данных и таблицу. Щелкните правой кнопкой мыши базы данных и выберите « Новая база данных» .

Шаг 2 — Назовите его как Demodb и нажмите OK

Шаг 3 — В новой базе данных щелкните правой кнопкой мыши и создайте новую таблицу.

Шаг 4 — Вы можете добавить нужные столбцы в таблицу.

Шаг 5 — Сохраните таблицу и назовите ее как Demotb .

Шаг 6 — Теперь щелкните правой кнопкой мыши по таблице и выберите пункт меню « Таблица сценариев», как → Удалить и Создать в → Файл .

Шаг 7 — Сохраните файл в папке демонстрационного проекта как Sample.sql .

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

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Шаг 8 — Теперь давайте быстро изменим наш код ASP.Net для ссылки на новую базу данных.

Шаг 9 — В файле Tutorial.cs в вашем демонстрационном проекте добавьте следующие строки кода. Эти строки кода подключатся к вашей базе данных, возьмут версию Сервера и сохранят имя версии в переменной Name. Мы можем отобразить эту переменную Name в нашем файле Demo.aspx.cs с помощью команды Response.write .

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Шаг 10. Добавьте следующий код в файл Demo.aspx.cs, чтобы убедиться, что он отображает версию SQL Server.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Теперь, если мы запустим код, вы получите следующий вывод в браузере.

Шаг 11 — Теперь давайте добавим наш шаг в TeamCity, который вызовет скрипт базы данных. Перейдите на панель управления проектом и нажмите « Изменить настройки конфигурации» .

Шаг 12 — Перейдите к шагу сборки и нажмите Добавить шаг сборки .

Выберите следующие параметры (обратите внимание, что клиент MS SQL Server должен быть установлен на сервере CI).

• Тип бегуна должен быть Командная строка.

• Укажите необязательное имя шага.

• Run должен быть исполняемым с параметрами.

• Исполняемый файл команды должен быть C: \ Program Files \ Microsoft SQL Server \ 110 \ Tools \ Binn \ sqlcmd.exe

• Параметры команды должны быть -S WIN-50GP30FGO75 -i Sample.sql . Где –S — имя экземпляра SQL Server.

Тип бегуна должен быть Командная строка.

Укажите необязательное имя шага.

Run должен быть исполняемым с параметрами.

Исполняемый файл команды должен быть C: \ Program Files \ Microsoft SQL Server \ 110 \ Tools \ Binn \ sqlcmd.exe

Параметры команды должны быть -S WIN-50GP30FGO75 -i Sample.sql . Где –S — имя экземпляра SQL Server.

Шаг 13 — Нажмите Сохранить.

Теперь необходимо обеспечить порядок сборки. Вы должны убедиться, что порядок сборки следующий.

Шаг 14 — Вы можете изменить порядок сборки, выбрав опцию для изменения порядка сборки.

• Настройка базы данных должна быть первой — поэтому она будет использоваться для восстановления вашей базы данных из свежих.

• Далее идет сборка вашего приложения.

• Наконец ваша тестовая настройка.

Настройка базы данных должна быть первой — поэтому она будет использоваться для восстановления вашей базы данных из свежих.

Далее идет сборка вашего приложения.

Наконец ваша тестовая настройка.

Шаг 15. Теперь запустите команды git add и git commit, чтобы файл Sample.sql был зарегистрирован в Git. Это запустит сборку автоматически. И эта сборка должна пройти.

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

Теперь, когда вы сделали это с локальным SQL Server, мы можем повторить те же шаги для AWS MS SQL Server, который был создан в одном из предыдущих разделов. Чтобы подключиться к Microsoft SQL Server, вам необходимо подключиться по следующему соглашению.

Шаг 16. Сначала посмотрите, какое имя присвоено экземпляру вашей базы данных в AWS. После входа в AWS перейдите в раздел RDS в разделе базы данных.

Шаг 17 — Нажмите на Экземпляры БД на следующем экране, который появляется.

Шаг 18 — Нажмите на вашу базу данных и запишите конечную точку. На следующем скриншоте это demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Шаг 19. Теперь для подключения к базе данных из SQL Server Management Studio необходимо указать соединение как demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com, 1433 (обратите внимание на запятую, используемую между именем экземпляра и номером порта. ).

На следующем снимке экрана показано успешное подключение к базе данных.

Тогда вы можете повторить все те же шаги. Команда Sqlcmd будет выглядеть следующим образом:

Эту же команду можно заменить на этапе построения базы данных в TeamCity. Когда вы выполните команду sqlcmd , таблица будет автоматически создана в вашей базе данных SQL Server в AWS.

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

Автоматизированные сборки и повторяемые сборки. Автоматизированные тесты и повторяемые тесты. Тестовые категории и тестовые частоты. Непрерывные проверки. Непрерывная интеграция с базой данных. Эта цепочка задач при создании эффективной среды CI в первую очередь дает одно ключевое преимущество: выпуск работающего программного обеспечения в любой момент времени и в любой среде.

В наших предыдущих главах мы выполнили все следующие этапы —

• Создан наш код.
• Обеспечил правильную сборку в TeamCity.
• Создан процесс интеграции базы данных.
• Проведено успешное тестирование.

Теперь осталось только выполнить автоматическое развертывание, чтобы завершить весь наш процесс.

Для автоматического развертывания в нашем случае нам необходимо выполнить следующие шаги:

• На нашем сервере развертывания убедитесь, что IIS установлен.

• Убедитесь, что пользователю IIS предоставлен доступ к нашей базе данных.

• Создайте профиль публикации, который будет использоваться для публикации сайта при его создании.

• Убедитесь, что мы изменили нашу команду MSBuild для автоматического развертывания.

• Автоматизируйте TeamCity для автоматической публикации.

• Сделайте git commit, чтобы убедиться, что все ваши файлы находятся в Git.

На нашем сервере развертывания убедитесь, что IIS установлен.

Убедитесь, что пользователю IIS предоставлен доступ к нашей базе данных.

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

Убедитесь, что мы изменили нашу команду MSBuild для автоматического развертывания.

Автоматизируйте TeamCity для автоматической публикации.

Сделайте git commit, чтобы убедиться, что все ваши файлы находятся в Git.

Шаг 1. Настройте локальный сервер IIS. Если у вас есть локальный или удаленный сервер IIS, для развертывания нашего приложения можно выполнить следующую настройку. Всегда полезно посмотреть, можно ли выполнить развертывание вручную, прежде чем оно будет выполнено в автоматическом режиме.

Шаг 2. На сервере Windows 2012 перейдите в диспетчер серверов и нажмите «Добавить роли и компоненты».

Шаг 3 — Нажмите Далее на следующем появившемся экране.

Шаг 4 — Выберите установку на основе ролей или функций на следующем экране и нажмите Далее.

Шаг 5 — Выберите сервер по умолчанию и нажмите Далее.

Шаг 6 — Выберите роль веб-сервера и нажмите Далее.

Шаг 7 — На следующем появившемся экране нажмите Далее.

Шаг 8 — Нажмите Next еще раз на следующем экране, который появляется.

Шаг 9 — На следующем всплывающем экране нажмите Далее.

Шаг 10 — На последнем экране вы можете нажать кнопку Установить, чтобы установить IIS.

После установки IIS вы можете открыть его, открыв Информационные службы Интернета.

Шаг 11 — Нажмите Application Pools, вы увидите пул с именем DefaultAppPool . Это должно иметь доступ к SQL Server на следующем шаге.

Шаг 12. Если нам нужно подключить приложение ASP.Net к приложению MS SQL Server, мы должны предоставить доступ к пулу приложений по умолчанию для экземпляра SQL Server, чтобы он мог подключаться к нашей базе данных Demodb .

Шаг 13 — Откройте SQL Server Management Studio. Перейдите в раздел « Вход», щелкните правой кнопкой мыши и выберите пункт меню « Новый вход» .

На следующем экране обновите следующие параметры и нажмите OK.

• Имя входа как IIS APPPOOL \ DefaultAppPool.
• База данных по умолчанию — это должна быть наша база данных, которая является demodb.

Шаг 14 — Создание профиля публикации . Профиль публикации используется в Visual Studio для создания пакета развертывания, который затем можно использовать с MS Build и на любом CI Server соответственно. Для этого в Visual Studio щелкните правой кнопкой мыши проект и выберите пункт меню «Опубликовать».

Шаг 15 — На следующем появившемся экране выберите создание нового профиля публикации, дайте ему имя — DemoDeployment . Затем нажмите кнопку «Далее».

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

• Выберите метод публикации как веб-развертывание.
• Введите сервер как локальный хост.
• Введите имя сайта в качестве веб-сайта по умолчанию / демо.
• Введите URL-адрес назначения как http: // localhost / Demo

Затем нажмите кнопку «Далее».

Шаг 16 — На следующем экране нажмите Далее.

Шаг 17 — На последнем появившемся экране нажмите кнопку «Опубликовать».

Теперь, если вы перейдете в папку C: \ Demo \ Simple \ Properties \ PublishProfiles вашего проекта, вы увидите созданный новый XML-файл профиля публикации . Этот файл профиля публикации будет содержать все детали, необходимые для публикации вашего приложения на локальном сервере IIS.

Шаг 18. Теперь давайте настроим нашу команду MSBuild и воспользуемся приведенным выше профилем публикации и посмотрим, что произойдет. В нашей команде MSBuild мы указываем следующие параметры —

• Развертывание при сборке — это правда — это будет запускать автоматическое развертывание после успешной сборки.

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

• Версия Visual Studio должна быть упомянута только для возможности развертывания MSBuild в используемой версии Visual Studio.

Развертывание при сборке — это правда — это будет запускать автоматическое развертывание после успешной сборки.

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

Версия Visual Studio должна быть упомянута только для возможности развертывания MSBuild в используемой версии Visual Studio.

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

Теперь, если мы перейдем на сайт — http: //localhost/Demo/Demo.aspx, мы увидим следующий вывод, который означает, что MSBuild успешно выполнил развертывание на нашем сайте.

Шаг 19 — Автоматизация через TeamCity. Теперь пришло время добавить задачу на наш сервер TeamCity, чтобы автоматически использовать MSBuild для развертывания нашего приложения на основе вышеупомянутых шагов.

Шаг 20 — Перейдите на панель управления проектом и нажмите « Изменить настройки конфигурации» .

Шаг 21 — Перейдите к Шаги сборки и нажмите Добавить шаг сборки.

Выберите следующие параметры —

• Тип бегуна должен быть MSBuild

• Дайте необязательное имя шага

• Введите путь сборки как Simple / Simple.csproj

• Сохраните версию MSBuild как Microsoft Build Tools 2013

• Оставьте версию MSBuild Tools 12.0

• Поместите командную строку как / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Тип бегуна должен быть MSBuild

Дайте необязательное имя шага

Введите путь сборки как Simple / Simple.csproj

Сохраните версию MSBuild как Microsoft Build Tools 2013

Оставьте версию MSBuild Tools 12.0

Поместите командную строку как / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Шаг 22 — Нажмите Сохранить.

Убедитесь, что на этапах сборки этап развертывания является последним этапом в цепочке.

Шаг 23 — Теперь давайте сделаем заключительный коммит git , чтобы убедиться, что все файлы находятся в Git и могут использоваться TeamCity.

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

Непрерывная интеграция — лучшие практики

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

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

Автоматизация сборки. Мы увидели, как использовать MSBuild для автоматизации сборки вместе с использованием профиля публикации. Это снова ключевой шаг в процессе непрерывной интеграции.

Выполните самотестирование сборки. Убедитесь, что вы можете протестировать сборку, сохранив контрольные примеры на месте, и эти контрольные примеры должны выполняться таким образом, чтобы он мог выполняться сервером Continuous Integration.

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

Каждый коммит (до базового уровня) должен быть построен — каждый коммит, сделанный в приложении, должен быть успешно собран. Если сборка завершается неудачей по какой-либо причине, необходимо изменить код, чтобы обеспечить успешную сборку.

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

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