Причины использования «Git» на предприятии - PullRequest
15 голосов
/ 29 марта 2010

Недавно я использовал коммерческую централизованную систему контроля версий в крупной компании с около 100 различными подсистемами, написанными на разных операционных системах и языках, и я заметил, что несколько разработчиков используют git или mercurial в своих любимых проектах, но для их систем работы. Лично я более знаком с git, но мне было интересно, по каким причинам они «не» используют Git на предприятии, за исключением того, что выбор уже сделан (у нас много проблем с нашей централизованно управляемой системой версий, поэтому я могу не сказать, что это блестяще).

Обновление

Мир действительно изменился с тех пор, как я написал это. Рассматриваемая компания, которая фактически запретила Git в то время, теперь использует Mercurial в качестве предпочтительной системы

Ответы [ 11 ]

15 голосов
/ 29 марта 2010

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

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

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

12 голосов
/ 29 марта 2010

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

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

8 голосов
/ 12 апреля 2012

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

  1. Существующие наборы навыков : если большая часть команды имеет навыки по существующим инструментам, они автоматически станут препятствием для их изменения, даже для лучших.
  2. Консолидированная стабильность : изменения - это всегда боль с точки зрения миграции и стабильности. То, что находится в производстве, «работает от природы», и каждое изменение всегда создает проблемы.
  3. Соответствие : существующие инструменты были проанализированы и утверждены Enterprise ICT Security, а затем определены как «стандартные и соответствующие» процедурам компании. Все остальное будет рассматриваться как потенциальная угроза безопасности.

ИМХО тогда проблема не в самом GIT или распределенном контроле версий: проблема заключается в изменении SCM и переходе к чему-то неизвестному и потенциально «опасному» для набора правил Enterprise. Вот почему «антитела» вступают в игру, чтобы предотвратить любые существенные изменения.

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

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

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

  • 1996: миграция с RCS на CVS
  • 2001: переход с SourceSafe на CVS
  • 2005: переход с CVS на Subversion
  • 2009: миграция с Subversion на Git

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

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

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


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

Дайте мне знать, что вы думаете о внедрении Git и Enterprise Tools!

Luca / @ lucamilanesio

7 голосов
/ 29 марта 2010

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

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

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

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

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

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

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

5 голосов
/ 29 марта 2010

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

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

4 голосов
/ 29 марта 2010

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

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

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

2 голосов
/ 29 марта 2010

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

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

1 голос
/ 23 августа 2012

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

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

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

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

1 голос
/ 30 марта 2010

Существенным практическим препятствием для принятия предприятия, помимо отсутствия централизованного контроля и интеграции, как упомянул Эрик, является «простота использования».

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

Пожалуйста, докажите, что я не прав

1 голос
/ 29 марта 2010

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

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

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

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