Как организована непрерывная интеграция в крупных компаниях?

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

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

development-process continuous-integration large-scale-project

— Мегамозг
источник

см Почему мы не поддержка клиентов для [вашей любимой компании]

— комар

@gnat Вы адекватны? Как это связано? Я попросил об инсайдерском опыте и указал компании, например. Я не просил поддержки клиентов.

— Мегамозг

@gnat Я не понимаю, как это связано с этим. Мегамозг: CI организован по модулю проектов, нет модуля с 1000 разработчиков. Поэтому, если людей слишком много, сократите ваш проект / модуль на меньшую часть.

— Вальфрат

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

— gnat

@gnat Я действительно не понимаю, как применялась предоставленная вами ссылка, особенно с комментарием, который вы предоставили в ответ на Walfrat. Исходя из этого комментария, это ИМХО будет правильной ссылкой (часть о вопросах типа опроса) softwareengineering.meta.stackexchange.com/a/6490

— Newtopian

Ответы:

Это, в основном, проблема масштабирования. Вы разделяете свою работу на модули, которые могут быть разными проектами и / или разными функциями вашего продукта.

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

Основной цикл CI, скорее всего, будет отличаться от циклов CI командного уровня в следующих аспектах:

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

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

— Владимир Стокич
источник

В дополнение к тому, что сказал @Vladimir_Stokic, в некоторых командах (у меня ~ 150 разработчиков) мы собираем чаще, чем каждые 24 часа. Всякий раз, когда происходит фиксация, мы запускаем 5-минутный таймер. После истечения 5 минут все коммиты, которые произошли в течение 5-минутного интервала, объединяются и строятся. Сборка обычно является инкрементной сборкой. У нас есть отдельный компоновщик, который запускает модульные тесты для каждой происходящей сборки. После того, как сборка завершена, если во время сборки было больше коммитов (что занимает от 1 до 45 минут, в зависимости от того, что изменилось), создаются все ожидающие изменения и так далее. У нас также есть ночная (чистая, полная) сборка, но сборки, которые происходят при каждой фиксации (грубо), очень быстро сообщают нам, провалились ли какие-либо тесты.

— user1118321
источник