Прерывание сломанного кода в хранилище с целью его резервного копирования

Я просто разговаривал с другим разработчиком (старше меня) и пытался убедить его, что мы должны внедрять непрерывную интеграцию через Cruise Control. Он сказал мне, что это не сработает, потому что он совершает код, который не компилируется в хранилище все время для целей его резервного копирования. И автоматические сборки, сообщающие нам об отказах, будут просто шумом.

Мне кажется, что компрометировать репо. Но я был в недоумении и не знал, что сказать. Какая альтернатива? Какая наилучшая практика для резервного копирования вашего кода на другой машине без добавления пустых бессмысленных версий?

BTW, наша система управления версиями SVN и, вероятно, не изменится в ближайшее время.

Ответ 1

Разработка в ветких и готовность к тестированию и, надеюсь, рабочих ветвей в основную линию. Пусть сервер непрерывной интеграции зависит от основной строки (в svn чаще всего называется trunk) для новых изменений для сборки и проверки.

Ответ 2

Как точно компилируются все остальные члены вашей команды, если он проверяет код, который не компилируется?

В общем, я думаю, что это faux-pas для проверки кода в вашей основной ветке, которая не компилируется; это действительно не учитывает всех, кто рассчитывает на то, что сможет получить последние данные от источника управления и сборки.

У TFS есть некоторые интересные функции, которые помогут решить эту проблему (shelve/unshelve); не уверен, что SVN делает или нет. Большую часть времени, когда кто-то работает над огромными изменениями, и они должны иметь возможность зарегистрировать сломанный код, лучше разветкиться и объединить изменения в основной строке.

Ответ 3

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

Взаимоприемлемой лучшей практикой может быть требование о том, чтобы проверки "брандмауэр" типа "break the build" выполнялись в частной ветке разработчика, и всякий раз, когда код находится в состоянии, которое не будет прерывать сборку или модульные тесты, он объединяется с ветвью ствола, которую наблюдает Cruise Control.

Ответ 4

Если он не является единственным разработчиком на ветке (что звучит так, как будто это не так), то он не должен отказывать в нарушении кода. Существуют десятки решений для "резервного копирования" кода в разработке, включая создание частной ветки текущей строки или запись небольшого script, который поддерживает рабочий каталог на файловом сервере.

Ответ 5

Используйте git для локальных резервных копий/истории и git -svn-инструментов для проверки только рабочих версий.