Вопрос 5. CI (Continuous Integration) – непрерывная интеграция

Непрерывная интеграция (англ. Continuous Integration) – это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать ёё более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. Практика частой сборки (интеграции) проекта удачно сочетается проведением модульного (unit) тестирования.

Типы сборок:

- редкие сборки под конкретные релизы

- ночные сборки

- непрерывные сборки

Требования к проекту:

Исходные коды и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями CVS;

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

Распространённые системы управления версиями:

- GIT

- Mercurial

- Subversion

- CVS

- Microsoft Visual SourceSafe

- Microsoft Team Foundation

- Rational ClearCase

Процесс CI:

Практика continuous integration не требует никакого технического и программного обеспечения, но гораздо удобнее, проще и дешевле наладить процесс CI с использованием подобных специальных средств. Такие средства называются сервера интеграции (continuous integration server)- специализированные приложения для автоматизации данного процесса.

Наиболее известный из серверов интеграции пожалуй CruiseControl. CruiseControl это сервер для интеграции приложений на java, написанный на java. Так же широко распространен его собрат (точнее портированная версия) под.NET – CruiseControl.NET, интересен Team City от питерской компании JetBrains.

Итак, для организации процесса CI на выделенном сервере организуется служба, запускающая сборку по триггеру:

- внешнему запросу,

- по расписанию,

- по факту обновления репозитория.

Основные этапы CI в CruiseControl:

1) Trigger - триггер срабатывания Цикл интеграции начинается со срабатывания триггера. Это может быть одно из следующего:

a) изменение в системе контроля версий, зафиксирован факт обновления репозитория;

b) изменение в файловой системе;

c) по расписанию в определенный момент времени;

d) сборка другого проекта;

e) нажата «красная» кнопка, внешний запрос;

f) и др. например, изменение на веб сервере др.;

Подробно рассмотрим отдельно триггерные события (c) и (a):

(c) сборка по расписанию

В случае сборки по расписанию (англ. daily build — русск. суточная сборка) дополнительно вводится система нумерации сборок. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается перед очередной сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория системы контроля версий помечаются номером сборки. Благодаря этому точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.

(a) Сборка по факту обновления репозитория

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

Быстрая сборка

«Сборка должна идти быстро» - точнее не более 10 минут. Если после одного небольшого коммита (фиксирование изменения в VCS) интеграционный сервер будет затрачивать около часа на сборку, тестирование и разворачивание от этого будет мало пользы. Разработчики будут уже далеко, над решение других проблем и им будет сложно вернуться и понять причины сбоя, если таковой был. Ведь суть непрерывной интеграции в получении быстрого feedback. В добавок поздний ответ с сервера может отвлечь их от другого дела.

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

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

3) Analyse – не обязателен;

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

4) Build - обязательный этап. (NAnt, MSBuild, Ant).

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

5) UnitTest – проведение автоматизированных тестов.

6) Deploy – посредством тестирования мы убедились в работоспособности кода, поэтому проект разворачивается, например в случае веб-приложения, соответствующие файлы выкладываются на веб-сервер. Либо осуществляется переустановка приложения в системе. Этап является не обязательным.

7) Test – не обязателен. После того ка приложение «развернуто» необходимо его протестировать. Здесь имеются ввиду автоматические функциональные тесты, иначе говоря на данном этапе проводиться регрессионное тестирование После прохождения регрессионных тестов можно считать, что интеграция прошла успешно и в проект не внесено правок, которые могут привести к его не работоспособности (здесь все зависит от вашего набора тестов модульных и функциональных).В противном случае интеграция не успешна—код содержит ошибки и требуется его исправление/доработка.

Тестирование это один из «фатальных» этапов процесса, ошибка на котором означает сбой сборки. Всего есть несколько таких «фатальных» этапов:

Build—проект не собирается

UnitTest — модульные тест не прошли или покрытие упало ниже заданного уровня Coverage;

Test — регрессионные тесты не прошли или покрытие упало ниже заданного уровня;

Иногда к ним присоединяют этап Analyse— если в коде обнаружено несоответствие стандартам кодирования (FXCop), то это является ошибкой.

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

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

Преимущества:

- проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле;

- немедленный прогон модульных тестов для свежих изменений;

- постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т.п.

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

Недостатки:

- затраты на поддержку работы непрерывной интеграции;

- потенциальная необходимость в выделенном сервере под нужды непрерывной интеграции;

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

Дата добавления: 2017-01-13