Введение в непрерывную интеграцию (Андрей Сатарин, AgileDays-2008)

Материал из CustisWiki

Версия от 18:31, 18 апреля 2011; StasFomin (обсуждение | вклад)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск
Докладчик
Андрей Сатарин

Мы несколько опоздали к началу, поэтому рекомендуем скачать полное видео с сайта http://agiledays.ru/.

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/6280593?byline=0&portrait=0" width="720" height="544" frameborder="0"></iframe>

Андрей Сатарин на AgileDays-2008-01.jpg


Доклад про Continuous Integration, возможно уже несколько набил оскомину у продвинутых тестировщиков и разработчиков, — ведь мы по более-менее схожей теме уже проводили открытый семинар, доклад на конференции SECR-2008, не говоря уже о паре внутренних лекций.

С другой стороны, в отличие от некоторых авторов (включая западных гуру), выступающих с одной темой годами, достигая в ней неизмеримых высот и глубин, мы считаем, что лучше «отбомбиться» по теме сразу и до конца, пока она актуальна, чтобы избежать обидных обвинений ( [:|||||||:] ).

И действительно, семинар показал, что в целом, концепция непрерывной интеграции у аудитории удивления не вызывает, споров полезна она или вредна, уже не ведется (примерно как ранее стало бессмысленно спорить о необходимости систем контроля версий), многие попробовали несколько различных продуктов, а многие даже гордятся возникающими сложностями — «наш проект настолько длинный велик, что даже самая непрерывная интеграция прерывается и превращается в ночные сборки» и «наша команда настолько распределенная, что наши сборки не поспевают за Солнцем…».

Андрей Сатарин на AgileDays-2008-02.jpg


Такие настроения было несложно предугадать, и продемонстрировать «карту в рукаве/рояль в кустах» — «слайды с ответами на ожидаемые вопросы».

В целом мысль такова: долгое время сборки — это

  • либо проблема неправильных инструментов (не используются правильные менеджеры сборки, типа SCons, Ant, make, …),
  • либо проблема архитектуры (наличие крупных ядер, где «все зависит от всего»).

Конечно, такие случаи есть, и странно, что аудитория на них не указала (тогда бы мы показали еще слайдов).

Например, классическая реляционная база данных, как известно, очень плохо стыкуется почти со всеми agile-практиками, и в случае continuous integration «кошерное» пересоздание тестировочной базы с нуля в большинстве случаев выглядит неподъемной задачей.

Но и в этом случае можно «бороться за живучесть» концепции, применяя разные лайфхаки.

Например, классический паттерн ускорения непрерывной интеграции — наращивание памяти на сборочном сервере, и использование tmpfs для файлов и специальных in-memory SQL СУБД для тестирования SQL СУБД функциональности.

Но несмотря на все эти гитики, действительно, тема непрерывной интеграции не такая уж и обширная, в целом тянет на полдесятка статей, так например, книга «Continuous Integration» Пола Дюваля и К° (есть русский перевод — «Непрерывная интеграция»), явно имеет «надутый водой» объем.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».


Репликация: База Знаний «Заказных Информ Систем» → «Введение в непрерывную интеграцию (Андрей Сатарин, AgileDays-2008)»