Continuous integration (CI) - что это такое и с чем его едят

 

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

 

Что такое CI?

Continuous integration - дословно, это непрерывная интеграция. Вроде все просто и понятно. Осталось только разобраться интеграция чего и с чем. Если верить [Википедии](http://ru.wikipedia.org/wiki/Непрерывная интеграция), то получаем следующее определение:

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags

.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache asp.net asp.net-mvc automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms fstab gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx k8s kharkivpy kiss kombu kubernetes kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols proxy pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh static-site sublimetext svg tests tgt tipfy todo tornado typescript uapycon ui uneta unit-tests upgrades usability vim virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги

Recent posts

Go 1.18: new features

Всё будет Kubernetes

2022 Relaunch

Everyday Blogging

I don't want this CI


Archives

2022 (3)
2019 (73)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (36)
2010 (25)
2009 (35)
2008 (32)
2007 (2)