Как мы должны решать большие изменения в нашем приложении?

Question

У нас есть это огромное приложение, которое имеет 18 проектов в нашей системе контроля версий ( VSS ).

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

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

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

Как мы должны планировать разработку такого рода функций?

Answer 1

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

Ваша компания будет жить лучше с Subversion. Попробуйте!

Сервер Простота установки в любой системе (Windows / Linux)

TortoiseSVN Клиент для Windows, который интегрируется в Windows Explorer

Руководство по SVN Прочитайте, по крайней мере, первые несколько глав

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

Answer 2

Рассматривали ли вы обмен и ветвление? Кроме того, вы можете разрешить несколько проверок с пользователями, которые имеют опыт работы. В вашем случае внесения значительных изменений в приложение я предлагаю создать метку, а затем создать ветку. Если что-то случится с «большими изменениями», у вас не будет рабочей версии. Вы можете внести свои быстрые исправления в выпущенный код, а затем объединить их в «большие изменения», как только он будет готов. Проверьте раздел справки «Совместное использование и ветвление».

Answer 3

Если обновление до реальной VCS сейчас не вариант, попросите человека, выполняющего основную функцию, загрузить локальную копию всего и затем внести свои изменения вне контроля версий. Объедините все сразу (на выходных или в случае чего-то сложного).

Это не поможет разработчику, которому понадобится контроль версий при внесении «больших изменений»

Ну, ты делаешь то, что должен делать с инструментами, которые у тебя есть. Он всегда мог установить современный VCS, такой как git, который работает локально. Просто проверь всю базовую линию в git (за исключением истории) и иди.

Answer 4

VSS отстой , перейдите на настоящий SCM, Microsoft, вероятно, поможет вам легко перейти на TFS, у которой нет этой проблемы. Или перейдите на любую из FOSS SCM, такую ​​как subversion, но переход, вероятно, будет сложнее (но может быть и дешевле).

Answer 5

В долгосрочной перспективе вы захотите перейти на другую VCS. Как уже упоминали другие, рассмотрите либо с открытым исходным кодом или TFS, если вы хотите придерживаться MS. (Мы используем TFS, но я не буду его хвалить - все нормально.) Как уже упоминал AMissico, ветвление поможет с любой VCS, которая его поддерживает. Научиться эффективно использовать ветвление не тривиально и потребует обучения и / или обучения.

Непрерывная интеграция также поможет. TeamCity - это то, что мы используем, и его относительно просто настроить. См. FeatureBranch .

Answer 6

У вас уже есть совет по переходу на работающую VCS.

Кроме того, вы и разработчики должны научиться разбивать большие изменения на более мелкие. Я бы посчитал около 10 коммитов в день и полный рабочий день разработчика нормальным тарифом. Это делает замки намного менее болезненными.

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

В случае, если вы набросали. Добавление параметра в один слой и изменение всех вызовов этого уровня (возможно, с фиктивным значением) будет одним изменением. На самом деле, используя это значение, было бы другое изменение.

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

Answer 7

VSS - это просто старая история, сейчас мы используем Subversion (сервер) и TortoiseSVN (клиент). (Это только на основе наших предпочтений) Кстати, переход на другой контроль версий / только контроль версий - не решит проблему вашей команды. Проблема в общении. Если она не может общаться с остальными и остается в привычке (работая с большим количеством файлов, не проверяя их), она уволит вашу команду, вы должны дать ей знать, как работать с командой с помощью контроля версий. Если нет, она поставит вас в проблему «слияния» при использовании Subversion. ^^

Answer 8

SVN - ответ на ваши проблемы. Я использовал его, и его ветер учиться / работать с ним. Но на блоке есть несколько новых детей. Попробуйте GIT . Я много слышал об этом, хотя у меня не было возможности попробовать это

Answer 9

Используйте систему контроля версий, которая работает в режиме слияния (оптимистично), а не в режиме блокировки.

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

Примером системы контроля версий, которая может работать в режиме слияния, является CVS. Сейчас он устарел, но существуют и другие.