Няня вашей системы непрерывной интеграции

Одна из моих ролей в моей команде - это человек, занимающийся сборкой . Я отвечаю за поддержание / обновление наших сценариев сборки и за то, чтобы мы работали «гладко» на сервере непрерывной интеграции. Я обычно не возражаю против этой работы, хотя часто мне кажется, что я постоянно присматриваю за сервером CI.

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

Я знаю, что многие зрелые команды используют Непрерывную Интеграцию, но там не так много материала о хороших практиках.

Мои проблемы указывают на то, что наша непрерывная интеграция не очень зрелая, или это просто часть работы?

Каковы некоторые хорошие практики для подражания? Каковы характеристики зрелой непрерывной интеграции ?

Обновить

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

Читая ответы каждого, мы чувствуем две основные проблемы.

1. CI Server не выдает достаточно громких жалоб при сбое сборки.
2. Разработчики не считают своей обязанностью гарантировать, что их обязательства пройдут успешно.

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

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

Большинство CI-серверов (я использовал только Hudson) будут отправлять автоматические электронные письма с подробным описанием совершенных коммитов, которые привели к поломке сборки. Единственная часть вашей роли - стоять за ними, выглядя жестко, пока подозреваемый не исправит то, что сломал.

Ваша команда ошиблась в одном:

Быть ответственным за сервер сборки - это не то же самое, что отвечать за сборку .

Это обязанность человека, проверяющего код, заставить его «работать» (для некоторой ценности работы). Единственная причина наличия сервера сборки - это уловить упущения в этом процессе. Любой заслуживающий внимания сервер сборки может уведомить людей, которые зарегистрировались в коде с момента последней сборки (а также всех, кто интересуется), следующую информацию:

• Сборка сломалась!
• Что пошло не так при сборке!
• Что изменилось с момента последней сборки!

Это очень часто происходит по электронной почте. Важно, что это происходит довольно быстро после каждой регистрации.

Затем человек может увидеть, что пошло не так, и исправить это, а сервер сборки затем уведомить всех, кто заинтересован, что сборка вернулась в нормальное состояние. Это должно произойти само по себе без какого-либо участия других, кроме виновников регистрации.

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

Кроме того, если «странные условия существуют» случаются очень часто, выясните причину этого и сделайте систему более устойчивой.

Изменить процесс. Если коммит нарушает сборку, автоматически откатывает этот коммит и уведомляет разработчика, который его нарушил. Глупо допускать, чтобы ошибка одного члена команды замедляла работу остальной команды. Или вместо того, чтобы интеграционные сборки выполнялись автоматически, разработчики могут проверить машину интеграции, и, если сборка завершится успешно, они могут выполнить фиксацию. Непрерывная интеграция не означает «проверяйте, какой мусор вам нравится, и кто-то за вас это исправит».

Стратегия «золотой ветки» не работает, если не существует привратника для золотой ветви.

DVCS как Git может помочь; вместо фиксации разработчик может просто отправить набор изменений для интеграции на сервер CI, а затем сервер может попытаться интегрировать набор изменений. Если интеграция завершается успешно, набор изменений объединяется, а если нет, он отклоняется.

Одна проблема, которую я часто вижу, заключается в том, что разработчики не могут выполнить локальную сборку, которая имеет точно такие же шаги, как сборка CI. То есть сервер CI настроен на включение дополнительных шагов, таких как модульные / интеграционные тесты, покрытие и т. Д., Которые не могут быть выполнены локально. Неизбежно, что разработчики будут укушены одним из шагов, которые они не могут выполнить локально, и начнут сомневаться, почему они вообще не хотят создавать релиз локально до регистрации.

Я сохраняю всю свою сборку автономной, и сервер CI просто запускает сборку релиза без каких-либо дополнительных настроек / шагов. Разработчики могут выполнить сборку релиза локально до регистрации, которая включает в себя все шаги, которые будут выполняться сборкой CI, и быть гораздо более уверенными, что ничего не сломается, когда они выполнят регистрацию.

Дополнительные преимущества этого подхода включают в себя:

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

PS. вся концепция няни сборки нелепа, но другие это уже освещали.

Во-первых, разработчики не должны регулярно ломать сборки - они должны создавать и запускать тесты локально, прежде чем переходить в ветку CI. Это должно быть признаком позора, чтобы сломать сборку, и важно обеспечить это. Я сделал это, публикуя статистику, и видел, что у других команд есть «пакет сборки», в который вы вкладываете доллар каждый раз, когда ломаете сборку. В конце проекта эти деньги идут на пиво.

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

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

Я не могу рекомендовать книгу « Непрерывная доставка» . Если вы ищете руководство по совершенствованию процесса CI, попробуйте.

