Первую версию этого поста я начал писать еще 2009-01-05 и в ней должно было описываться что такое CI и как настроить CruiseConrol.NET для ежедневных билдов. Пока писал - на ДОУ(линк на хоум пейдж) вышла аналогичная статья, т.ч. в то время моему посту не суждено было быть опубликованным. Потом я считал что Continuous integration является обязательным для любого проекта чуть более чем “hello world” и эта простая истина всем понятна. Как оказалось нет...

 

Что такое CI?

Continuous integration - дословно, это непрерывная интеграция. Вроде все просто и понятно. Осталось только разобраться интеграция чего и с чем. Если верить Википедии, то получаем следующее определение:

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

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

Что подразумевает под собой процесс CI?

Этот процесс может включать в себя такие шаги:

 

  • сборка проекта из исходников;
  • разворачивание/установка проекта (deployment);
  • тестирование (unit, интеграционные, нагрузочные и другие тесты).
  • создание отчета и уведомление команды о результатах предыдущих шагов.

Все эти шаги хотя и являются желаемыми, но не есть обязательными. За исключением, наверное, последнего - без него теряется фидбек о текущем состоянии проекта и о каких-то проблемах команда узнает не сразу. Но и этот шаг при желании/необходимости можно пропустить. Теперь подробнее о каждом из шагов. Шаги выполняются по порядку шаг 1 => шаг 2 => шаг 3 => шаг четыре. Если на шагах 1-3 произошла ошибка, то сразу переходят к последнему.

Сборка проекта из исходников

В типичном случае - по какому-то триггеру (время, новый коммит, нажатие кнопки “Старт”) сервер CI вытаскивает из системы контроля версии последние исходники, помечает текущую версию тегом с номером билда и компилирует проект. Все достаточно просто и понятно.

Разворачивание/установка проекта (deployment)

Этот шаг является подготовительным для тестирования. В случае если необходимо тестировать инсталлятор - шаг 2 объединяется с шагом 3.

Тестирование (unit, интеграционные, нагрузочные и другие тесты)

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

В зависимости от типов и количества тестов, на сервере CI может быть создано несколько разных типов проектов/билдов. Это может быть прогон unit-тестов при каждом изменении кода, запуск ночных билдов со smoke-тестами и, в случае прохождения smoke-тестов, будут запускаться более долгие по времени тесты - нагрузочное тестирование, проверка всех компонентов программы и т.д. 

Создание отчета и уведомление команды о результатах предыдущих шагов

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

Какие же преимущества нам дает CI?

Значительных преимуществ тут, на мой взгляд, 3 (конечно, их все можно объединить в одно - качество):

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

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


Comments are closed