Блог

Непрерывная Интеграция. Антипаттерны.

2010-02-05T02:42:00.001+02:00

Непрерывная Интеграция. Антипаттерны.

Так получилось, что с недавнего времени в компании на которую я работаю решили ввести практику Непрерывной Интеграции сборок.

О том, что из себя представляет сама практика писать не буду - об этом и так неплохо описано в вики. Попытаюсь высказать свои мысли по этой теме, которые, возможно, будут полезны для людей, которые тоже решат использовать в своих проектах эту полезнейшую практику. Также надеюсь что те, кто уже ее используют, дополнят список своими "обожженными местами".

Полезности, которые дает НИ. Перечислены не возможности, а именно полезности - что на мой взгляд является действительно самым важным. Приоритет по убыванию:

1. Максимально быстрое извещение разработчиков о том, что их изменения что-то где-то поломали;

2. Авто-сбор статистики по различным метрикам;

3. Возможность автоматизировать обновление производственного сервера (в случае серверных приложений) или выкладывание новых инсталляционных файлов на сервер (в случае настольных приложений).

Теперь о тех условиях, без которых, как мне кажется, НИ не может иметь жизнь.

1. Система контроля версий.

Очевидно. Одно из главных условий - без нее очень трудно отследить когда и какие были внесены изменения, и, соответственно, запустить сборку проекта в нужное время и в нужном состоянии.

2. Автоматическая сборка системы.

Система должна "уметь" собираться без участия разработчика - никаких запросов "Вы уверены что хотите запустить модульные тесты?" или "Укажите путь к библиотеке ***:" не должно быть - иначе НИ скрипт/cервер не сможет собрать проект в фоновом режиме. Так же желательно, что бы сборка осуществлялась в один запуск, хотя это уже не обязательно - практически все современные НИ инструменты позволяют создавать композитные шаги для сборки.

3. Все включено.

Все используемые при сборке библиотеки должны быть включены в репозиторий. В идеале - что бы можно было сделать чекаут проекта из репозитория на "чистой" машине и удачно собрать проект. Само собой, это правило не касается инструментов, осуществляющих тот или иной шаг сборки - компиляторы, инструменты тестирования и т.п. - поэтому слово "чистой" было взято в кавычки. Речь идет о библиотеках исходного кода, которые использует разрабатываемая система.

4. Правильное производственное окружение на НИ сервере.

Наверняка все сталкивались с ситуацией, когда у одного разработчика на его рабочей машине "все собирается", а у другого тот же самый код упорно не хочет собираться и ужасно ругается. После изнурительных разборов оказывается, что первый доставил себе какую-то библиотеку и забыл ее включить в репозиторий. Это правило не дает подобному случится (ну случится-то случится, но исправления будут происходить куда как быстрее). Если говорить коротко, то сборки продуктов должны проходить на системе, которая повторяет окружение основной производственной системы.

5. Быстрая сборка.

Условие, которое гласит так: время собирания проекта не должен занимать времени более, чем теоретическое количество времени между коммитами в команде разработки. Причина - сама непрерывность сборки - т.е. основные сборки не должны становиться в очередь, а должны успевать собраться до следующего коммита изменений в репозиторий. В маленьких системах это не проблема, но если система большая, то процесс сборки разбивается на несколько частей - первая (занимающая менее 10 минут) - это основная компиляция и минимальный набор тестов, далее - уже более громоздкие тесты, которые можно убрать в бекграунд и поставить в очередь, и результаты неудачи по которым не будут критичными. Также здесь можно применить подход разделенной компиляции, где компиляция происходит по частям на разных серверах или персональных машинах.

6. Правила извещений и развертывания.

Описанные логические правила "если - то", по которым будет писаться скрипт/рецепт/конфигурация запуска сборки. Т.е. что необходимо делать при успешном/не успешном результате того или иного шага сборки (и всей сборки в целом) и кого нужно уведомлять. Почему это на мой взгляд является правилом описывает один из антипаттернов ниже.

Для себя я выделил некий список антипаттернов - то, чего стоит избегать настраивая у себя в проекте НИ. Некоторые из них встретил в процессе серфинга на тему, к сожалению обожженных хватает, другие в процессе настройки и использования практики НИ лично.

