Ответ 1

Я должен не соглашаться с идеями, что Предприятия боятся свободы или что они медленно меняются. Это может быть правдой, но использовать их для отклонения медленного уровня принятия git в пространстве Enterprise не учитывает то, что означает Enterprise. Кроме того, SVN довольно популярен и свободен.

Предприятие относится к централизации. Вы хотите, чтобы все ваши разработчики выполнили ту же процедуру, получили тот же код и т.д.

Эрик Синк более красноречив на эту тему, чем я мог бы быть: http://www.ericsink.com/articles/vcs_trends.html

Ответ 2

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

Конечно, мы, как технические эксперты, знаем, что нагрузка.

Ответ 3

По моему опыту, Предприятия имеют множество анти-тел против изменений

• Существующие навыки: если значительная часть команды обладает навыками существующих инструментов, они автоматически станут препятствием для их изменения, даже для лучших.
• Консолидированная стабильность: изменение всегда является проблемой с точки зрения миграции и стабильности. То, что в производстве "работает по своей природе", и каждое изменение всегда создает проблемы.
• Соответствие. Существующие инструменты были проанализированы и подтверждены корпоративной безопасностью ICT, а затем определены как "стандартные и совместимые" с процедурами компании. Что-то другое будет рассматриваться как потенциальный риск для безопасности.

IMHO, тогда проблема не GIT сама или управление распределенной версией: проблема в изменении SCM и перехода к чему-то неизвестному и потенциально "опасному" для набора правил Enterprise. Именно поэтому "антитела" вступают в игру, чтобы предотвратить какие-либо значительные изменения.

Более конкретно, в GIT, многие риски и угрозы предоставляют дополнительные аргументы против его принятия, связанные с тремя упомянутыми выше пунктами:

• Навыки: GIT отличается от любого другого SCM, используемого до сих пор. Именование двусмысленно и вводит в заблуждение ( "svn checkout" является "клоном git"... в то время как "git commit" не является "svn commit" )
• Консолидированная стабильность: GIT была очень неустойчивой до Ver. 1.6. Мы использовали его в Windows с Ver. 1.5, и это было настоящей болью, особенно с неопытными разработчиками.
• Соответствие: GIT не имеет принудительного исполнения по умолчанию и не дает четкого следа того, кто что сделал. Это "одноранговый", поэтому по своей природе он против централизованного контроля и аудита.

Я видел "анти-тела" в действии много раз до GIT:

• 1996: переход от RCS к CVS
• 2001: переход из SourceSafe в CVS
• 2005: переход из CVS в Subversion
• 2009: переход из Subversion в Git

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

После большой боли и усилий все эти миграции были в конечном итоге очень успешными! Я представил GIT на крупных предприятиях, таких как Vodafone Group Services в Великобритании и Германии. В любом случае, после болей и сопротивления изменение изменилось, а преимущества стали видимыми и уже обеспечили значительную рентабельность инвестиций с точки зрения эффективности, ловкости и контроля.

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

• CollabNet (http://www.collab.net) для принятия SubVersion с RBAC Безопасность
• GitEnterprise (http://www.gitenterprise.com) для GIT Предприятие соответствие SOX и CMMI
• Google (http://code.google.com/p/gerrit/) для обзора кода Gerrit внедрение и отслеживание изменений

В общем случае изменение - это самая дорогая, но БОЛЬШАЯ ВАЖНАЯ задача на крупном предприятии, прежде всего с точки зрения мышления людей.

Позвольте мне знать, что вы думаете о приёме GIT и корпоративных инструментов!

Luca/@lucamilanesio

Ответ 4

Некоторые из многих причин:

• Инерция: там огромное количество людей знакомо с централизованными системами. Вам не нужно "переучивать" разработчиков, если вы просто не меняете.

• Взаимодействие с другими инструментами: корпоративная среда, конечно, важна для дополнительных инструментов, таких как непрерывная интеграция, IDE, фейерверки и т.д. Естественно, там больше поддержки установленных централизованных VCS с теми, что с относительно новыми git и hg.

• Поддержка: когда вы покупаете коммерческий продукт VCS, вы не просто покупаете программу, вы покупаете спокойствие.

Конечно, я не говорю, что это веские причины; они просто убеждают людей, которые могут принять это решение. Я думаю, что стоит преодолеть инерцию - сейчас она требует работы, но она окупается позже. Я думаю, что внешние инструменты улучшаются при поддержке git, особенно с открытым исходным кодом - им просто нужны плагины. А что касается поддержки, мы все знаем, что в Интернете существует гораздо меньше формальной поддержки.

Действительно, есть общая мысль во всех этих вопросах - философия свободного программного обеспечения - это не то, как корпорации ведут бизнес. Покупка продукта установлена ​​и проста. Вы платите свои деньги, получаете то, что вам нужно. Управлению не нужно беспокоиться. Используя бесплатный программный продукт... ну, это может быть намного лучше, но с ним сложнее справиться. Он не входит в коробку.

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

Ответ 5

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

Еще одна причина, по которой я часто слышал, заключается в том, что интеграция IDE еще не достигла качества, например. CVS или Subversion. Хотя аргумент верен, он все чаще становится проблемой.

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

"Помимо того, что выбор уже сделан"

Эта часть заявления на самом деле слишком важна для игнорирования, поскольку она связана с кривой обучения любого конкретного инструмента. Обучение, например, SVN занимает некоторое время, а процесс обучения стоит денег в форме времени разработчика. Изучение git, по моему опыту, занимает больше времени и усложняется в отсутствие упрощенных интерфейсов (gittortoise ongoing development не выдерживает). Плюс Git имеет так много инструментов, что его кривая обучения действительно может считаться большей частью уклона обучения.

Выплата после преодоления кривой велика, но первоначальное требование является препятствием для принятия.

Ответ 9

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

Если вы привыкли к Subversion или похожим инструментам, таким как PVCS, то Git (и DVCS в целом) представляет собой значительный обучающий холм для поднятия - как на концептуальном уровне, так и на ежедневном рабочем процессе. В моем (несколько измученном) опыте многие предприниматели часто не желают вкладывать усилия в изучение нового инструмента или концепций; и я боюсь, что будет пытаться внедрить DVCS.

Прошу доказать, что я ошибаюсь

Ответ 10

Вот некоторые конкретные рекомендации. (читайте полный блог здесь).

Если у вас есть убедительные требования к одной, определенной, основной копии вашей работы, используйте Subversion. Вы можете сделать это с помощью Git, если нет проскальзываний. Но вы не можете делать что-либо еще с Subversion (slip-ups или no), а "неотразимые требования", такие как Sarbanes-Oxley, более счастливы с гарантиями, чем возможностями.

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

Ни один из них? Возьмите свой выбор, вы должны быть в порядке с любым инструментом.

Ответ 11

Часть трудности связана не с системой, а с организацией рабочих.

SVN легко понять и использовать но лучше, если использовать для нескольких разработчиков, работающих с одной ветвью (или головой)

Git - хорошая идея, но реализация очень отвратительна и требуется много времени и работы, чтобы сделать что-то так же просто, как вставить свой проклятый код!

мы все еще ждем DECENT DVCS...