Использование CI для построения взаимозависимых проектов в изоляции - PullRequest
0 голосов
/ 30 апреля 2018

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

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

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

Это приводит к большому количеству писем о сломанных сборках (по одному для каждого проекта), даже если последний набор изменений ничего не сломал! Когда я поднял эту проблему, мне сказали, что это известная проблема, и CI-сервер «несколько раз перестроит вещи для определения зависимостей!»

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

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

Кажется, я не могу убедить их, что это A Bad Thing . Итак, что мне здесь не хватает?

Спасибо!

Мир!

1 Ответ

0 голосов
/ 01 мая 2018

Я второе ваше мнение.

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...