1. Молоток с тридцатью разными режимами работы.

Представьте что вы работаете в цеху, где собирают мебель из готовых компонентов. Задача работника цеха - забить гвоздь между двумя деталями. Вы просите молоток для забивания этого единственного гвоздя, а мега-продвинутый нач. цеха дает вам пятикилограммовый молоток с ручками и рычажками, который можно настроить на забивание чего угодно и где угодно (и в каких угодно условиях). Ваша реакция? Вот такая же будет реакция у человека, которому говорят что для непрерывных сборок проекта "Convert CSV 2 INI" поднят огромный CI сервер, чья проектная настройка включает в себя больше строк, чем строк в самом проекте. А ведь достаточно было написать python скрипт, который собирает и отправляет уведомления, и всем бы было хорошо. Помните, что цель должна оправдывать средства, и если есть способ "сделать это проще" при настройке НИ - делайте, не надо быть мега-продвинутым нач. цеха и закладываться на возможные условия работы при нулевой гравитации.

2. Редкая синхронизация кода.

Это когда разработка долгое время ведется вне ветки trunk. Это даже не антипаттерн CI, а антипаттерн в целом - чем более долгое время ветки не сливаются, тем более долгое время разработчики исправляют полученные конфликты и имеют много головной боли (и руководители вместе с ними). Решение очевидно - почаще сливайте ветки и не делайте "забытых" веток - за каждую ветку и за ее слияние должен кто-то отвечать.

3. Поврежденные сборки.

Чем больше неисправленных вовремя сборок, тем медленнее будет реакция на следующие поломки. Как я уже писал - первостепенная задача НИ - это максимально быстрое извещение о поломке. Если сборка не исправлена, значит все последующие тоже поломаны, а значит сама практика теряет свой смысл. Решение тоже исходит из названия - чините сборки в первую очередь с максимальным приоритетом - не откладывайте на завтра, потому как завтра ваш коллега зальет нормальные изменения и очень испугается, увидев поломку в своей ревизии.

4. Минимальная обратная связь.

Вот и добрались до того, о чем я писал выше. Стройте правильную схему уведомлений. Все участники должны получать ровно столько, сколько нужно. Этот антипаттерн обычно применяют когда "сверху" сказали настроить НИ, и тот, кто его настраивает не заинтересован в результате. Что-то там настроил, что-то там сделал, поставил одного себя в список на уведомления и забы(и)л. А разработчики даже и не подозревают, что сборки ломаются и что у них вообще есть настроенный сервер НИ. Вывод - сначала описываем условия и участников, потом настраиваем НИ.

5. Чрезмерная обратная связь.

Обратная сторона предыдущего антипаттерна. Когда информация льется рекой на всех - кто когда запустился, полные логи всех процессов, логи когда НИ ждал, и т.п. И в результате имеем переполнение буфера у разработчиков и полное игнорирывание уведомлений он НИ сервера. Лечится как и в предыдущем пункте.

6. Медленная система.

Если у вас серьезные проект, и время сборки уже существенно большое, то стоит пойти к начальству и попросить хорошее железо под ваш НИ сервер. Чем дольше выполняется сборка, тем дольше будут слатся уведомления, и тем медленнее будет реакция разработчиков.

7. Перегруженная сборка.

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

Вот пока и все. Надеюсь эта информация хоть кому-то пригодится.

Постараюсь выкладывать дополнительную информацию по НИ в дальнейшем, есть много удобных под-практик которые можно использовать и получать от этого еще более сильное удовольствие.

Надеюсь увидеть дополнительные комментарии кто еще с какими антипаттернами встречался с НИ.

Первый пост

2010-01-07T02:43:00.002+02:00

Тем, кто ценит свое время и зашел сюда почитать что-то, возможно для себя новое, предлагаю не тратить время на этот пост и на другие подобные с тегом (ярлыком) "болтовня". В подобных сообщениях я буду давать волю языку (пальцам) и писать всякую дребедень, практической пользы от которой нет. Потом не говорите, что я не предупреждал.

