Бизнес-кейс для децентрализованных систем контроля версий

26

Я искал и не смог найти никаких деловых причин, почему системы git / mercurial / bazzr лучше, чем централизованные системы (subversion, performance).

Если вы пытаетесь продать DVCS нетехническому лицу, какие аргументы вы бы привели для увеличения прибыли DVCS .

Вскоре я передам git своему менеджеру, это займет некоторое время на конвертирование репозиториев Subversion и некоторые расходы на покупку лицензий smartgit.

Редактировать Я попытался сделать этот вопрос в общую дискуссию по централизованному против децентрализовано, но неизбежно он превратился в мерзавец против подрывной деятельности. Конечно, есть лучшие централизованные системы, чем Subversion.

Keyo
источник
1
Мы находимся в аналогичном положении, когда рассматриваем вопрос, и, надо сказать, я не уверен, что он сейчас есть.
Джон Хопкинс
Может git-svnудовлетворить ваши потребности?
Дж.Б. Уилкинсон
@JBRWilkinson Я только что использовал git-svn для переноса множества репозиториев в git. Компания не вкладывает много средств в инструменты, которые интегрируются с SVN, поэтому это не было большой проблемой.
Кейо
Пересмотрите редактирование - вы все еще не объяснили, как и почему SVN подводит вас так, что вы чувствуете, что вам нужна замена. Мой ответ (например) НЕ о git vs svn, а о поиске экономического обоснования для изменения статус-кво.
Мерф

Ответы:

23

Хм, будучи менеджером, у меня есть две немедленные реакции "коленного рефлекса" на это:

  • Если у вас нет веских причин, почему вы предлагаете что-то еще, кроме того, чтобы быть модным?
  • Точно так же, как Subversion терпит неудачу так, что вам нужна замена?

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

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

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

Может случиться так, что все, что вы хотите сделать, это запустить git локально на своей машине как «лучший» клиент Subversion (я смотрю на это с помощью Mercurial).

Хм, может быть, весь этот ответ на самом деле комментарий? Вы должны изложить свое мнение здесь (в вопросе) для git over subversion (в вашей среде), чтобы узнать, можем ли мы помочь вам определить экономическое обоснование.


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

Murph
источник
1
Решение проблем с разрешениями и гибкостью: вам все еще нужен репозиторий «источник», где вы можете установить права как обычно. Непрерывная интеграция выполняется для исходного репозитория, разработчики клонируют исходный репозиторий и т. Д. Однако его резервное копирование менее важно, поскольку у каждого есть клон, а не просто извлечение.
Матье М.
1
Пункт о том, что полные клоны являются резервными копиями, хорошо сделан Я свободно признаю, что есть некоторые области этого, которые я недостаточно хорошо понимаю, так как мои «рабочие» вещи - svn, а мои ртутные - личные и, пока, несколько ограниченные.
Murph
14

Я бы сказал, что быстрое и безболезненное ветвление и слияние позволят разработчикам более продуктивно работать со своим кодом, поскольку каждая новая функция может быть разветвлена, а затем объединена. Заставить процесс разработки идти намного более гладко. Кроме того, распределенная природа позволила бы каждому разработчику иметь полную копию кода, поэтому не стоит беспокоиться о сбое централизованного сервера, что приведет к удалению всего вашего кода. Вероятно, есть и другие причины, однако эти две являются моими основными причинами использования Git.

mbreedlove
источник
2
В бизнес-среде «централизованный сервер» будет иметь резервирование, резервное копирование и администраторов, ответственных за поддержание его (и всех других серверов) в живых.
JBRWilkinson
2
В большой бизнес-среде у вас будет избыточность сервера. В малом бизнесе такая избыточность серверов не так уж и очевидна.
Майкл Шоу
2
Отказ централизованного сервера не уничтожил бы весь ваш код. Даже если у вас не было резервных копий, худшее, что он может сделать, это снять историю изменений. Но пока у всех разработчиков есть проверенный код, он существует в текущей форме и в их системах.
Мейсон Уилер
1
@mason: но это довольно предположение: «до тех пор, пока все разработчики ...». Потому что в небольших компаниях с еще более мелкими проектами проекты могут существовать и успешно использоваться без того, чтобы кто-то программировал их в течение года или два
Инка
А также, я бы не стал недооценивать ценность истории коммитов. В огромной системе очень полезно увидеть, кто и почему что-то сделал с кодом.
Тамас Селей
8

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

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

