Каков ROI непрерывной интеграции?

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

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

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

Вот как я научился это объяснять: «Непрерывная интеграция исключает из вашего проекта целые классы рисков».

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

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

1. Риск интеграции: в системе сборки, основанной на непрерывной интеграции, такие проблемы интеграции, как «он забыл проверить файл перед тем, как отправиться домой. длинные выходные »гораздо реже могут привести к тому, что вся команда разработчиков потеряет всю пятничную работу. Экономия на проекте, позволяющая избежать одного такого инцидента = количество человек в команде (минус один из-за злодея, который забыл зарегистрироваться) * 8 часов в рабочий день * почасовая ставка на инженера. Здесь это тысячи долларов, которые не будут списаны с проекта.ROI Win!
2. Риск регресса: с помощью набора модульных / автоматических тестов, который запускается после каждой сборки, вы уменьшаете риск того, что изменение кода приведет к поломке того, что используется для работы. Это гораздо более расплывчато и менее уверенно. Тем не менее, вы, по крайней мере, предоставляете структуру, в которой одни из самых утомительных и трудоемких (т. Е. Дорогостоящих) человеческих тестов заменяются автоматизацией.
3. Технологический риск: непрерывная интеграция также дает вам возможность опробовать новые технологические компоненты. Например, мы недавно обнаружили, что обновление 18 Java 1.6 дает сбой в алгоритме сборки мусора во время развертывания на удаленном сайте. Благодаря непрерывной интеграции мы были уверены, что откат к обновлению 17 с высокой вероятностью сработает, а обновление 18 - нет. Такого рода вещи гораздо сложнее сформулировать в терминах денежной стоимости, но вы все равно можете использовать аргумент риска: определенный провал проекта = плохо. Изящное понижение рейтинга = намного лучше.

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

Вот твой номер.

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

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

Из Википедия :

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

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

С точки зрения разработчика, CI может напугать, когда результат автоматической сборки, отправленный по электронной почте всему миру (разработчикам, менеджерам проектов и т. Д.), Говорит: "Ошибка в загрузка сборки DLL с 'XYZ.dll' не удалась. " и вы мистер XYZ, и они знают, кто вы :)!

Вот мой пример из моего собственного опыта ...

Наша система имеет несколько платформ и конфигураций, и более 70 инженеров работают над одной и той же кодовой базой. Мы пострадали от примерно 60% успеха сборки для менее часто используемых конфигураций и 85% для наиболее часто используемых. Ежедневно шел постоянный поток электронных писем об ошибках компиляции или других сбоях.

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

После развертывания стойки со сборочными серверами, управляемой Team City, мы теперь видим средний показатель успешности 98% для всех конфигураций, средняя ошибка компиляции остается в системе в течение нескольких минут, а не часов, и большинство наших инженеров теперь могут спокойно оставаться в системе. последняя редакция кода.

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

Наше самое большое преимущество - это постоянная ночная сборка для QA. В нашей старой системе каждый продукт, по крайней мере, раз в неделю, обнаруживал в 2 часа ночи, что кто-то проверил неверный код. Это не привело к тому, что для тестирования QA не нужно было проводить ночные сборки, было отправлено электронное письмо с разработкой релиза. Они диагностируют проблему и связываются с разработчиком. Иногда у QA действительно было, с чем поработать до полудня. Теперь, помимо того, что каждую ночь у нас есть хороший установщик, мы фактически устанавливаем его на виртуальные машины всех различных поддерживаемых конфигураций каждую ночь. Так что теперь, когда приходит QA, они могут начать тестирование в течение нескольких минут. Теперь, когда вы думаете о старом способе, QA пришел, схватил установщик, запустил все виртуальные машины, установил его, а затем начал тестирование. Мы экономим QA, вероятно, 15 минут на каждую конфигурацию для тестирования, на человека QA.