Непрерывная интеграция - краткое руководство
Непрерывная интеграция была впервые представлена в 2000 году с помощью программного обеспечения, известного как Cruise Control. С годами непрерывная интеграция стала ключевой практикой в любой программной организации. Это практика разработки, при которой команды разработчиков должны гарантировать, что сборка и последующее тестирование проводятся для каждого изменения кода, внесенного в программу. Эта концепция была предназначена для устранения проблемы обнаружения поздних возникновений проблем в жизненном цикле сборки. Вместо того, чтобы разработчики работали изолированно и недостаточно интегрировались, была введена непрерывная интеграция, чтобы гарантировать, что изменения кода и сборки никогда не будут выполняться изолированно.
Почему непрерывная интеграция?
Непрерывная интеграция стала неотъемлемой частью любого процесса разработки программного обеспечения. Непрерывный процесс интеграции помогает ответить на следующие вопросы команде разработчиков программного обеспечения.
Все ли программные компоненты работают вместе, как должны? - Иногда системы могут стать настолько сложными, что для каждого компонента будет несколько интерфейсов. В таких случаях всегда важно обеспечить бесперебойную работу всех программных компонентов друг с другом.
Код слишком сложен для интеграции? - Если процесс непрерывной интеграции продолжает давать сбой, может быть, что код слишком сложен. И это может быть сигналом к применению правильных шаблонов проектирования, чтобы сделать код менее сложным и более удобным в обслуживании.
Соответствует ли код установленным стандартам кодирования? - Большинство тестовых примеров всегда проверяют, соответствует ли код надлежащим стандартам кодирования. Выполняя автоматический тест после автоматизированной сборки, это хороший момент, чтобы проверить, соответствует ли код всем желаемым стандартам кодирования.
Сколько кода покрывают автоматизированные тесты? - Нет смысла тестировать код, если тестовые примеры не охватывают требуемую функциональность кода. Поэтому всегда рекомендуется гарантировать, что написанные тестовые примеры должны охватывать все ключевые сценарии приложения.
Все ли тесты прошли успешно после последнего изменения? - Если тест не прошел, тогда нет смысла продолжать развертывание кода, поэтому это хороший момент, чтобы проверить, готов ли код перейти к этапу развертывания или нет.
Рабочий процесс
На следующем изображении показан быстрый рабочий процесс того, как весь рабочий процесс непрерывной интеграции работает в любом проекте разработки программного обеспечения. Мы рассмотрим это подробно в следующих главах.
Итак, исходя из приведенного выше рабочего процесса, обычно так и работает процесс непрерывной интеграции.
Сначала разработчик фиксирует код в репозитории контроля версий. Между тем, сервер непрерывной интеграции на машине сборки интеграции опрашивает репозиторий исходного кода на предмет изменений (например, каждые несколько минут).
Вскоре после совершения фиксации сервер непрерывной интеграции обнаруживает, что в репозитории контроля версий произошли изменения, поэтому сервер непрерывной интеграции извлекает последнюю копию кода из репозитория и затем выполняет сценарий сборки, который интегрирует программное обеспечение.
Сервер непрерывной интеграции формирует обратную связь, отправляя результаты сборки по электронной почте указанным участникам проекта.
Затем выполняются модульные тесты, если сборка этого проекта проходит. Если тесты пройдены успешно, код готов к развертыванию на промежуточном или производственном сервере.
Сервер непрерывной интеграции продолжает опрашивать изменения в репозитории контроля версий, и весь процесс повторяется.
Программная часть - самый важный аспект любого процесса непрерывной интеграции. В этой главе основное внимание уделяется программному обеспечению, которое потребуется для всего процесса непрерывной интеграции.
Репозиторий исходного кода
Репозиторий исходного кода используется для поддержки всего исходного кода и всех внесенных в него изменений. Двумя наиболее популярными для управления репозиториями исходного кода являются Subversion и Git, причем Git является самой последней популярной системой. Теперь мы посмотрим, как установить Git в системе.
Системные Требования
| объем памяти | 2 ГБ ОЗУ (рекомендуется) |
| Дисковое пространство | HDD 200 Мб для установки. Для хранения исходного кода проекта требуется дополнительное хранилище, и это зависит от добавляемого исходного кода. |
| Версия операционной системы | Может быть установлен в Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X. |
Установка Git
Step 1 - Официальный сайт Git: https://git-scm.com/. Если вы нажмете на ссылку, вы попадете на домашнюю страницу официального сайта Git, как показано на следующем снимке экрана.
Step 2 - Чтобы загрузить Git, просто прокрутите экран вниз, перейдите в раздел «Загрузки» и нажмите «Загрузки».
Step 3 - Щелкните ссылку Windows, и загрузка Git начнется автоматически.
Step 4- Щелкните загруженный файл .exe для Git. В нашем случае мы используем файл Git-2.6.1-64-bit.exe. Нажмите «Выполнить», который появится на следующем экране.
Step 5 - Нажмите кнопку «Далее», которая появится на следующем экране.
Step 6 - Нажмите «Далее» на следующем экране, чтобы принять Генеральное лицензионное соглашение.
Step 7 - Выберите место для установки Git.
Step 8 - Нажмите Далее, чтобы принять компоненты по умолчанию, которые необходимо установить.
Step 9 - Выберите вариант «Использовать Git из командной строки Windows», поскольку мы собираемся использовать Git из Windows.
Step 10 - На следующем экране примите настройку по умолчанию «Оформить заказ в стиле Windows, зафиксировать окончания строк в стиле Unix» и нажмите «Далее».
Step 11 - На следующем экране выберите вариант «Использовать окно консоли Windows по умолчанию», поскольку мы используем Windows в качестве системы для установки Git.
Теперь начнется установка, и после ее завершения можно будет выполнить следующие шаги для настройки Git.
Настройка Git
После установки Git необходимо выполнить шаги настройки для начальной настройки Git.
Первое, что нужно сделать, это настроить идентификацию в Git, а затем настроить имя пользователя и адрес электронной почты. Это важно, потому что каждыйGit commitиспользует эту информацию, и она неизменно встраивается в коммиты, которые вы начинаете создавать. Это можно сделать, открыв командную строку, а затем введите следующие команды:
git config –global user.name “Username”
git config –global user.email “emailid”Следующий снимок экрана является примером для лучшего понимания.
Эти команды фактически изменят файл конфигурации Git соответственно. Чтобы убедиться, что ваши настройки вступили в силу, вы можете перечислить настройки файла конфигурации Git, выполнив следующую команду.
git config --listПример вывода показан на следующем снимке экрана.
Сервер непрерывной интеграции
Следующее важное программное обеспечение, необходимое для всего конвейера непрерывной интеграции, - это само программное обеспечение непрерывной интеграции. Ниже приведены наиболее часто используемые программы непрерывной интеграции, используемые в отрасли.
Jenkins- Это программное обеспечение для непрерывной интеграции с открытым исходным кодом, которое используется многими сообществами разработчиков.
Jet Brains TeamCity - Это одно из самых популярных доступных коммерческих программ непрерывной интеграции, и большинство компаний используют его для своих нужд в непрерывной интеграции.
Atlassian Bamboo- Это еще одно популярное программное обеспечение для непрерывной интеграции, предоставляемое компанией Atlassian Pvt. ООО
Все упомянутые выше программы работают по одной и той же модели непрерывной интеграции. В рамках этого урока мы рассмотримJetbrains TeamCity для сервера непрерывной интеграции.
Установка TeamCity
Ниже приведены шаги и системные требования для установки Jet Brains TeamCity на ваш компьютер.
Системные Требования
| объем памяти | 4 ГБ ОЗУ (рекомендуется) |
| Дисковое пространство | 1 ГБ HDD для установки. Дополнительное хранилище требуется для хранения рабочей области сборки для каждого проекта. |
| Версия операционной системы | Устанавливается на Windows, Linux, Mac OS X. |
Установка
Step 1 - Официальный сайт TeamCity:https://www.jetbrains.com/teamcity/. Если вы нажмете данную ссылку, вы перейдете на домашнюю страницу официального сайта TeamCity, как показано на следующем снимке экрана. Вы можете просмотреть страницу, чтобы загрузить необходимое программное обеспечение для TeamCity.
Step 2 - Загруженный .exe используется для выполнения TeamCity-9.1.6.exe. Дважды щелкните исполняемый файл, а затем нажмите «Выполнить» на следующем всплывающем экране.
Step 3 - Щелкните Далее, чтобы начать настройку.
Step 4 - Нажмите кнопку «Я согласен», чтобы принять лицензионное соглашение и продолжить установку.
Step 5 - Выберите место для установки и нажмите Далее.
Step 6 - Выберите компоненты по умолчанию для установки и нажмите Далее.
Это запустит процесс установки. После завершения последует процесс настройки.
Step 7- Выберите номер порта для запуска сервера. Лучше всего использовать другой порт, например8080.
Step 8- Затем он спросит, под какой учетной записью TeamCity нужно запускать. Выберите системную учетную запись и нажмите Далее.
Step 9- Далее он запросит службы, которые необходимо запустить. Примите значения по умолчанию и нажмите Далее.
Настройка TeamCity
После завершения установки следующим шагом будет настройка TeamCity. Это программное обеспечение можно открыть, перейдя по следующему URL-адресу в браузере -
http://locahost:8080
Step 1- Первый шаг - указать местоположение сборок, которые будет выполнять TeamCity. Выберите желаемое место и нажмите кнопку «Продолжить».
Step 2- Следующим шагом является указание базы данных для хранения всех артефактов TeamCity. Для целей учебника можно выбратьInternal (HSQLDB), которая представляет собой внутреннюю базу данных, которая лучше всего подходит при использовании продуктов в целях тестирования.
Затем TeamCity обработает все необходимые шаги для его запуска и запуска.
Step 3- Далее вам будет предложено принять лицензионное соглашение. Примите то же самое и нажмите «Продолжить».
Step 4- Вам необходимо создать учетную запись администратора, которая будет использоваться для входа в программное обеспечение TeamCity. Введите необходимые данные и нажмите кнопку «Создать учетную запись».
Теперь вы войдете в TeamCity.
Инструмент сборки
Инструмент «Сборка» - это инструмент, который гарантирует, что программа построена определенным образом. Инструмент обычно выполняет список задач, которые требуются для правильного построения программы. Поскольку в нашем примере мы будем смотреть на.Net program , мы будем смотреть на 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. Для этого нам нужно убедиться, что на месте присутствуют следующие артефакты.
Сервер базы данных
Выполните следующие шаги, чтобы убедиться, что сервер базы данных находится в Amazon для развертывания.
Step 1 - Перейдите в консоль Amazon - https://aws.amazon.com/console/.
Войдите с вашими учетными данными. Обратите внимание, что вы можете подать заявку на получение бесплатного идентификатора на сайте Amazon, что позволит вам иметь уровень бесплатного пользования, который позволяет бесплатно использовать некоторые ресурсы на Amazon.
Step 2 - Перейдите в раздел RDS, чтобы создать свою базу данных.
Step 3 - Щелкните Экземпляры на следующем всплывающем экране.
Step 4 - Щелкните значок Launch DB вариант на следующем экране, который появляется.
Step 5 - Выберите вкладку SQL Server, а затем выберите параметр Выбрать для SQL Server Express.
Step 6 - Убедитесь, что введены следующие данные, чтобы подтвердить, что вы используете бесплатный уровень баз данных, доступный от Amazon.
Step 7 - Нажмите кнопку «Следующий шаг» после заполнения всех полей.
Step 8 - На следующем появившемся экране примите все настройки по умолчанию и нажмите Launch DB Instance.
Step 9- Затем вам будет представлен экран, на котором говорится, что БД успешно запускается. На этой же странице будет кнопка для просмотра инстанса БД. Щелкните ссылку, чтобы увидеть свойDB Instance настраивается.
Через некоторое время статус экрана, показанного выше, изменится, чтобы уведомить об успешном создании инстанса БД.
Веб сервер
Следующим шагом будет создание вашего веб-сервера на Amazon, на котором будет размещено веб-приложение. Это можно сделать, выполнив следующие шаги.
Step 1 - Перейдите в консоль Amazon - https://aws.amazon.com/console/.
Войдите с вашими учетными данными. Обратите внимание, что вы можете подать заявку наfree id on the Amazon site, что позволит вам получить уровень бесплатного пользования, позволяющий бесплатно использовать некоторые ресурсы Amazon.
Step 2 - Зайдите в EC2 section для создания вашего веб-сервера.
Step 3 - На следующем экране нажмите «Запустить экземпляр».
Step 4 - Щелкните Windows - Microsoft Windows Server 2010 R2 Base.
Step 5 - Выберите t2.microопция, которая является частью бесплатного уровня. НажмитеNext: Configure Instance Details.
Step 6 - Примите настройки по умолчанию на следующем экране, который появится, а затем выберите вариант Next: Add Storage.
Step 7 - Примите настройки по умолчанию на следующем экране и выберите вариант Next: Tag Instance.
Step 8 - Примите настройки по умолчанию на следующем экране и выберите вариант Next: Configure Security Group.
Step 9 - Примите настройки по умолчанию на следующем экране и выберите вариант Review and Launch.
Step 10 - Нажмите «Запуск» на следующем появившемся экране.
Step 11- На следующем появившемся экране вам будет предложено создать пару ключей. Это будет использоваться для входа на сервер позже. Просто создайте пару ключей и нажмитеLaunch Instance.
Теперь экземпляр будет настроен в Amazon.
Есть вероятность, что в проекте что-то пойдет не так. Эффективно практикуя CI, вы узнаете, что происходит на каждом этапе пути, а не позже, когда проект входит в цикл разработки. CI помогает выявлять и снижать риски, когда они возникают, облегчая оценку и составление отчетов о состоянии проекта на основе конкретных данных.
В этом разделе мы сосредоточимся на рисках, которых можно избежать с помощью непрерывной интеграции.
В любом проекте существует множество рисков, которыми необходимо управлять. Устранение рисков на ранних этапах жизненного цикла разработки снижает вероятность того, что эти риски перерастут в проблемы позже, когда система действительно будет запущена.
Риск 1 - Отсутствие развертываемого программного обеспечения
“It works on my machine but does not work on another”- Это, наверное, одна из самых распространенных фраз, встречающихся в любой программной организации. Из-за большого количества изменений, вносимых в сборки программного обеспечения на ежедневной основе, иногда нет уверенности в том, действительно ли сборка программного обеспечения работает или нет. Эта проблема имеет следующие три побочных эффекта.
Мало или нет уверенности в том, сможем ли мы создать программное обеспечение.
Длительные этапы интеграции перед поставкой программного обеспечения внутри компании (т. Е. Группа тестирования) или извне (т. Е. Заказчик), в течение которых больше ничего не делается.
Невозможность создавать и воспроизводить тестируемые сборки.
Решение
Устранение тесной связи между IDE и процессами сборки. Используйте отдельный компьютер исключительно для интеграции программного обеспечения. Убедитесь, что все, что вам нужно для сборки программного обеспечения, содержится в репозитории контроля версий. Наконец, создайте систему непрерывной интеграции.
Сервер непрерывной интеграции может отслеживать изменения в репозитории управления версиями и запускать сценарий сборки проекта, когда он обнаруживает изменение в репозитории. Возможности системы непрерывной интеграции можно расширить, включив в нее запуск сборки посредством тестов, выполнение проверок и развертывание программного обеспечения в средах разработки и тестирования; таким образом у вас всегда будет работающее программное обеспечение.
“Inability to synchronize with the database”- Иногда разработчики не могут быстро воссоздать базу данных во время разработки, и поэтому им сложно вносить изменения. Часто это происходит из-за разделения между командой базы данных и командой разработчиков. Каждая команда будет сосредоточена на своих обязанностях и будет мало сотрудничать друг с другом. Эта проблема имеет следующие три побочных эффекта:
Страх внесения изменений или рефакторинга базы данных или исходного кода.
Сложность заполнения базы данных разными наборами тестовых данных.
Сложность в поддержке сред разработки и тестирования (например, разработки, интеграции, контроля качества и тестирования).
Решение
Решение вышеуказанной проблемы состоит в том, чтобы обеспечить размещение всех артефактов базы данных в репозитории управления версиями. Это означает, что все, что требуется для воссоздания схемы и данных базы данных: сценарии создания базы данных, сценарии манипулирования данными, хранимые процедуры, триггеры и любые другие активы базы данных.
Восстановите базу данных и данные из сценария сборки, удалив и воссоздав базу данных и таблицы. Затем примените хранимые процедуры и триггеры и, наконец, вставьте тестовые данные.
Протестируйте (и проверьте) свою базу данных. Как правило, вы будете использовать тесты компонентов для тестирования базы данных и данных. В некоторых случаях вам нужно будет написать тесты для конкретной базы данных.
Риск 2 - обнаружение дефектов на поздних этапах жизненного цикла
Поскольку в исходный код часто вносятся изменения несколькими разработчиками, всегда есть вероятность, что в код может быть внесен дефект, который может быть обнаружен только на более позднем этапе. В таких случаях это может иметь большое влияние, поскольку чем позже дефект будет обнаружен в программном обеспечении, тем дороже становится его устранение.
Решение
Regression Testing- Это самый важный аспект любого цикла разработки программного обеспечения, тестирования и еще раз тестирования. Если есть какие-либо серьезные изменения в программном коде, абсолютно необходимо обеспечить выполнение всех тестов. И это можно автоматизировать с помощью сервера непрерывной интеграции.
Test Coverage- Нет смысла тестировать, если тестовые примеры не охватывают всю функциональность кода. Важно убедиться, что тестовые наборы, созданные для тестирования приложения, полны и все пути кода проверены.
Например, если у вас есть экран входа в систему, который необходимо протестировать, у вас просто не может быть тестового примера со сценарием успешного входа в систему. У вас должен быть отрицательный тестовый пример, когда пользователь вводит другую комбинацию имен пользователей и паролей, а затем требуется увидеть, что происходит в таких сценариях.
Риск 3 - Недостаточная прозрачность проекта
Механизмы ручной коммуникации требуют тщательной координации, чтобы обеспечить своевременное распространение проектной информации среди нужных людей. Наклоняться к разработчику рядом с вами и сообщать ему, что последняя сборка находится на общем диске, довольно эффективно, но не очень хорошо масштабируется.
Что делать, если есть другие разработчики, которым нужна эта информация, но у них перерыв или они недоступны по другим причинам? Если сервер выходит из строя, как вы уведомляетесь? Некоторые считают, что могут снизить этот риск, отправив электронное письмо вручную. Однако это не может гарантировать, что информация будет передана нужным людям в нужное время, потому что вы можете случайно пропустить заинтересованные стороны, а некоторые могут не иметь доступа к своей электронной почте в это время.
Решение
Решением этой проблемы снова является сервер непрерывной интеграции. Все серверы CI имеют возможность иметь автоматические электронные письма, которые будут запускаться при сбое сборки. Это автоматическое уведомление всех ключевых заинтересованных сторон также гарантирует, что все знают о текущем состоянии программного обеспечения.
Риск 4 - Программное обеспечение низкого качества
Есть дефекты, а есть потенциальные дефекты. У вас могут быть потенциальные дефекты, если ваше программное обеспечение плохо спроектировано, не соответствует стандартам проекта или является сложным в обслуживании. Иногда люди называют это запахом кода или дизайна - «признаком того, что что-то не так».
Некоторые считают, что некачественное программное обеспечение - это исключительно отсроченная стоимость проекта (после поставки). Это может быть отложенная стоимость проекта, но это также приводит ко многим другим проблемам, прежде чем вы доставляете программное обеспечение пользователям. Чрезмерно сложный код, код, не соответствующий архитектуре, и дублированный код - все это обычно приводит к дефектам в программном обеспечении. Обнаружение этих запахов кода и дизайна до того, как они проявятся в дефектах, может сэкономить время и деньги и может привести к созданию более качественного программного обеспечения.
Решение
Существуют программные компоненты для проверки качества кода, которые можно интегрировать с программным обеспечением CI. Это можно запустить после того, как код будет построен, чтобы убедиться, что код действительно соответствует правильным правилам кодирования.
Системы контроля версий, также известные как системы контроля версий, системы управления исходным кодом или системы контроля версий, представляют собой механизм для хранения нескольких версий ваших файлов, так что при изменении файла вы все равно можете получить доступ к предыдущим версиям.
Первой популярной системой контроля версий был проприетарный инструмент UNIX под названием SCCS(Система контроля исходного кода), которая восходит к 1970-м годам. Это было замененоRCS, Система контроля версий и более поздние версии CVS, Система одновременных версий.
В настоящее время наиболее популярными системами контроля версий являются Subversion и Git. Давайте сначала посмотрим, почему нам нужно использовать систему управления версиями, а затем давайте посмотрим, как поместить наш исходный код вGit source code repository system.
Назначение системы контроля версий
Одна из причин, по которой мы используем термин контроль версий вместо контроля версий, заключается в том, что контроль версий применяется не только для исходного кода. Каждый артефакт, связанный с созданием вашего программного обеспечения, должен находиться под контролем версий.
Developers should use it for source code - По умолчанию весь исходный код должен храниться в системе контроля версий.
Related artefacts- Каждая система будет иметь связанные с исходным кодом артефакты, такие как сценарии базы данных, сценарии сборки и развертывания, документация, библиотеки и файлы конфигурации для вашего приложения, вашего компилятора и набора инструментов и т. Д. Все это дополняет весь процесс разработки и развертывания, а также должно храниться в системе управления версиями.
Сохранение всей информации для приложения в системе управления версиями упрощает воссоздание тестовой и производственной среды, в которой работает ваше приложение. Это должно включать информацию о конфигурации для стека программного обеспечения вашего приложения и операционных систем, составляющих среду, файлы зоны DNS, конфигурацию межсетевого экрана и т. Д.
Как минимум, вам понадобится все необходимое для воссоздания двоичных файлов вашего приложения и сред, в которых они работают. Задача состоит в том, чтобы все, что может измениться в любой момент жизненного цикла проекта, хранилось под контролем. Это позволяет восстановить точный снимок состояния всей системы, от среды разработки до производственной среды, в любой момент истории проекта.
Полезно даже хранить файлы конфигурации для сред разработки группы разработчиков в системе контроля версий, так как это позволяет всем членам команды использовать одни и те же параметры. Аналитики должны хранить документы с требованиями. Тестировщики должны держать свои тестовые сценарии и процедуры в системе контроля версий. Руководители проектов должны сохранять здесь свои планы релизов, графики выполнения и журналы рисков.
Короче говоря, каждый член команды должен хранить любой документ или файл, связанный с проектом, в системе контроля версий.
Работа с Git для системы контроля версий исходного кода
В этом разделе мы сосредоточимся на том, как Git можно использовать в качестве системы управления версиями. Он будет сосредоточен на том, как вы можете загрузить свой код в систему контроля версий и управлять изменениями в ней.
Наше демонстрационное приложение
Для целей этого урока мы рассмотрим простой Web ASP.Netприложение, которое будет использоваться для всего процесса непрерывной интеграции. В этом упражнении нам не нужно сосредотачиваться на всех деталях кода, просто обзора того, что делает проект, достаточно для понимания всего процесса непрерывной интеграции. Это приложение .Net было построено с использованиемVisual Studio Integrated Development Environment.
На следующем снимке экрана представлена структура решения в среде 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.
Step 1 - Инициализировать Git Repository. Перейдите в командную строку, перейдите в папку своего проекта и введите командуgit init. Эта команда добавит необходимые файлы Git в папку проекта, чтобы Git мог их распознать при загрузке в репозиторий.
Step 2- Добавление ваших файлов, которые необходимо добавить в репозиторий Git. Это можно сделать, выполнивgit add command. Параметр точка сообщает Git, что все файлы в папке проекта необходимо добавить в репозиторий Git.
Step 3- Последний шаг - зафиксировать файлы проекта в репозитории Git. Этот шаг необходим, чтобы убедиться, что все файлы теперь являются частью Git. Выполняемая команда представлена на следующем снимке экрана. В–m option это комментарий к загрузке файлов.
Ваше решение теперь доступно в Git.
Ниже приведены некоторые из основных функций или практик непрерывной интеграции.
Maintain a single source repository- Весь исходный код хранится в едином репозитории. Это позволяет избежать разброса исходного кода по разным адресам. Такие инструменты какSubversion and Git являются наиболее популярными инструментами для поддержки исходного кода.
Automate the build- Сборка программного обеспечения должна выполняться таким образом, чтобы ее можно было автоматизировать. Если необходимо выполнить несколько шагов, инструмент сборки должен уметь это делать. Для .Net MSBuild является инструментом сборки по умолчанию, а для приложений на основе Java у вас есть такие инструменты, какMaven and Grunt.
Make your build self-testing- Сборка должна быть тестируемой. Сразу после сборки следует запустить тестовые примеры, чтобы убедиться, что можно провести тестирование различных функций программного обеспечения.
Every commit should build on an integration machine- Машина интеграции является сервером сборки, и необходимо убедиться, что сборка выполняется на этой машине. Это означает, что все зависимые компоненты должны существовать на сервере непрерывной интеграции.
Keep the build fast- Сборка должна произойти за считанные минуты. Сборка не должна занимать часы, потому что это будет означать, что шаги сборки не настроены должным образом.
Test in a clone of the production environment- Среда сборки должна быть по своей природе близкой к производственной среде. Если между этими средами есть огромные различия, то может быть случай, когда сборка может завершиться неудачно в производственной среде, даже если она передается на сервер сборки.
Everyone can see what is happening - Весь процесс сборки, тестирования и развертывания должен быть виден всем.
Automate deployment- Непрерывная интеграция ведет к непрерывному развертыванию. Абсолютно необходимо убедиться, что сборку можно легко развернуть в промежуточной или производственной среде.
Ниже приводится список наиболее важных требований для непрерывной интеграции.
Check-In Regularly- Самая важная практика для правильной работы непрерывной интеграции - это частые проверки в основной или основной ветке репозитория исходного кода. Проверка кода должна происходить не реже двух раз в день. Регулярная проверка приносит много других преимуществ. Это уменьшает количество изменений и, следовательно, снижает вероятность поломки сборки. Это означает, что самая последняя версия программного обеспечения, к которой нужно вернуться, известна, когда в любой последующей сборке была сделана ошибка.
Это также помогает быть более дисциплинированным в отношении рефакторинга кода и придерживаться небольших изменений, которые сохраняют поведение. Это помогает гарантировать, что изменения, изменяющие множество файлов, с меньшей вероятностью будут конфликтовать с работой других людей. Это позволяет разработчикам быть более исследовательными, пробовать идеи и отбрасывать их, возвращаясь к последней совершенной версии.
Create a Comprehensive Automated Test Suite- Если у вас нет полного набора автоматических тестов, проходящая сборка означает только то, что приложение можно скомпилировать и собрать. Хотя для некоторых команд это большой шаг, важно иметь некоторый уровень автоматизированного тестирования, чтобы убедиться, что ваше приложение действительно работает.
Обычно в непрерывной интеграции проводятся 3 типа тестов, а именно: unit tests, component tests, и acceptance tests.
Модульные тесты написаны для тестирования поведения небольших частей вашего приложения по отдельности. Обычно их можно запустить, не запуская все приложение. Они не попадают в базу данных (если она есть в вашем приложении), файловую систему или сеть. Они не требуют, чтобы ваше приложение работало в производственной среде. Модульные тесты должны выполняться очень быстро - весь ваш пакет, даже для большого приложения, должен работать менее чем за десять минут.
Компонентные тесты проверяют поведение нескольких компонентов вашего приложения. Как и модульные тесты, они не всегда требуют запуска всего приложения. Однако они могут попасть в базу данных, файловую систему или другие системы (которые могут быть отключены). Тесты компонентов обычно занимают больше времени.
Keep the Build and Test Process Short - Если сборка кода и запуск модульных тестов занимает слишком много времени, вы столкнетесь со следующими проблемами.
Люди перестанут делать полную сборку и будут запускать тесты до того, как отметятся. Вы начнете получать больше неудачных сборок.
Процесс непрерывной интеграции займет так много времени, что к тому времени, когда вы снова сможете запустить сборку, произошло бы несколько коммитов, поэтому вы не узнаете, какая проверка привела к повреждению сборки.
Люди будут регистрироваться реже, потому что им приходится сидеть целую вечность, ожидая сборки программного обеспечения и запуска тестов.
Don’t Check-In on a Broken Build- Самая большая ошибка при непрерывной интеграции - это проверка сломанной сборки. Если сборка ломается, ответственные разработчики ждут, чтобы это исправить. Они при первой возможности определяют причину поломки и устраняют ее. Если мы примем эту стратегию, мы всегда сможем лучше понять причину поломки и немедленно ее исправить.
Если один из наших коллег выполнил проверку и в результате сломал сборку, то, чтобы иметь наибольшие шансы исправить это, ему потребуется четкое рассмотрение проблемы. Когда это правило нарушается, исправление сборки неизбежно занимает гораздо больше времени. Люди привыкают к тому, что сборка сломана, и очень быстро вы попадаете в ситуацию, когда сборка остается сломанной все время.
Always Run All Commit Tests Locally Before Committing- Всегда проверяйте, что тесты, разработанные для приложения, сначала выполняются на локальном компьютере, прежде чем запускать их на сервере CI. Это необходимо для того, чтобы убедиться, что написаны правильные тестовые примеры, и если в процессе CI происходит сбой, то это связано с ошибочными результатами тестирования.
Take Responsibility for All Breakages that Result from Your Changes- Если вы зафиксируете изменение, и все написанные вами тесты пройдут, а другие сломаются, сборка все равно будет повреждена. Обычно это означает, что вы ввели в приложение регрессионную ошибку. Это ваша ответственность - поскольку вы внесли изменение - исправить все тесты, которые не прошли в результате ваших изменений. В контексте CI это кажется очевидным, но на самом деле это не обычная практика во многих проектах.
Существует множество инструментов сборки, доступных для множества языков программирования. Некоторые из самых популярных инструментов сборки включаютAnt for Java и MSBuild for .NET. Использование инструмента сценария, разработанного специально для создания программного обеспечения, вместо настраиваемого набора сценариев оболочки или пакетных сценариев, является наиболее эффективным способом разработки согласованного, повторяемого решения сборки.
Итак, зачем нам процесс сборки для начала. Начнем с того, что для сервера непрерывной интеграции процесс сборки должен быть простым в работе и легко реализуемым.
Давайте рассмотрим простой пример того, как может выглядеть файл сборки для .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 task используется для указания того, какой проект .Net необходимо создать.
Приведенный выше пример представляет собой очень простой файл сборки. При непрерывной интеграции гарантируется, что этот файл поддерживается в актуальном состоянии, чтобы обеспечить беспроблемный процесс сборки.
Создание решения в .Net
Средством сборки по умолчанию для .Net является MSBuild, который поставляется с платформой .Net. В зависимости от платформы в вашей системе вам будет доступна соответствующая версия MSbuild. Например, если у вас установлен .Net framework в месте по умолчанию, вы найдете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.
<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>
<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 будет использоваться для переопределения этих настроек и развертывания на нашем выбранном сервере.
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>Следующий важный шаг - убедиться, что решение основано на сервере сборки. Первая часть - это ручной шаг, потому что перед использованием инструмента непрерывной интеграции мы сначала должны убедиться, что сборка запускается на сервере сборки таким же образом, как и на клиентском компьютере. Для этого мы должны выполнить следующие шаги -
Step 1- Скопируйте весь файл решения на сервер. Мы создали сервер экземпляра Amazon, который будет использоваться в качестве нашего сервера сборки. Итак, сделайте ручное копирование на сервер всего.Net решение на сервере.
Step 2- Убедитесь, что фреймворк присутствует на сервере. Если вы скомпилировали свое приложение в .Net framework 4.0 на своем клиентском компьютере, вы должны убедиться, что оно установлено и на сервере. Так что иди в локациюC:\Windows\Microsoft.NET\Framework на вашем сервере и убедитесь, что желаемая структура присутствует.
Step 3 - Теперь давайте просто запустим MSBuild на сервере и посмотрим, что произойдет.
Хорошо, похоже, мы обнаружили ошибку. В непрерывной интеграции можно извлечь один важный урок: вы должны убедиться, что сборка работает на сервере сборки. Для этого вам необходимо убедиться, что все необходимое программное обеспечение установлено на сервере сборки.
Для .Net нам нужно установить компонент под названием Visual Studio Redistributable package. Этот пакет содержит все необходимые файлы, необходимые для.Netприложение для сборки на сервере. Итак, давайте выполним следующие шаги установки на сервере сборки.
Step 4 - Дважды щелкните исполняемый файл, чтобы начать установку.
Step 5 - На следующем этапе согласитесь с условиями лицензии и нажмите «Установить».
Step 6 - Теперь при запуске MSBuild нам нужно убедиться, что мы включаем дополнительный параметр при вызове MSBuild, который - p:VisualStudioversion = 12.0. Это гарантирует, что MSBuild ссылается на те файлы, которые были загружены на предыдущем этапе.
Теперь мы видим, что решение построено правильно, и мы также знаем, что наш базовый проект правильно строится на сервере.
Следующий ключевой аспект - убедиться, что наш базовый код проверен на нашем сервере управления репозиторием исходного кода, которым является Git. Для этого нам необходимо выполнить следующие действия.
Step 1- Инициализировать репозиторий, чтобы его можно было загрузить в Git. Это делается с помощьюgitкоманда инициализации. Итак, вам нужно перейти в папку вашего проекта и выпуститьgit init команда.
Step 2- Следующий шаг называется промежуточными файлами в Git. Это подготовит все файлы в папке проекта, которые необходимо добавить в Git. Вы делаете это с помощьюgit addкак показано на следующем снимке экрана. '.' обозначение используется, чтобы сказать, что все файлы в каталоге и подкаталоге должны быть включены в фиксацию.
Step 3 - Последний шаг - зафиксировать файлы в репозитории Git, так что теперь это полноценный репозиторий Git.
Теперь, когда у нас есть исходный код в репозитории Git и весь наш исходный код работает на сервере сборки, пришло время создать проект на нашем сервере непрерывной интеграции. Это можно сделать с помощью следующих шагов -
Step 1- Войдите в программу TeamCity. Перейдите по URL-адресу на вашем сервере непрерывной интеграции -http://localhost:8080/login.html.
Введите учетные данные администратора и войдите на сервер.
Step 2- После входа в систему вы увидите главный экран. НажмитеCreate Project чтобы начать новый проект.
Step 3- Дайте название проекту и нажмите «Создать», чтобы запустить проект. В нашем случае мы даем нашему проекту имя «Демо», как показано на следующем снимке экрана.
Step 4- Следующим шагом будет упоминание репозитория Git, который будет использоваться в нашем проекте. Помните, что в среде непрерывной интеграции серверу CI необходимо получить код из репозитория с поддержкой Git. Мы уже сделали нашу папку проекта репозиторием с поддержкой Git на предыдущем этапе. В TeamCity вам необходимо создать корень VCS. Для этого нажмитеVCS Roots на главном экране проекта.
Step 5 - На следующем экране нажмите Create VCS root как показано на следующем снимке экрана.
Step 6 - На следующем появившемся экране выполните следующие шаги -
Укажите тип VCS как Git.
Дайте имя корню VCS, это может быть любое понятное имя. Мы дали название какApp.
Укажите URL-адрес для получения как C:\Demo\Simple - Это out git включен репозиторий.
Если вы прокрутите экран вниз, вы увидите кнопку Проверить соединение. Щелкните его, чтобы убедиться, что вы можете успешно подключиться к репозиторию с поддержкой Git.
Step 7 - Нажмите Create, и вы увидите, что ваш репозиторий зарегистрирован, как показано на следующем изображении.
Step 8- Следующим шагом является создание конфигурации сборки, которая будет использоваться для сборки проекта. Перейдите на экран вашего проекта вTeamCity → General Settings. Щелкните "Создать конфигурацию сборки".
Step 9- На следующем экране дайте имя конфигурации сборки. В нашем случае мы назвали его какDemoBuild а затем нажмите "Создать".
Step 10 - На следующем появившемся экране вам будет предложено выбрать VCS repositoryкоторый был создан на предыдущих шагах. Так что выберите имя‘App’ и щелкните "Присоединить".
Step 11- Теперь на следующем всплывающем экране нам нужно настроить шаги сборки. Так что нажмите "configure build steps manually'гиперссылка.
Step 12 - На следующем экране сборки нам нужно ввести следующие данные -
Выберите тип Runner как MSBuild.
Дайте необязательное имя для имени шага.
Дайте имя файлу, который нужно построить. Когда мы указываем MSbuild в предыдущих разделах, мы обычно видим, что даем возможностьSimple.csproj. Здесь нужно указать то же самое.
Выберите версию MSBuild как «Microsoft Build Tools 2013».
Выбрать MSBuild ToolsVersion как 12.0.
Прокрутите страницу вниз, чтобы сохранить настройки.
Step 13 - На следующем экране нажмите «Выполнить».
Вы увидите, что сейчас идет сборка вашего приложения.
Вы должны получить успешный экран, что является хорошим признаком того, что ваше решение строится правильно.
Вы также можете перейти в журнал сборки, чтобы увидеть все шаги, которые выполнял сервер непрерывной интеграции, как показано на следующем снимке экрана.
Теперь, когда у нас есть базовый код в Git и ссылка на сервер непрерывной интеграции, пришло время увидеть первый шаг непрерывной интеграции в действии. Это достигается путем определения задач на сервере непрерывной интеграции, таких как триггеры, что делает весь процесс непрерывной интеграции максимально бесшовным. Давайте внесем изменения в наш код в Visual Studio.
Step 1 - Зайдите в Demo.aspx страницу в Visual Studio и измените заголовок страницы.
Step 2 - Если мы запросим наш репозиторий Git через git status вы увидите, что Demo.aspx файл был изменен.
Теперь нам нужно убедиться, что каждое изменение в нашем коде должно запускать сборку на нашем сервере непрерывной интеграции. Для этого нам необходимо внести следующие изменения.
Step 3 - Перейдите на панель управления проекта, щелкните раздел триггеров и нажмите Add new trigger.
Step 4 - На следующем появившемся экране выберите VCS trigger, который будет использоваться для создания триггера, чтобы при регистрации в репозитории запускалась сборка.
Step 5 - Щелкните Show Advanced Options и убедитесь, что выбраны параметры, показанные на следующем снимке экрана.
Step 6- Щелкните Сохранить. Теперь вы увидите, что триггер успешно зарегистрирован, как показано на следующем снимке экрана.
Step 7- Теперь пора проверить наш код в репозитории Git и посмотреть, что произойдет. Итак, перейдем в нашу командную строку и выдадимgit add команда для обработки наших измененных файлов.
Step 8 - Теперь выдаем git commit команда, и она отправит изменения в репозиторий Git.
Step 9 - Если вы теперь перейдете на экран обзора проектов, вы увидите, что новая сборка была запущена и запущена.
Если вы видите Change log Tab, вы увидите git comment который запустил сборку.
Попробуем еще раз. Давайте внесем еще одно изменение вDemo.aspxфайл. Проведемgit add команда и git commit со следующим сообщением фиксации.
Теперь вы увидите, что сборка автоматически запускается на панели управления Project в TeamCity.
При сборке появится сообщение об успешном завершении.
Теперь вы увидите сообщение «Вторая фиксация», которое использовалось, когда изменение было зафиксировано в git repository.
Мы успешно завершили первую часть процесса непрерывной интеграции.
Уведомление о сбое сборки - это событие, которое запускается при сбое сборки. Уведомление отправляется всем ключевым людям при сбое сборки. Первое, что нужно сделать в таком случае, - убедиться, что время потрачено на неудачную сборку, чтобы гарантировать, что сборка прошла. Следующие шаги используются, чтобы убедиться, что уведомления о сборке размещены в TeamCity.
Ниже приведены шаги по настройке уведомлений по электронной почте в TeamCity.
Step 1- В TeamCity перейдите на панель управления проекта и нажмите «Администрирование» в правом верхнем углу. Затем вы увидитеEmail Notifierссылка в левой части. Щелкните эту ссылку, чтобы открыть общие настройки электронной почты.
Step 2 - Следующий шаг - ввести данные действующего SMTP Server. Gmail предоставляет бесплатное средство SMTP, которым может пользоваться кто угодно. Таким образом, мы можем ввести эти данные на следующем экране, который появится, как показано на следующем снимке экрана.
- SMTP-хост - smtp.gmail.com
- Номер порта SMTP - 465
- Отправлять сообщения электронной почты и вход по SMTP - это должен быть действующий идентификатор Gmail.
- Пароль SMTP - действительный пароль для этого идентификатора Gmail.
- Безопасное соединение - укажите это как SSL
Step 3 - Щелкните Test Connectionпросто чтобы убедиться, что настройки работают правильно. Затем нажмитеSave для сохранения настроек.
Step 4- Следующим шагом будет включение уведомлений о сборке для пользователя. Первая задача - создать пользователя, который будет получать эти уведомления о сборке. Перейдите в панель управления проекта и выберитеUsers Option.
Step 5- Создайте нового пользователя. Введите необходимые имя пользователя и пароль. Затем нажмите кнопку «Создать пользователя», которая будет расположена в нижней части экрана.
Step 6 - Теперь войдите в систему TeamCity с этим новым идентификатором пользователя и паролем.
Step 7- После входа в систему вам будут представлены общие настройки пользователя. В разделе «Уведомление по электронной почте» нажмите «Изменить».
Step 8 - На следующем появившемся экране щелкните Add new rule.
Step 9 - В «Добавить новое правило» выберите следующие два варианта и нажмите «Сохранить».
Сборки из выбранных проектов - выберите демонстрационный проект.
Установите флажок «Сбой сборки».
Включив эти два параметра, теперь всякий раз, когда сборка для демонстрационного проекта терпит неудачу, пользователю будет отправлено уведомление по электронной почте: demouser.
Step 10- Теперь давайте вызовем неправильную сборку, чтобы увидеть это в действии. В Visual Studio перейдите вdemo.aspx.cs файл и добавить неправильную строку кода.
Step 11 - Теперь проверьте код из Git, выполнив git add и git commit.
Теперь на панели инструментов проекта сборка будет автоматически запущена, и вы увидите, что сборка не удалась, как показано на следующем снимке экрана.
Если вы войдете в Gmail с идентификатором demouser, вы фактически увидите в нем уведомление об ошибке сборки, как показано на следующем снимке экрана.
Один из ключевых аспектов непрерывной интеграции - всегда видеть, как работают сборки, собирать важные метрики, документировать эти результаты и генерировать постоянную обратную связь посредством непрерывных сборок.
Каковы преимущества наличия этих показателей?
Not Committing Code Enough- Если разработчики не часто фиксируют код в репозитории управления версиями, причиной может быть медленная сборка интеграции. Чтобы сократить продолжительность сборки, выполните высокоуровневый анализ среды сборки интеграции для определения узких мест.
Затем проанализируйте результаты и определите наиболее подходящее улучшение, а затем попытайтесь внести изменения в процесс сборки, чтобы сократить продолжительность сборки. Наконец, повторно оцените продолжительность сборки, чтобы определить, нужны ли дальнейшие улучшения.
Improve Test Performance- Даже в хорошо функционирующей CI-системе большая часть времени сборки интеграции будет занята выполнением автоматических тестов. Оценка и улучшение производительности этих тестов может значительно сократить продолжительность сборки.
Infrastructure Issues- Вы можете обнаружить, что сборки интеграции выполняются медленно из-за системной инфраструктуры. Возможно, сетевая производительность низкая или имеется медленное соединение с виртуальной частной сетью.
Географически распределенные системы и ненадежное оборудование или программное обеспечение также могут вызывать проблемы с производительностью. Изучите и улучшите любые ресурсы инфраструктуры, чтобы сократить время сборки.
Метрики
Ниже приведены некоторые показатели, доступные на сервере непрерывной интеграции.
Давайте посмотрим, что может предложить TeamCity -
Одна из самых простых форм метрик - это то, что доступно на панели инструментов проекта. Ключевым элементом здесь является запись продолжительности каждой сборки. Если продолжительность каждой сборки начинает увеличиваться непропорционально создаваемому коду, это может быть проблемой. Итак, это одна обратная связь, которую можно принять, и причины этого могут заключаться в том, что у CI-сервера не хватает ресурсов и, возможно, требуется увеличить емкость сервера.
TeamCity имеет возможность узнать, действительно ли у CI-сервера есть какие-либо проблемы с инфраструктурой. вadmin dashboard в TeamCity можно нажать Disk Usage чтобы узнать, сколько места на диске занято каждой сборкой.
Если требуются дополнительные сведения, то TeamCity имеет diagnostics button, который может дать больше информации о CPU and Memory используется CI-сервером.
Подробный просмотр показателей сборки
Если кто-то хочет увидеть подробный обзор сборок конкретного проекта с течением времени, то это доступно как часть сборок проекта. На экране сборки проекта перейдите на экран статистики, он предоставит различную статистику и диаграммы того, как выполняется сборка.
Одна из ключевых особенностей непрерывной интеграции - гарантировать, что on-going testingсодержит весь код, созданный CI-сервером. После того, как CI-сервер выполняет сборку, необходимо убедиться в наличии тестовых примеров для тестирования необходимого кода. Каждый CI-сервер имеет возможность запускать модульные тесты как частьCI suite. В.Net, модульное тестирование - это функция, встроенная в .Net framework и то же самое можно включить в CI Server.
В этой главе мы увидим, как мы можем определить тестовый пример в .Netа затем позвольте нашему серверу TeamCity запустить этот тестовый пример после завершения сборки. Для этого нам сначала нужно убедиться, что у нас есть модульный тест, определенный для нашего образца проекта.
Для этого мы должны с максимальной осторожностью выполнять следующие шаги.
Step 1- Давайте добавим в наше решение новый класс, который будет использоваться в нашем модульном тесте. У этого класса будет переменная имени, которая будет содержать строку «Непрерывная интеграция». Эта строка будет отображаться на веб-странице. Щелкните правой кнопкой мыши простой проект и выберите пункт меню.Add → Class.
Step 2 - Дайте название классу как Tutorial.cs и нажмите кнопку «Добавить» внизу экрана.
Step 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";
}
}
}Step 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";
}
}
}Step 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. После завершения компиляции вы должны получить следующий результат.
Step 6- Теперь пора добавить в проект наши модульные тесты. Щелкните правой кнопкой мыши наSolution и выберите пункт меню Add → New Project.
Step 7 - Перейдите к Test и с правой стороны выберите Unit Test Project. Дайте имя какDemoTest а затем нажмите ОК.
Step 8 - В вашем Demo Test project, вам необходимо добавить ссылку на проект Simple и на необходимые testing assemblies. Щелкните проект правой кнопкой мыши и выберите пункт меню.Add Reference.
Step 9 - На следующем появившемся экране перейдите в «Проекты» и выберите Simple Reference и нажмите ОК.
Step 10 - Щелкните Add Reference снова перейдите в Сборки и введите Webв поле поиска. Затем добавьте ссылку наSystem.Web.
Step 11 - В Unit Test fileдобавьте следующий код. Этот код гарантирует, что у класса 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");
}
}
}Step 12- Теперь давайте запустим наш тест в Visual Studio, чтобы убедиться, что он работает. В Visual Studio выберите пункт менюTest → Run → All Tests.
После запуска теста вы увидите, что тест успешно запущен в левой части Visual Studio.
Включение непрерывного тестирования в TeamCity - Теперь, когда все тестовые примеры готовы, пришло время интегрировать их в наш сервер Team City.
Step 13- Для этого нам нужно создать шаг сборки в нашей конфигурации проекта. Перейдите на главную страницу своего проекта и щелкните Изменить параметры конфигурации.
step 14 - Затем перейдите в «Шаг сборки» → «Сборка MS» и нажмите «Добавить шаг сборки», как показано на следующем снимке экрана.
На следующем появившемся экране добавьте следующие значения -
Выберите тип бегуна как Visual Studio Tests.
Введите необязательное имя шага теста.
Выберите тип Test Engine как VSTest.
Выберите версию Test Engine как VSTest2013.
В имени тестовых файлов укажите местоположение как DemoTest\bin\Debug\DemoTest.dll - Помни это DemoTestэто название нашего проекта, который содержит наши модульные тесты. ВDemoTest.dll будет сгенерирован нашим первым шагом сборки.
Щелкните Сохранить, который будет доступен в конце экрана.
Теперь у вас будет 2 этапа сборки для вашего проекта. Первый - это этап сборки, на котором будет построен код вашего приложения и ваш тестовый проект. А следующий будет использоваться для запуска ваших тестовых случаев.
Step 15- Теперь пришло время зарегистрировать весь ваш код в Git, чтобы можно было запустить весь процесс сборки. Единственная разница в том, что на этот раз вам нужно запуститьgit add и git commit команда из Demo parent folder как показано на следующем снимке экрана.
Теперь, когда запускается сборка, вы увидите начальный вывод, в котором будет сказано, что тест пройден.
Step 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
Step 1 - Перейдите на главный экран своего проекта и нажмите «Изменить параметры конфигурации».
Step 2 - Перейдите в раздел «Шаги сборки» и нажмите «Изменить» для TestStep. Непрерывная проверка должна выполняться вместе с определенными модульными тестами.
Step 3 - В разделе .Net Coverage нажмите .Net Coverage Tool. А затем выберите следующие настройки.
- Выберите инструмент .Net Coverage как NCover (3.x)
- Платформа как x86
- Версия как v4.0
- Путь к NCover как C: \ Program Files (x86) \ NCover
- Остальные настройки оставьте как есть
Step 4 - Щелкните Сохранить.
Step 5 - Теперь перейдите на главный экран вашего проекта и нажмите «Выполнить».
Step 6- После запуска сборки нажмите «Тест пройден». Теперь вы увидите экран «Покрытие кода» и множество индикаторов показателей.
Step 7 - Теперь вы можете щелкнуть вкладку «Охват кода», чтобы получить дополнительную информацию об анализе кода.
Step 8 - Щелкните значок fullcoveragereport.html. Теперь вы получите полный подробный отчет о проверке, проведенной для.Net code.
Непрерывная интеграция базы данных - это процесс восстановления базы данных и тестовых данных каждый раз, когда в репозиторий управления версиями проекта вносятся изменения.
В интеграции базы данных, как правило, все артефакты, связанные с интеграцией базы данных -
- Должен находиться в системе контроля версий.
- Могут быть проверены на строгость и проверены на соответствие политике.
- Может быть сгенерирован с использованием ваших сценариев сборки.
Действия, которые могут быть задействованы в непрерывной интеграции базы данных, могут быть одним из следующих:
Drop a Database - Отбросьте базу данных и удалите связанные данные, чтобы вы могли создать новую базу данных с тем же именем.
Create a new Database - Создайте новую базу данных с помощью языка определения данных (DDL).
Insert the Initial Data - Вставьте любые исходные данные (например, таблицы поиска), которые, как ожидается, ваша система будет содержать при доставке.
Migrate Database and Data - Периодически переносите схему и данные базы данных (если вы создаете систему на основе существующей базы данных).
Modify Column Attributes - Измените атрибуты и ограничения столбцов таблицы на основе требований и рефакторинга.
Modify Test Data - При необходимости измените тестовые данные для нескольких сред.
Итак, в нашем примере с непрерывной базой данных мы собираемся сделать следующие шаги:
Создадим базу данных MS SQL Server и соответствующую таблицу.
Мы создадим сценарий из SQL Server Management Studio. Этот сценарий базы данных будет использоваться для создания нашей таблицы в базе данных.
Мы напишем код в нашем проекте ASP.Net для доступа к этой базе данных.
Мы создадим в нашем проекте в TeamCity шаг для запуска этого скрипта.
Мы проверим наш скрипт в Git.
Шаги для этого в базе данных AWS, созданной в предыдущем разделе.
Step 1- Создайте базу данных MS SQL Server и соответствующую таблицу. Давайте откроем SQL Server Management Studio и создадим простую базу данных и таблицу. Щелкните базы данных правой кнопкой мыши и выберитеNew Database.
Step 2 - Назовите это как Demodb и нажмите ОК
Step 3 - В новой базе данных щелкните правой кнопкой мыши и создайте новую таблицу.
Step 4 - Вы можете добавить желаемые столбцы в таблицу.
Step 5 - Сохраните таблицу и назовите ее как Demotb.
Step 6 - Теперь щелкните правой кнопкой мыши стол и выберите пункт меню. Script Table as → Drop and Create to → File.
Step 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]
GOStep 8 - А теперь давайте быстро изменим наш ASP.Net code для ссылки на новую базу данных.
Step 9 - В Tutorial.cs файл в вашем Demo projectдобавьте следующие строки кода. Эти строки кода будут подключаться к вашей базе данных, принимать версию сервера и сохранять имя версии в переменной 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();
}
}
}
}Step 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);
}
}
}Теперь, если мы запустим код, вы получите следующий результат в браузере.
Step 11- Теперь давайте добавим наш шаг в TeamCity, который будет вызывать скрипт базы данных. Перейдите в панель управления проекта и нажмитеEdit Configuration Settings.
Step 12 - Перейдите к этапам сборки и щелкните Add build step.
Выберите следующие параметры (обратите внимание, что клиент MS SQL Server должен быть установлен на CI Server).
Тип бегуна должен быть командной строкой.
Укажите необязательное Имя шага.
Запуск должен быть исполняемым с параметрами.
Исполняемый файл команды должен быть C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe
Параметры команды должны быть -S WIN-50GP30FGO75 -i Sample.sql. Где –S дает имя экземпляра SQL Server.
Step 13 - Щелкните Сохранить.
Теперь необходимо обеспечить порядок сборки. Вы должны убедиться, что порядок сборки следующий.
Step 14 - Вы можете изменить порядок сборки, выбрав опцию изменения порядка шагов сборки.
Настройка базы данных должна быть первой - так что она будет использоваться для воссоздания вашей базы данных из свежего.
Далее идет сборка вашего приложения.
Наконец-то ваша тестовая установка.
Step 15 - Теперь запустите git add и git commit команда так, чтобы Sample.sqlфайл зарегистрирован в Git. Это автоматически запустит сборку. И эта сборка должна пройти.
Теперь у вас есть полноценный цикл сборки с аспектом непрерывной интеграции базы данных, а также в вашем цикле. В следующем разделе давайте продолжим и рассмотрим непрерывное развертывание.
Теперь, когда вы сделали это с локальным SQL Server, мы можем повторить те же шаги для AWS MS SQLСервер, созданный в одном из предыдущих разделов. Чтобы подключиться к Microsoft SQL Server, вам необходимо подключиться согласно следующему соглашению.
Step 16- Сначала посмотрите, какое имя присвоено вашему экземпляру базы данных в AWS. При входе в AWS перейдите в раздел RDS под разделом базы данных.
Step 17 - Нажмите на инстансы БД на следующем появившемся экране.
step 18- Щелкните свою базу данных и запишите конечную точку. На следующем снимке экрана этоdemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433
Step 19 - Теперь для подключения к базе данных из SQL Server Management Studio, вам нужно указать соединение как demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Обратите внимание на запятую, используемую между именем экземпляра и номером порта).
На следующем снимке экрана показано успешное подключение к базе данных.
Затем вы можете повторить все те же действия. ВSqlcmd command будет следующим -
Эту же команду можно заменить на этапе сборки базы данных в TeamCity. Когда вы выполняетеsqlcmd command, таблица будет автоматически создана в вашей базе данных SQL Server в AWS.
Автоматические сборки и повторяемые сборки. Автоматические тесты и повторяемые тесты. Категории тестов и частота тестов. Постоянные проверки. Непрерывная интеграция с базой данных. Эти задачи по созданию эффективной среды CI в первую очередь дают одно ключевое преимущество: выпуск работающего программного обеспечения в любой момент времени и в любой среде.
В наших предыдущих главах мы выполнили все следующие этапы:
- Создал наш код.
- Обеспечил правильную сборку в TeamCity.
- Создал процесс интеграции базы данных.
- Проведено успешное тестирование.
Теперь остается только выполнить автоматическое развертывание, чтобы завершить весь процесс.
Для автоматического развертывания в нашем случае нам нужно выполнить следующие шаги:
На нашем сервере развертывания убедитесь, что IIS установлен.
Убедитесь, что пользователю IIS предоставлен доступ к нашей базе данных.
Создайте профиль публикации, который будет использоваться для публикации сайта при его создании.
Убедитесь, что мы изменили нашу команду MSBuild для автоматического развертывания.
Автоматизируйте TeamCity для автоматической публикации.
Сделать git commit чтобы все ваши файлы были в Git.
Step 1- Настроить локальный сервер IIS. Если у вас есть локальный или удаленный сервер IIS, для развертывания нашего приложения можно выполнить следующую настройку. Всегда полезно проверить, можно ли выполнить развертывание вручную, прежде чем оно будет выполнено в автоматическом режиме.
Step 2 - На сервере Windows 2012 перейдите в диспетчер серверов и нажмите «Добавить роли и компоненты».
Step 3 - Нажмите Далее на появившемся следующем экране.
Step 4 - Выберите установку на основе ролей или функций на следующем экране и нажмите Далее.
Step 5 - Выберите сервер по умолчанию и нажмите Далее.
Step 6 - Выберите роль веб-сервера и нажмите Далее.
Step 7 - На следующем появившемся экране нажмите Далее.
Step 8 - Еще раз нажмите «Далее» на появившемся следующем экране.
Step 9 - На следующем всплывающем экране нажмите Далее.
Step 10 - На последнем экране вы можете нажать кнопку «Установить», чтобы установить IIS.
После того, как вы установили IIS, вы можете открыть его, открыв Internet Information Services.
Step 11 - Щелкните Пулы приложений, вы увидите пул с именем DefaultAppPool. На следующем этапе ему потребуется доступ к SQL Server.
Step 12 - Если нам нужно подключить приложение ASP.Net к приложению MS SQL Server, мы должны предоставить доступ к пулу приложений по умолчанию для экземпляра SQL Server, чтобы он мог подключиться к нашему Demodb база данных.
Step 13- Откройте SQL Server Management Studio. Перейдите в Логины, щелкните правой кнопкой мыши и выберите пункт меню.New Login.
На следующем экране обновите следующие параметры и нажмите OK.
- Имя для входа - IIS APPPOOL \ DefaultAppPool.
- База данных по умолчанию - это должна быть наша база данных, которая называется demodb.
Step 14 - Создание Publish Profile. Профиль публикации используется в Visual Studio для создания пакета развертывания, который затем можно использовать с MS Build и, соответственно, на любом сервере CI. Для этого в Visual Studio щелкните проект правой кнопкой мыши и выберите пункт меню Опубликовать.
Step 15 - На следующем появившемся экране выберите создание нового профиля публикации, дайте ему имя - DemoDeployment. Затем нажмите кнопку «Далее».
На следующем экране, который появляется, добавьте следующие значения -
- Выберите метод публикации как веб-развертывание.
- Введите сервер как localhost.
- Введите имя сайта как Default Web Site / Demo.
- Поместите целевой URL как http://localhost/Demo
Затем нажмите кнопку «Далее».
Step 16 - На следующем экране нажмите Далее.
Step 17 - На последнем появившемся экране нажмите кнопку «Опубликовать».
Теперь, если вы перейдете к C:\Demo\Simple\Properties\PublishProfiles расположение вашего проекта, вы увидите новый publish profile xml fileсоздан. Этот файл профиля публикации будет содержать все сведения, необходимые для публикации вашего приложения на локальном сервере IIS.
Step 18- Теперь давайте настроим нашу команду MSBuild и воспользуемся указанным выше профилем публикации и посмотрим, что произойдет. В нашей команде MSBuild мы указываем следующие параметры -
Развертывание при сборке истинно - это вызовет автоматическое развертывание после успешной сборки.
Затем мы упоминаем об использовании профиля публикации, который использовался на предыдущем шаге.
Версия Visual Studio просто должна быть упомянута для возможности развертывания MSBuild относительно того, какая версия Visual Studio используется.
Когда вы запускаете указанную выше команду, MSBuild запускает процесс сборки и развертывания. Вы заметите, что он развертывает его на нашемDefault Website на нашем сервере IIS.
Теперь, если мы перейдем на сайт - http://localhost/Demo/Demo.aspx мы увидим следующий результат, который означает, что MSBuild успешно развернул на нашем веб-сайте.
Step 19 - Автоматизация с помощью TeamCity - Теперь пора добавить на наш сервер TeamCity задачу для автоматического использования MSBuild для развертывания нашего приложения на основе вышеупомянутых шагов.
Step 20 - Перейдите в панель управления проекта и нажмите Edit Configuration Settings.
Step 21 - Перейдите в раздел «Шаги сборки» и нажмите «Добавить шаг сборки».
Выберите следующие варианты -
Тип бегуна должен быть MSBuild
Укажите необязательное имя шага
Введите путь сборки как Simple / Simple.csproj
Оставьте версию MSBuild как Microsoft Build Tools 2013
Оставьте версию MSBuild Tools как 12.0
Поместите командную строку как / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0
Step 22 - Щелкните Сохранить.
Убедитесь, что на этапах сборки этап развертывания является последним в цепочке.
Step 23 - А теперь сделаем финал git commit, чтобы убедиться, что все файлы находятся в Git и могут использоваться TeamCity.
Поздравляем, вы успешно настроили полный цикл непрерывной интеграции для своего приложения, который можно запустить в любой момент.
Давайте сделаем окончательный обзор лучших практик непрерывной интеграции на основе всех уроков, которые мы извлекли до сих пор -
Maintain a code repository- Это самый простой шаг. Во всех наших примерах все поддерживается в репозитории Git, от базы кода до профилей публикации и сценариев базы данных. Всегда нужно следить за тем, чтобы все хранилось в репозитории кода.
Automate the build- Мы видели, как использовать MSBuild для автоматизации сборки вместе с использованием профиля публикации. Это снова ключевой шаг в непрерывном процессе интеграции.
Make the build self-testing - Убедитесь, что вы можете протестировать сборку, сохраняя единичные тестовые случаи на месте, и эти тестовые примеры должны быть такими, чтобы их мог запускать сервер непрерывной интеграции.
Everyone commits to the baseline every day- Это ключевой принцип непрерывной интеграции. Нет смысла оставаться до конца всего процесса, чтобы посмотреть, кто сломал сборку.
Every commit (to baseline) should be built- Каждая фиксация, сделанная в приложении, должна быть успешно построена. Если сборка по какой-либо причине завершается неудачно, необходимо изменить код, чтобы обеспечить успешную сборку.
Keep the build fast- Если сборка выполняется медленно, это указывает на проблему во всем процессе непрерывной интеграции. Убедитесь, что продолжительность сборки всегда ограничена, желательно никогда не превышать 10 минут.
Everyone can see the results of the latest build- Панель управления TeamCity дает всем возможность увидеть все сборки, которые прошли или не прошли. Это дает хорошее представление обо всех людях, участвующих в процессе непрерывной интеграции.