Anon.
источник
Это то, что я собирался опубликовать, в значительной степени. Вы наверняка должны увидеть улучшения производительности от разработчиков, которые рано и часто подключаются к своему собственному репозиторию, не создавая проблем для своих коллег.
Carson63000
5
Тогда вы будете в аду интеграции, когда в конце концов начнете продвигать свои изменения. Это плохо, а не хорошо.
Генри
Поскольку вы выполняете локальную разработку с большим количеством коммитов, вы можете продолжать извлекать изменения из центрального репозитория и поддерживать свои локальные изменения в соответствии с текущей разработкой, над которой работают другие. Таким образом, когда придет время перенести ваши изменения в центральное хранилище, у вас уже должно быть большинство изменений, которые там произошли, и интеграция будет легкой.
DaveJohnston
1
Если один из ваших коллег не сделал то же самое, и вы оба не интегрировались довольно долго. Всегда есть компромисс. Я видел случаи, когда вещи были интегрированы на основной линии, где их не должно было быть (неправильное решение, тупиковая попытка решения и т. Д.), Интеграция при полноте функций также имеет свои преимущества.
Joppe
2
Разве вы не можете делать все это с (а) ветвями SVN или (б) несколькими рабочими копиями?
JBRWilkinson
4
  • Отделение-за ошибки
  • Уменьшенная задержка ваших различий.
  • Возможность очень быстро произвольно перемещаться по истории ветки, когда вы рецензируете.
  • У вас все еще есть доступ ко всей истории, когда у вас нет доступа к централизованному серверу: вы не в офисе, питание просто отключилось, но батарея вашего ноутбука все еще работает, ...

Эти вещи позволяют вам работать более эффективно, как в одиночку, так и в команде. Более эффективная работа = более быстрое время разработки = более быстрое время выхода на рынок = прибыль.

Фрэнк Шиарар
источник
3

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

Не стесняйтесь понижать голосование, если вы не находите их уместными.

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

Карл Билефельдт
источник
Ваши записи в блоге хорошо написаны. Я еще не прочитал их все. Интересно, почему вы выбрали Bzr, когда Git и Hg кажутся гораздо более популярными. Люди, кажется, ненавидят Bzr за медлительность. Я также фанат Git из-за хешей дерева вместо номеров ревизий, что мне кажется очень безопасным. Не будут ли номера bzr rev полностью перемешаны при объединении веток?
Кейо
2
@Keyo, я выбрал bzr, потому что мне пришлось преподавать DVCS для себя, а bzr - самый дружественный новичку. С тех пор я переключился на мерзость для скорости, функций и стабильности. Bazaar также хэширует свои ревизии и имеет глобально уникальные идентификаторы, они просто не предоставляются пользователю по умолчанию. Их номера ревизий не действительно не отличается от использования HEAD~1, HEAD~2и т.д. в мерзавец. Очень редко вам нужен настоящий хеш, но это первое, что вы изучаете в git, и оно всегда перед вами. Скрытие этого от пользователя, если оно вам действительно не нужно, является одной из причин, по которой bzr более дружелюбен к новичкам.
Карл Билефельдт
Благодарю за разъяснение. Git был не совсем легким для меня выходом из subversion. Многие команды имеют одно и то же слово, но делают разные вещи.
Кейо
2

Мои аргументы в пользу DVCS таковы:

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

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

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

По сути, речь идет о снижении трения. Для этого есть термин: муда . Чем больше трения, тем больше боли это делать. Чем больше боли, тем меньше делается, тем меньше прибыли.

Пол Натан
источник
2

Я прошу прощения, если я нахожусь в покое, но позвольте мне изложить экономическое обоснование недвусмысленно

SVN делает жизнь разработчиков несчастной . И это делает бизнес программного обеспечения несчастным.

... способами, которые многие не осознают, пока не начнут использовать DVCS. Это самое важное экономическое обоснование, которое может быть сделано . Зачем? Что ж, по сравнению со стоимостью поиска и удержания хороших разработчиков стоимость перехода на DVCS практически не существует .

Учтите следующее:

  • Все операции, кроме самых простых в SVN (и большинстве других CVCS), требуют доступа к сети. В большинстве DVCS доступ к сети происходит только при выполнении операции pushили pullоперации. Это означает, что нетривиальные команды работают медленно . Что вы делаете, когда команда принимает навсегда? Я лично захожу на сайт programmers.se или хакерские новости, пока жду. Проще говоря, DVCS позволяют программистам сосредоточиться на том, что они любят: написание программного обеспечения компании .
  • SVN поддерживает ветвление во многом таким же образом, как в тюрьмах есть возможность бросать мыло в душ: вы можете это делать, но когда вы это делаете, вас трахают. Таким образом, SVN заставляет ваших разработчиков постоянно бороться друг с другом за внесение изменений .
  • Когда SVN не работает, он не работает. Разработчикам становится очень трудно выполнять свою работу, если они вообще могут ее выполнять. Таким образом, SVN заставляет ваших разработчиков полагаться на то, что ваша инфраструктура на 100% не содержит ошибок .
  • В наши дни git быстро завоевывает популярность, а SVN быстро теряет его. Если использование DVCS по сравнению с SVN не дает никаких преимуществ, почему сообщество программистов меняется так быстро, как только может?