Я слышал о том, что делает Microsoft (может быть?), Которая заключается в том, чтобы роль сборочной няни в команде. То, как они это делают, заключается в том, что когда кто-то ломает сборку (что, вероятно, должно включать проверку чего-то, что не проходит тесты), он принимает на себя роль. Это делает людей ответственными за последствия своих действий самым непосредственным образом. И учитывая, что это несколько раздражающая работа, это побуждает их больше не ломать сборку.

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

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

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

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

Как сказал Джонатан Ку, вы все должны нести ответственность за сервер сборки и скрипт сборки. Есть три причины:

1. На данный момент у вас есть случай «Bus of 1», что означает, что если вас перебросит автобус, тогда все знания о сервере сборки и сценариях сборки будут потеряны.
2. Сценарии, которые были написаны вами (правильно или неправильно), имели только ваш вклад. Как и в любом другом коде, чем больше людей задействовано, тем шире база знаний, которую можно применить к нему.
3. Наконец, когда что-то идет не так, только ты чувствуешь боль. Боль это хорошо, но не тогда, когда она изолирована. В данный момент вы имеете дело с болью, но если бы у всех были боли, то вы бы обнаружили, что в конечном итоге они будут более жесткими в тестировании кода перед фиксацией.

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

1. Сценарии сборки должны выполняться не только на CI-серверах, но и на локальных машинах разработки. Они должны выдавать одинаковые выходные данные, запускать одинаковые тесты и давать сбой по тем же причинам. Это позволяет разработчикам запускать сценарий перед фиксацией их кода.
2. Если кто-то нарушает сборку, сделайте ее общедоступной, используя всплывающие окна в панели задач, электронные письма, мигающие огни, шумы и т. Д. Он служит не только для того, чтобы смущать членов команды, но и для всех остальных членов команды, что позволяет ему подпрыгивать и помощь.
3. Какое-то время избегайте исправления сборки. Получить кого-то еще, чтобы сделать это. Если никто больше не подпрыгивает, подождите, пока не произойдут плохие вещи, и используйте это как точку обучения для всей команды, чтобы понять, почему сервер CI важен.
4. Старайтесь, чтобы ваш сервер сборки и машины разработки были максимально лишены установленных сторонних компонентов, особенно содержите GAC в чистоте. Положитесь на сторонние компоненты, находящиеся в папке библиотеки проектов. Это помогает быстрее идентифицировать недостающие компоненты.

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

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

Catlight также покажет, кто первым сломал сборку, оказав социальное давление на этого человека, поскольку вся команда будет видеть это при каждом последующем сбое сборки.

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

Другой - повысить уровень ответственности людей. Например, если вы используете что-то вроде Ритвельда, тогда люди не смогут совершить коммит без прохождения экспертной оценки. (На практике этот процесс намного легче, чем вы думаете. Но он заставляет людей «работать» и работать над несколькими вещами одновременно.) Ответственность за сохранение сборки несут как коммиттер, так и рецензенты. Если кто-либо либо регулярно нарушает сборку, либо одобряет вещи, которые нарушают сборку, не позволяйте им давать окончательные одобрения для коммитов. Объедините его с процессом, в котором любой может легко откатить любое изменение, и сборка не будет ломаться так часто, и не останется сломанной после внесения изменения.

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

Имейте в виду вещи:

1. Вашей команде нужен набор стандартов, которым нужно следовать
2. Вы должны получить управление на борту с идеей чистого кода и стремиться к улучшению практики кода.
3. Тест тест тест! Всегда проверяйте, прежде чем проверить.
4. Хотя я согласен с тем, что можно сломать сборку, это редкий случай, и я имею в виду крайне редкий случай, который был бы приемлемым. Если это будет ежедневно, я буду искать дверь или говорить с моим боссом о стандартах.

В целом, вам, ребята, нужно установить, написать стандарты, основанные на лучших практиках, а не на ваших индивидуальных практиках (очевидно, они не работают). Когда все согласятся со стандартами, начните процесс проверки кода и обеспечения соблюдения стандартов. Похоже, что руководство ушло в отпуск и больше не вернулось. Это вещи, которые, честно говоря, довольно просты для любого магазина. Основа хорошего кода начинается с хороших стандартов, определяющих код команды и способ ее написания. Просто мои мысли. Недавно я попал в похожую ситуацию на своей новой работе, и я поговорил с моим боссом. Ему объяснили, что XYZ нужно завершить, потому что он влияет на ABC. Две недели спустя я написал список стандартов кода, которым нужно следовать, и представил его. Вслед за тем, что мои коллеги внесли свой вклад, и примерно через 2 месяца у нас были стандарты, которые разрешили тонны проблем.