Какова рентабельность непрерывной интеграции?

Question

В настоящее время наша организация не практикует непрерывную интеграцию.

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

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

Answer 1

Моя # 1 причина, по которой мне нравится CI, заключается в том, что она помогает разработчикам не проверять неработающий код, который иногда может нанести вред всей команде. Представьте себе, если я сделаю серьезную регистрацию, включающую некоторые изменения схемы БД, прямо перед тем, как уйти в отпуск. Конечно, все отлично работает на моем компьютере разработчика, но я забыл проверить сценарий изменений схемы БД, который может быть или не быть тривиальным. Что ж, теперь есть сложные изменения, относящиеся к новым / измененным полям в базе данных, но никто, кто находится в офисе на следующий день, на самом деле не имеет этой новой схемы, так что теперь вся команда не работает, пока кто-то изучает воспроизведение уже проделанной вами работы просто забыл проверить.

И да, я использовал особенно неприятный пример с изменениями в БД, но на самом деле это может быть что угодно. Возможно частичная регистрация с некоторым кодом электронной почты, который тогда заставляет всех ваших разработчиков спамить ваших реальных конечных пользователей? Вы называете это ...

Так что, на мой взгляд, если вы избегаете ни одной из этих ситуаций, рентабельность инвестиций от таких усилий ОЧЕНЬ быстро окупается.

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

• Сэкономит ли это? может быть нет,
• Проект провалится во время UAT? определенно НЕТ,
• будет ли проект закрыт между? - высокая вероятность того, что клиенты обнаружат, что это не ожидаемый результат.
• Получите ли вы в режиме реального времени и реальные данные о проекте - ДА

Так что это помогает быстрее проваливаться, что помогает снизить риски раньше.

Answer 9

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

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