[Из песочницы] Continuous Integration. Путь обеспечения надежности и доверия к системе
Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. Refactoring, TDD, XP, и, наконец, Continuous Integration, это то, что в последнее время интересует меня в процессе разработки программного обеспечения.
Хочу поделиться с хабросообществом тем, что я вынес из книг и с чем приходится сталкиваться в реальности.
Теория Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.Использование CI позволяет вовремя отслеживать ошибки интеграции, сделать систему и процесс разработки более «прозрачными» для всех участников команды, также, CI избавляет от рутинных операция по сборке продукта, повышает качество продукта, включает в себя профит от написания тестов, который, я думаю, для всех хаброюзеров очевиден.
Фактически, CI позволяет избавиться от предположений, при процессе разработки ПО. Менеджер предполагает, что продукт готов и стабилен, программист — что в коде нет ошибок и т. д. Избавиться от вопросов, таких как: «стабильна ли последняя сборка, какие фичи готовы, соответствует ли код стандартам компании» и т.д.
Всех, кому интересна тема CI прошу под кат.Идеологически CI базируется на следующих соглашениях:
часто (не менее 1 раза в день) «заливать» свой код в репозиторий писать автоматические тесты запускать private builds (процесс сборки, который выполняется с использованием исходного кода, в данный момент находящегося в локальном репозитории разработчика) не «заливать» неработающий код чинить сломанный build немедленно следить за тем, чтобы все тесты и проверки проходили не выкачивать из репозитория сломанный код Build script Скрипт сборки — это набор комманд, которые будут выполнены при запуске процесса интеграции. Чаще всего он выглядит как следующий набор шагов: Очистка от результатов предидущего запуска Компиляция (или статический анализ кода для интерпретируемых языков) Интеграция с базой данных Запуск автоматических тестов Запуск других проверок (соответствие код стандартам, проверка цикломатической сложности и т. д.) Разворачивание программного обеспечения Автоматические тесты Всем, кто собирается внедрять CI, придется смириться с тем, что автоматические тесты это неотъемлемая часть процесса непрерывной интеграции. И один лишь статический анализ кода в автоматическом режиме не является Continuous Integration, такой подход называют Continuous Compilation.В CI используются тесты всех уровней за исключением исследовательских. Так как на разных ресурсах список уровней тестирования разный приведу те, которые описывают идеологи CI:
модульные (unit) тесты компонентные тесты функциональные тесты системные тесты По написанию и запуску тестов также принят ряд соглашений:
более быстрые тесты должны запускаться первыми тесты должны быть разделены по категориям на все баги должны писаться тесты тест кейсы стоит ограничивать одной проверкой тесты должны выполняться без ошибок при повторном запуске На сколько надежна система За надежность системы отвечает каждый ее компонент, поэтому очень важно уделить повышению надежности системы свое внимание. Я думаю, что никто не хотел бы пользоваться компьютером, который 20% времени не отвечает на ваши запросы. Для того, чтобы продемонстрировать важность надежности представьте себе, что у вас система из 3-х компонентов. Каждый их этих компонентов, надежен на 90%, таким образом общая надежность системы представляет произведение надежностей каждого компонента, итого — 73%. А теперь вспомните, сколько компонентов в последнем написанном вами приложении…Continuous Inspection Continuous Inspection — это один из шагов build script, который предполагает проверку соответствия кода в репозитории код стандартам, соответствие уровня code coverage и других метрик заданному порогу.Continuous Feedback Одним из самых важных действий в CI является механизм обратной связи, который согласно положениям CI, должен осуществляться с учетом правила: «Правильным людям. В правильное время. Правильным образом.» (ориг. — «The right people. The right time. The right way.»).Существуют следующие популярные механизмы осуществления обратной связи:
SMS browser plug-in светофор сборок звуковое оповещение email Также, стоит отметить, что многие IDE (NetBeans, PHPStorm), позволяют синхронизироваться с популярными (Jenkins, TeamCity) CI серверами.
Реальность Так уж случилось, что учавствую в разработке «кровавого энтерпрайз проекта», пришлось адаптировать идеальный вариант CI под реалии сурового мира. К тому времени, как я начал заниматься CI, в распоряжении компании уже были: CI server (Jenkins) с парой десятков билдов модульные тесты, хоть и небольшое колличество скрипты сборки, в основном на shell, но с тенденцией перехода на apache ant стандартный механизм обратной связи — email Главные проблемы:
разработчики не хотят писать даже модульные тесты реакция на механизм обратной связи, медленная, многие письма просто игнорируются баги не покрываются модульными тестами Решения:
доклады по CI и модульному тестированию просветительская работа с каждым разработчиком сотрудничество с QA департаментом изменение в процессе разработки, предполагающее обязательное написание тестов Планы:
улучшить механизм обратной связи, возможно, оставить тот же, предварительно составив для разработчиков алгоритм поиска причин упавшей сборки наладить процесс написания модульных тестов перед кодом, фактически переход на TDD сотрудничество с QA департаментом в целях обнаружения багов еще на этапе составления документации, а также для составления и написания тестовых сценариев Эпилог CI практика, которая в данное время набирает популярность в связи с развитием все большего колличества «взрослых» решений, которые несут серьезную ответственность за качество выпускаемого ими продукта.Заинтересовавшимся предлагаю прочести книги по CI и смежным или производным от него темам:
Пол Дюваль — Continuous-IntegrationДжез Хамбл — Continuous DeliveryРоберт Мартин — Clean Code, Clean Coder
