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

https://stackoverflow.com/questions/2523841

22-09-2019
|

Вопрос

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

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

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

Решение

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

От Википедия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow