Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.
Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. 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
- светофор сборок
- звуковое оповещение
Также, стоит отметить, что многие 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
Автор: Samhayn
