Мне нужна помощь с философией и дизайном непрерывной интеграции.
Наша текущая настройка CI использует buildbot. Когда я начинал проектировать его, я унаследовал (ну, не совсем так, как я был вовлечен в его проект годом ранее) сделанный на заказ конструктор CI, который был приспособлен для одновременного запуска всей сборки в одночасье. Через некоторое время мы решили, что этого недостаточно, и начали изучать различные инфраструктуры CI, в итоге выбрав buildbot. Одной из моих целей при переходе на buildbot (помимо получения удовольствия от всех дополнений, связанных со свистом) было преодоление некоторых недостатков нашего сделанного на заказ ночного строителя.
Забавьте меня на мгновение и позвольте мне объяснить, что я унаследовал. Кодовая база для моей компании - это почти 150 уникальных приложений Windows на c ++, каждое из которых зависит от одной или нескольких из дюжины внутренних библиотек (а также от сторонних библиотек). Некоторые из этих библиотек являются взаимозависимыми и имеют зависимые приложения, которые (хотя они не имеют ничего общего друг с другом) должны создаваться с использованием одной и той же сборки этой библиотеки. Половина этих приложений и библиотек считаются «устаревшими» и непереносимыми и должны быть построены с использованием нескольких различных конфигураций компилятора IBM (для которых я написал уникальные подклассы Compile), а другая половина построена с использованием Visual Studio.ShellCommandс, так как нет поддержки VSS).
Наш оригинальный ночной конструктор просто взял источник для всего и создал материал в определенном порядке. Не было никакого способа создать только одно приложение, выбрать ревизию или сгруппировать объекты. Было бы запущено виртуальных машин для создания ряда приложений. Это не было очень надежно, это не было распространяемым. Это не было ужасно растяжимо. Я хотел преодолеть все эти ограничения в buildbot.
Первоначально я делал это, создавая записи для каждого приложения, которое мы хотели построить (все 150 из них), затем создавал запускаемые планировщики, которые могли бы создавать различные приложения в виде групп, и затем объединял эти группы в общий планировщик ночных сборок. Они могут работать на выделенных подчиненных устройствах (больше не нужно заниматься виртуальными машинами), и, если я захочу, я могу просто добавить новых подчиненных. Теперь, если мы хотим выполнить полную сборку вне графика, это всего лишь один клик, но мы также можем создать только одно приложение, если захотим.
Однако у этого подхода есть четыре недостатка. Одним из них является сложная сеть зависимостей нашего исходного дерева. Чтобы упростить поддержку конфигурации, все сборщики создаются из большого словаря. Зависимости извлекаются и создаются не слишком ужасно (а именно, отключение определенных вещей в моем словаре целевых сборок). Во-вторых, каждая сборка имеет от 15 до 21 шага сборки, которые трудно просматривать и просматривать в веб-интерфейсе, а поскольку имеется около 150 столбцов, загрузка занимает вечность (от 30 секунд до нескольких минут). В-третьих, у нас больше нет автоматического обнаружения целей сборки (хотя, хотя один из моих коллег говорит мне об этом, я не вижу, что это нас привлекло в первую очередь). В заключение,
Теперь, переходя к новой разработке, мы начинаем использовать g ++ и subversion (не портируя старый репозиторий, обратите внимание - только для новых вещей). Кроме того, мы начинаем проводить больше модульного тестирования («больше» может дать неправильную картину ... это больше похоже на любое ) и интеграционное тестирование (с использованием Python). Мне трудно понять, как вписать их в мою существующую конфигурацию.
Итак, где я ошибся здесь с философской точки зрения? Как мне лучше всего двигаться дальше (с buildbot - это единственная часть головоломки, над которой у меня есть лицензия на работу), чтобы моя конфигурация в действительности поддерживалась? Как мне устранить некоторые недостатки моего дизайна? Что действительно работает с точки зрения стратегий CI для больших (возможно, чрезмерно) сложных баз кода?
РЕДАКТИРОВАТЬ:
Я думал, что объяснил свою проблему, но, очевидно, я не был достаточно ясен. Я не ищу предложений по изменению платформ CI. Этого не произойдет, и ответы, предполагающие, что не будут приняты. Я хочу знать, как другие люди управляют сложными кодами с помощью CI. У меня есть дюжина квадратов различных продуктов, и у меня есть зависимости, разбросанные по ветру, и все они разные. Это то, что я хочу знать, как иметь дело.