Что все это значит? Я еще не встречал разработчика, который дал честную попытку DVCS, который впоследствии предпочел бы SVN. Если бы я мог сделать еще одно раздражающее, смелое утверждение, SVN - это «необходимое зло», которое разработчики заставляют себя использовать. Git - это инструмент, который делает разработчиков более продуктивными и счастливыми .

(Я должен отметить, что выделенные жирным шрифтом выражения являются именно теми, на которых вы должны сосредоточиться. Остальные из них просто предоставляют контекст.)

Джейсон Бейкер
источник
5
-1 - вы играете на публику, и хотя в том, что вы пишете, есть доля правды, она вращается настолько негативно, что оказывается на грани FUD, а не на основе обоснованного анализа. SVN медленный? Только если хранилище обширно и сеть ледниковая. Прекращает ли я работу SVN из-за неработоспособности, не могу вспомнить, чтобы он когда-либо был недоступен, и НЕТ, поскольку мой компьютер не зависит от существования хранилища для редактирования / компиляции / запуска исходного кода. Плохо ли ветвление и слияние SVN? Ничего себе, у людей короткие воспоминания ... почему DVCS завоевывает популярность? Неразбериха функциональности - которая улучшается - и, честно говоря, мода.
Мерф
1
@ Мёрф - нравится вам это или нет, люди ненавидят перемены до такой степени, что они становятся вялыми . Чтобы убедить их измениться, вам нужно убедить их, что статус-кво нарушен. И это будет сломано. FUD плохо только тогда, когда нет причин бояться, сомневаться и сомневаться. Что касается ума, я согласен с вами. Но дело не в этом. Согласны ли с этим люди, принимающие решения. И каждый менеджер, которого я когда-либо встречал, был убежден этим аргументом (даже если они ненавидят мерзавца).
Джейсон Бейкер
2
Я не обязательно не согласен с тобой, Джейсон, просто предполагаю, что твои замечания не очень хорошо сформулированы. В частности, я думаю, что вы преувеличиваете из-за эффекта, и если вас поймают на этом, вы склонны терять очки за свои аргументы, даже если вы правы. (За исключением тех моментов, в которых вы, конечно, ошибаетесь ... (
:)
2
Все ваши точки зрения являются вопросами мнения, а не фактами. Я бы перечислил каждое, но в комментариях недостаточно места. Как насчет того, чтобы ответить еще раз без выдачи?
Генри
1
@Henry - Programmers.se для субъективных вопросов и ответов. Субъективно == вопрос мнения.
Джейсон Бейкер
1

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

Brainlag
источник
2
Конечно, но Subversion в основном работает и без сетевого подключения. (Очевидно, что не фиксация, но обычные вещи, такие как получение информации о рабочей копии или различие с базовой ревизией, все работают.)
j_random_hacker
@j_random_hacker: Смысл VCS - отслеживать изменения кода. Фиксация отслеживает изменения кода. Если вы не можете зафиксировать в автономном режиме, я бы сказал, что ваша VCS не работает в автономном режиме.
Дейнит
1

Разница показывает, когда есть проблемы

Мы перешли на git 6 месяцев назад после портирования нашего десятилетнего репозитория.

До сих пор, после небольшого эксперимента, я нашел следующее:

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

  • более надежный дизайн - вы не полагаетесь на доступность центрального сервера на 100%, а если это не так, вы можете временно рекламировать любой клон в качестве горячей замены. Это устраняет критическую точку отказа - если сервер SVN выходит из строя по какой-либо причине, никто не может выполнять работу SVN. Если по какой-либо причине центральный репозиторий git выходит из строя, вы все равно можете работать и выполнять push / pull локально, чтобы гарантировать репликацию коммитов. Вы даже можете иметь несколько сторонних репозиториев именно для этой цели.

  • взаимодействие с хранилищем упрощено. Для CVS вам по сути нужен доступ все время, когда вам нужна какая-то часть информации. Для git локально доступен весь репозиторий, что позволяет многим вещам идти быстрее.

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

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


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

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

Допустим, у вас есть несколько программистов, работающих над улучшением производительности приложения, и они находятся на экспериментальной стадии и не знают, будет ли когда-либо написанный ими код частью ветки master / trunk. Однако им нужно часто обмениваться кодом друг с другом и опробовать идеи, которые могут оказаться в тупике. Как вы справляетесь с такими частыми ветвлениями и слиянием в Subversion? Короткий ответ: вы этого не делаете. С dvcs это действительно легко, и программисты могут быстро опробовать новые идеи в ветках и поделиться с другими, прежде чем решить, будет ли эта идея реализована.

jshen
источник
-1

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

Майкл Шоу
источник