Pull to refresh

Continuous Integration. Путь обеспечения надежности и доверия к системе

Reading time 4 min
Views 34K
Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.

Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. 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
Tags:
Hubs:
+4
Comments 8
Comments Comments 8

Articles