Так повелось, что в первом посте обычно пишут о том, что "вот наконец-то руки дошли до блога", что мол "давно хотел, но времени не было" и начинают вещать читателям о том, какие они умные/опытные/обиженные жизнью/просто фигню какую-нить (нужное подчеркнуть).Вот и мне бы хотелось, дорогие читатели, поумничать и по-чесняку объяснить зачем он (блог) мне нужен и какой направленности контент я в него буду постить. В заключении постараюсь прояснить некоторые нюансы, которые, как мне бы хотелось, вы держали в уме при прочтении блога и отдельных его постов.

Начнем с мотивационной стороны: что именно меня подтолкнуло на этот шаг? Зачем тратить время на писанину, которую возможно будут читать только несколько человек, и еще несколько будут тролить (да-да, я не зря разделил читателей, и тролей)? До недавнего времени я абсолютно не хотел (ну может чуточку) тратить время на заведение и поддержку своего блога, так как не видел в этом практического смысла. Излить душу можно и друзьям за чашкой чая. Запостить информацию по делу (связанную непосредственно с IT) лучше в корпоративную вики, где ее будут читать твои подчиненные, становится умнее, и от чего ты будешь получать непосредственную выгоду. Зарабатывать на рекламе? Увольте. Тратить уйму времени на раскрутку и придумывание контента (да, именно придумывание, ибо для того, что бы что-то крутилось надо это что-то обновлять, а мысли есть не всегда) что бы потом заработать на этом и сразу же потратить на хостинг и на раскрутку. Нет, меня на это долго не хватит.

Но музыка играла не долго. Я понимаю что у тебя, уважаемый читатель, сейчас буря эмоций: а как же банальная реклама? Как же нематериальные вложения? Увы, я пришел к этому только сейчас: я стал все чаще и чаще замечать, что если выбирать между двумя людьми, которые работают и что-то там делают, разговоры и взгляды ложатся именно на тех людей, которые вовремя смогли себя раскрутить. Замечают скорее не тех, кто много делает, а тех, кто еще и показывает свои мысли, выводы, и то, что он сделал, на всеобщее обозрение. Переломный момент - это пост Сергея (aka COTOHA) на дарвинистское видение на отношения работодателя и работовзятеля. Ведь действительно, чем ярче окраска, тем сильнее тебя видно. А чем сильнее тебя видно, тем больше на тебя цена. Теперь вот придется искать время на рекламу себя любимого, но кто знает, может это и принесет свои плоды.

Теперь про направленность информации, которую я собираюсь постить в этот блог. Пока я буду пользовать блоггер.ком, направленности будет две. Первая будет связанна с IT - в таких постах я буду стараться передавать максимум полезной информации, разбавленных шутками-прибаутками дабы не засыпали при прочтении. Я надеюсь что подобных постов будет подавляющее большинство. Второй тип: это посты, отмеченные тегом "болтовня" - там будет подобная этому посту вода, которую можно без зазрения совести пропустить и перейти к основным блюдам. Возможно как только осилю (хотя меня терзают смутные сомнения) подпилить вордпресс и перенести туда блог, появится третья направленность - личная, слезливо-сопливая, в которую я буду изливать душу и делиться самым сокровенным. Доступ будет ограничен, дабы не портить психику всему честному народу а напрягать только самых близких друзей. Но это пока так, только проект, и не факт что он будет реализован.

Теперь по поводу нюансов:

1. Все, что было и будет написано является моим личным мнением. Настоятельно не рекомендую абсолютно верить написанному, указывать меня как авторитетный источник или думать что-либо подобное. Если не уверенны, проверьте и, если я таки не прав, запостите коммент где именно и при каких обстоятельствах.

2. Думайте перед тем, как что-нибудь откомментировать. Тролей не люблю и не уважаю, вне зависимости от того, тролят сам пост или чей-то коммент.

А вообще я добрый и пушистый, и сегодня у меня свободный вечер и действительно нечего делать. Оттого я так и расписался тут.

А еще заметил что мода на латынь пошла. Так что revis esse laboro, obscurus fiо. Вот.