Контроль версий для кода, который еще предстоит протестировать - PullRequest
Новая
       33

Контроль версий для кода, который еще предстоит протестировать

1 голос
/ 13 июля 2011

В моей команде дюжина инженеров, некоторые из которых работают над модулями, на создание которых уйдет 2-3 недели.

Теперь мы интегрируем каждый модуль в основную ветку CVS только после завершения модульного тестирования.

Проблема в том, что в течение хороших 2-3 недель код находится только на компьютере инженера и не контролируется версией.

Используемый язык программирования - C.

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

Спасибо

Джеймс

Ответы [ 3 ]

3 голосов
/ 13 июля 2011

Ваш процесс за 2-3 недели до регистрации в «основной» ветке не является нормой, как это было бы при аналогичном повторном проектировании «корневого канала» (серьезная работа по реструктуризации, которая иногданеобходимо).

Тем не менее, я бы очень нервничал из-за того, что столько времени находится вне контроля версий.

  1. Не кодируйте злой.
  2. Дон 't code drunk.
  3. Не кодируйте долгое время без «контрольной точки» контроля версий.

Настоятельная рекомендация заключается в том, что местный разработчик использует Mercurial или Git для локальныхконтроль версий в течение этих 2-3 недель, а затем вы можете проверить «завершенный» проект обратно в (основную) ветку CVS.Они действительно созданы для точно этого сценария.

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

(Для нас Mercurial локальный, Subversion - «основная» система контроля версий.)

2 голосов
/ 13 июля 2011
... в течение хороших 2-3 недель код находится только на компьютере инженера и не контролируется версией ...

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

В этом смысле я бы сказал, что любой другой подход, который каким-либо образом позволяет вашим разработчикам непрерывно держать свою работу под VC, был бы более элегантным , чем вообще ничего. Для этого существует много известных способов - поиск в Google для стратегии ветвления управления версиями 1010 * показывает множество ресурсов, объясняющих ваши варианты и критерии выбора.

Не экспериментируя, довольно сложно сказать, какой из этих вариантов лучше подходит для вашего проекта. При изучении ресурсов, на которые я ссылаюсь выше, я бы рекомендовал проверить детали того, что обычно называется Feature Branch . Эта стратегия довольно близко соответствует случаю, который вы описываете «модули, на выполнение которых уйдет 2-3 недели» - хотя я бы не поспорил, что он лучше всего подходит для вашей команды.

Обратите внимание, что, по крайней мере, для "внутренних" разработчиков необходимо иметь возможность использовать систему контроля версий, отличную от устаревшего и неудобного CVS.

1 голос
/ 13 июля 2011

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

Но если я вас неправильно понял, и это просто, что должна быть большая сессия тестирования , когда все сделано, ну, тогда это слишком плохо. Вы обязательно столкнетесь с досадными проблемами интеграции. Если вы не можете изменить эту политику, по крайней мере, иметь свой местный VCS. Кроме того, вы можете настроить с помощью переключателей «featureX_Enabled» и попытаться не забыть установить его на «0» при регистрации.

В любом случае, переключитесь на Git или Mercurial, их было бы гораздо менее болезненно использовать.

...