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

Приглашаем на конференцию «Application Developer Days-2011»! Задай вопросы председателю ПК (или ответь на пару вопросов и получи большую «скидку от шефа»)…

Докладчик

Андрей Сатарин

• Презентация,
• презентация-handout,
• статья.
• Есть аудиозапись.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.