С непрерывной интеграцией связаны накладные расходы, например, настройка, переподготовка, действия по повышению осведомленности, прекращение работы по устранению «ошибок», которые, как оказывается, являются проблемами с данными, принудительное разделение задач по стилям программирования и т. Д.
В какой момент непрерывная интеграция окупается?
РЕДАКТИРОВАТЬ: Это были мои выводы
Настройка была CruiseControl.Net с Нант, чтение из VSS или TFS.
Вот несколько причин сбоя, которые не имеют ничего общего с настройкой:
Затраты на расследование . Время, затрачиваемое на выяснение того, вызван ли красный свет подлинным логическим несоответствием в коде, качестве данных или другом источнике, таком как проблема инфраструктуры (например, проблема в сети, чтение тайм-аута из системы контроля источников, стороннего сервера). вниз и тд и тп)
Политические затраты по сравнению с инфраструктурой : я подумал о проведении проверки «инфраструктуры» для каждого метода в тестовом прогоне. У меня не было решения для тайм-аута, кроме как заменить сервер сборки. Красная лента мешала, и не было никакой замены сервера.
Стоимость исправления юнит-тестов : красный индикатор из-за проблем с качеством данных может быть индикатором плохо написанного юнит-теста. Таким образом, зависимые от данных модульные тесты были переписаны, чтобы уменьшить вероятность красного света из-за неверных данных. Во многих случаях необходимые данные были вставлены в тестовую среду, чтобы можно было точно запустить ее модульные тесты. Имеет смысл сказать, что, сделав данные более надежными, тест становится более надежным, если он зависит от этих данных. Конечно, это сработало хорошо!
Стоимость покрытия, т. Е. Написание модульных тестов для уже существующего кода : возникла проблема покрытия модульными тестами. Существовали тысячи методов, у которых не было юнит-тестов. Таким образом, для их создания потребуется значительное количество человеко-дней. Поскольку это было бы слишком сложно, чтобы представить экономическое обоснование, было решено, что модульные тесты будут использоваться для любого нового общедоступного метода в будущем. Те, у кого не было модульного теста, были названы «потенциально инфракрасными». Интересным моментом здесь является то, что статические методы были спорным в том, как можно было бы однозначно определить, как конкретный статический метод потерпел неудачу.
Стоимость сделанных на заказ выпусков : Сценарии Nant идут только так далеко. Они не очень полезны, скажем, для зависимых от CMS сборок для EPiServer, CMS или любого ориентированного на пользовательский интерфейс развертывания баз данных.
Это типы проблем, которые возникали на сервере сборки для ежечасных тестовых прогонов и ночных сборок QA. Я считаю, что они не нужны, поскольку мастер сборки может выполнять эти задачи вручную во время выпуска, особенно с группой из одного человека и небольшой сборкой. Таким образом, одношаговые сборки не оправдали использование CI в моем опыте. А как насчет более сложных, многошаговых сборок? Это может быть трудно построить, особенно без сценария Нанта. Таким образом, даже создав их, они не были более успешными. Затраты на устранение проблем, связанных с красным светом, перевесили преимущества. В конце концов, разработчики потеряли интерес и поставили под сомнение обоснованность красного света.
Сделав честную попытку, я считаю, что CI стоит дорого, и есть много работы по краям вместо того, чтобы просто сделать работу. Более выгодно нанимать опытных разработчиков, которые не делают беспорядка в больших проектах, чем внедряют и поддерживают систему сигнализации.
Это так, даже если эти разработчики уходят. Неважно, уйдет ли хороший разработчик, потому что процессы, которым он следует, гарантируют, что он напишет спецификации требований, спецификации проекта, придерживается рекомендаций по кодированию и прокомментирует свой код, чтобы он был читабельным. Все это пересматривается. Если этого не происходит, то его руководитель не выполняет свою работу, которую должен взять его менеджер и так далее.
Для работы CI недостаточно просто писать модульные тесты, пытаться поддерживать полное покрытие и обеспечивать работающую инфраструктуру для значительных систем.
Итог : можно задаться вопросом, желательно ли исправление как можно большего количества ошибок до выпуска с точки зрения бизнеса. CI включает в себя большую работу по выявлению нескольких ошибок, которые клиент может идентифицировать в UAT, или компании могут заплатить за исправление в рамках соглашения об обслуживании клиента, когда гарантийный срок все равно истекает.