Насколько подходит DVCS для корпоративной среды?

Question

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

Компания, в которой я работаю, является довольно стандартной компанией, где мы все работаем в одном месте (или иногда дома), и мы хотим сохранить центральный склад всего кода.

Мой вопрос: если все, что вы делаете с DVCS, - это создание центрального концентратора, к которому каждый вносит свои изменения, есть ли какая-то польза от перехода на DVCS и его дополнительные издержки в такой среде?

Answer 1

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

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

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

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

(К вашему сведению: автономные коммиты запланированы для Subversion 1.8)

Answer 2

Сотрудники DVCS могут поддерживать свои собственные локальные ветви без внесения каких-либо изменений в центральный репозиторий и помещать свои изменения в главный репозиторий, когда они думают, что он готов. Наш проект хранится в SVN-репозитории, но лично я использую git-svn для управления своими локальными изменениями и считаю его весьма полезным, поскольку нам не разрешено сразу же отправлять все изменения (они должны быть предварительно утверждены интегратором).

Answer 3

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

Я думаю, что одно это преимущество стоит того, чтобы перейти на DVCS.

Однако, использование DVCS требует немного больше обдумывания и понимания, и использование «стандартной» системы управления версиями, такой как SVN или CVS, поэтому вам нужно будет учесть затраты на обучение, если переход на DVCS или ваш центральный репозиторий закончится полно разных веток, люди не осознавали, что создают.

Answer 4

Лично я считаю, что это огромная выгода. Даже с центральным репо, DVCS меняет поток с «редактировать код, обновлять с центрального, фиксировать» на «редактировать код, фиксировать, выдвигать на центральное». Среди прочего, это означает, что разрешение конфликтов гораздо менее напряженно. Это также может стимулировать разработку небольшими порциями, так как вам не нужно нажимать после каждого коммита. Если с вашей командой все в порядке, это означает, что ваши отдельные коммиты могут оставить приложение в странном состоянии, пока оно работает, когда вы наконец продвигаетесь к центральному репо. Если они не согласны с этим, пока вы используете git (или очереди исправлений для hg, IIRC), вы все равно можете сделать dev в том же стиле, но затем сконденсировать все ваши меньшие коммиты в один больший коммит, который завершается, прежде чем вы отправите его в центральный репо.

Answer 5

Вы скоро начнете неизбежную войну против Git против Mercurial ... :-) Я лично использую Mercurial, но то, что я должен сказать, должно подходить для всех DVCS.

На мой взгляд, да, они подходят для корпоративного использования. Я использую их в своей собственной компании, хотя с небольшим количеством разработчиков, использующих его, но если вы беспокоитесь о масштабируемости, посмотрите на большие проекты с открытым исходным кодом, используя git и mercurial, например, Mozilla, Python.

Подход с центральным концентратором работает хорошо - это знакомая рабочая модель для пользователей Subversion, и у вас всегда есть «окончательная» версия. Заблокируйте доступ к этому и примените все ловушки для применения политик коммитов, и после этого разработчики получают большую свободу работы с локальными копиями так, как им нравится.

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

Что сложнее с DVCS, это управление бинарными файлами - вам не требуется блокировка бинарного файла, как при использовании Subversion (среди прочих). Управляйте этим с помощью коммуникации в идеале.

Наконец, клонирование репозитория отлично подходит для синхронизации проверок, если вы работаете с нескольких компьютеров.

Надеюсь, это поможет. K

Answer 6

По моему опыту, существует несколько способов использования DVCS в корпоративной среде:

• Поддержка нескольких сайтов: вы разделили команды и используете DVCS для настройки разных «серверов» в каждом месте, чтобы они не ограничивались основными сетевыми проблемами (и, поверьте мне, будут ). Раньше это делалось с «большими вещами», такими как Clearcase Multi-site или Wandisco (для SVN / CVS), но теперь это вполне выполнимо с системами DVCS.

• Поддержка "роуминговых пользователей": вы корп. разработчик, но вы хотите работать дома в течение определенного времени (или когда-либо): вместо того, чтобы полагаться на VPN, вы можете иметь DVCS на своем ноутбуке, и тогда вы будете свободны для фиксации, просмотра, различий, ветвления и объединения без замедления вниз центральным сервером. Вы синхронизируете данные, когда находитесь в сети или возвращаетесь в офис.

• Истинная «распределенная разработка»: это крайний случай: каждый разработчик имеет свою собственную DVCS (как вы делали бы в мире OSS). Это будет действительно зависеть от навыков и мотивации команды: если команда действительно хочет в нее войти, она выиграет, иначе это будет кошмар SYSADM, когда придется управлять не одним репо, а сотнями ... с соответствующими проблемами.

Answer 7

Лично я считаю, что наибольшим преимуществом DVCS является то, что вы фиксируете (локально) перед слиянием, поэтому если в середине процесса слияния оно окажется более сложным, чем вы изначально думали, вернуться к чистому состоянию без тривиального потерять свою работу. сравните с CVCS, где вам обычно нужно успешно объединиться, прежде чем вы сможете совершить коммит.

дополнительные преимущества включают в себя:

• Работа на дому / на сайте клиентов становится проще, так как вам не требуется подключение к сети, чтобы просто что-то проверить, и если вы ждете, пока база вернется, чтобы отправить изменения, история будет сохранена, а не сведена все в одно изменение.
• Большинство операций DVCS на самом деле намного быстрее, так как им не нужно передавать данные по сети
• Некоторые вещи (например, скрипты пользовательских настроек) лучше распространять напрямую между разработчиками, которые хотят поделиться ими, а не через центральное местоположение

Answer 8

Даже при работе с концентратором DVCS дает вам возможность делать небольшие коммиты локально, объединять их только тогда, когда вы хотите, и толкать их, когда они готовы.

С не-DVCS вы вынуждены либо:

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

И если вы исследуете тупик без DVCS: с первым методом вы не сможете перемотать назад, у вас нет коммита, к которому можно вернуться; со вторым все ваши коммиты и их возвраты должны были быть бессмысленно объединены всеми остальными.

Answer 9

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

все, что вы делаете с DVCS, - это создание центрального концентратора, который каждый вносит в

.

тогда вы на самом деле не пользуетесь основной целью DVCS, и я бы сказал, что SVN достаточно.

P.S. Можно также привести аргумент, что DVCS поощряет пользователей чаще совершать коммиты, поскольку они могут делать это в своем личном репозитории и публиковать свои изменения только тогда, когда они готовы & mdash; но это может быть легко достигнуто в SVN с использованием веток, с единственным «недостатком» является то, что «персональные» коммиты увеличивают номер версии всего хранилища.

Answer 10

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

Также DVCS обеспечивает естественный рабочий процесс разработки, когда требуется обязательная проверка кода перед тем, как новые изменения будут переданы в транк. Этот рабочий процесс (в отношении SVN) блестяще описан в статье UQDS . И несмотря на то, что в статье описан рабочий процесс на основе SVN, вы увидите, что это более естественно, когда вы используете DVCS вместо SVN, потому что в DVCS ветвление и слияние являются основной первоклассной операцией.