Сколько разработчиков до непрерывной интеграции станет для нас эффективным?

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

В какой момент непрерывная интеграция окупается?

РЕДАКТИРОВАТЬ: Это были мои выводы

Настройка была CruiseControl.Net с Нант, чтение из VSS или TFS.

Вот несколько причин сбоя, которые не имеют ничего общего с настройкой:

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

Политические затраты по сравнению с инфраструктурой : я подумал о проведении проверки «инфраструктуры» для каждого метода в тестовом прогоне. У меня не было решения для тайм-аута, кроме как заменить сервер сборки. Красная лента мешала, и не было никакой замены сервера.

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

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

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

Это типы проблем, которые возникали на сервере сборки для ежечасных тестовых прогонов и ночных сборок QA. Я считаю, что они не нужны, поскольку мастер сборки может выполнять эти задачи вручную во время выпуска, особенно с группой из одного человека и небольшой сборкой. Таким образом, одношаговые сборки не оправдали использование CI в моем опыте. А как насчет более сложных, многошаговых сборок? Это может быть трудно построить, особенно без сценария Нанта. Таким образом, даже создав их, они не были более успешными. Затраты на устранение проблем, связанных с красным светом, перевесили преимущества. В конце концов, разработчики потеряли интерес и поставили под сомнение обоснованность красного света.

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

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

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

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

Настройка CI-двигателя сродни настройке пожарной сигнализации в доме.

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

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

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

Это также является частью обеспечения качества.

РЕДАКТИРОВАТЬ: После написания выше, у меня был опыт работы с инструментом сборки Maven для Java. По сути, это позволяет нам сохранить полную конфигурацию CI внутри проекта (с pom.xml), что значительно упрощает поддержку установки CI и / или миграцию на другой механизм CI.

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

1: проверка кода
И
n: наличие устанавливаемых \ развертываемых пакетов

Если n <2, возможно, вам не нужен CI
, вам нужен CI

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

Это может стоить усилий даже для команды из одного человека. Это особенно верно, когда вы разрабатываете кроссплатформенный код и вам нужно убедиться, что ваши изменения будут работать на обеих платформах. Например, компилятор Microsoft C ++ более приемлем, чем GCC, поэтому, если вы разрабатываете в Windows, но также должны поддерживать Linux, наличие системы CI сообщит вам, когда перерывы в сборке в Linux - огромная помощь.

Некоторые CI-системы довольно просты в настройке, поэтому накладные расходы не так уж велики. Попробуйте Дженкинс или Хадсон, например.

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

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

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

На этой неделе я создал Jenkins для создания небольшого проекта .NET, над которым я работаю. Я интегрировал его с управлением исходным кодом Git, чтобы он запускал сборку при каждом коммите. Я интегрировал юнит-тесты в сборку. Я интегрировал статический анализ в виде нарушений FxCop и StyleCop.

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

Выполнение этого с нуля занимает час или около того (возможно, один день с Google, если вы не сделали этого раньше). Это ничего не стоит, потому что все инструменты доступны бесплатно.

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

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

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

Во всех остальных случаях это чистый выигрыш.

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

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

На вопрос, когда КИ окупается, трудно ответить на новый проект.

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

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

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

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

Всегда используйте его, независимо от размера команды. Если, например, только вы, кто знает, возможно, вы пишете код со своего ноутбука в Starbucks, а затем продолжаете работать в своей более мощной системе дома?

Накладные расходы не так уж и плохи.

Один. Да, достаточно начать использовать непрерывную интеграцию.

Дело не в том, сколько разработчиков, а в

а. Сколько времени вы экономите с помощью автоматизации и как часто.

• Время, сэкономленное на сборке после интеграции, выполнении автоматических тестов и создании настроек * частота регистрации = процент сэкономленного времени.

б. Сколько версий / веток / продуктов у вас есть.

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