Аргументы для создания снимков против локально компилируемого кода?

Question

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

Проблема в том, что всякий раз, когда другой разработчик передает код в отдельный проект от того, над которым я работаю, я должен обновить код и пересобрать его локально, чтобы убедиться, что я компилирую по последней версии. Это включает ожидание в течение 30-60 минут каждый раз, чтобы проверить изменения кода.

Мы бы хотели запускать все проекты из файлов 'моментальных снимков', поэтому каждый раз, когда происходит изменение кода, наши локальные сборки должны просто загружать последние снимки.

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

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

Answer 1

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

Это заставляет задуматься о несовместимых изменениях API, а также приводит к явным конфликтам в управлении версиями при фиксации компонента, который больше не будет компилироваться.

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

Answer 2

Действительно ли часовой код действительно нарушит условия сделки, если он будет обновлен? Если только не произойдут серьезные изменения или изменения, я не смогу понять, как одно изменение сломает все остальное.

Я также вижу, что ваша текущая ситуация состоит в том, чтобы скомпилировать все зависимости для каждой сборки, что занимает около 30-60 минут. Разве не было бы неплохо скомпилировать ваш проект с использованием самой последней из доступных сборок, что может занять около 5-10 минут, а затем продолжить программирование?

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