Передача взломанного кода в репозиторий в целях резервного копирования его
Я просто говорил с другим разработчиком (более старший, чем I) и пытался убедить его, что мы должны реализовать непрерывную интеграцию через Круиз-контроль. Он сказал мне, что это не будет работать, потому что он фиксирует код, который не компилирует в репозиторий все время в целях создать резервную копию его. И тот автоматизированные сборки, уведомляющие нас относительно отказов, были бы просто шумом.
Передача мусора к repo звучит плохой мне. Но я был в замешательстве слов и не знал, что сказать. Какова альтернатива? Какова лучшая практика для резервного копирования Вашего кода другой машины, не добавляя набор бессмысленных изменений?
BTW, наша система управления версиями является SVN, и это, вероятно, не изменится в ближайшее время.
5 ответов
Разрабатывайте ветки и фиксируйте готовые к тестированию и, надеюсь, рабочие ветки в основной строке. Пусть сервер непрерывной интеграции зависит от основной линии (в svn чаще всего называется магистралью) для создания и проверки новых ревизий.
Если вы регистрируете неработающий код в ветке, которую, как ожидается, будут использовать другие разработчики, и не поддерживаете связь по этому поводу, и делают это для некоторых веская причина ... ну, ваш коллега не следует лучшим практикам.
Взаимоприемлемая передовая практика может заключаться в том, чтобы требовать, чтобы проверки «разрыва сборки» типа «резервное копирование» выполнялись в частной ветке кода разработчика, а также всякий раз, когда код находится в состоянии, которое не нарушит сборку или модульные тесты, он объединяется с основной веткой, за которой наблюдает круиз-контроль.
Если только он не является единственным разработчиком в ветке (что звучит так, как будто это не так), ему не следует совершать повторный взлом кода. Существуют десятки решений для «резервного копирования» кода в разработке, в том числе просто создание частной ветви текущей строки или написание небольшого скрипта, который создает резервную копию рабочего каталога на файловом сервере.
Как именно компилируют все остальные в вашей команде, если он проверяет код, который не компилируется?
Вообще, я думаю, что это фальшивка - проверять код в вашей основной ветке, который не компилируется; это очень неучтиво по отношению ко всем остальным, кто рассчитывает на то, что сможет получить последнюю версию из контроля исходников и собрать.
В TFS есть несколько хороших функций для решения этой проблемы (shelve/unshelve); не уверен, есть ли они в SVN. В большинстве случаев, когда кто-то работает над огромным изменением и ему нужно иметь возможность проверить неработающий код, лучше сделать ответвление, а изменения слить в основную линию.
Используйте git для локальных резервных копий / истории и инструменты git-svn для проверки только рабочих версий.