Системы управления распределенной версией и Enterprise - хорошая смесь?

Ответ 1

В этом случае я только что представил DVCS (Git) в крупной банковской компании, где Perforce, SVN или ClearCase были централизованными VCS вариантов:
Я уже знал о проблемах (см. Мой предыдущий ответ Можем ли мы наконец перейти к DVCS в корпоративном программном обеспечении? Является ли SVN еще "обязательным для разработки?" )

Я был оспорен на трех фронтах:

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

• аутентификация: DVCS позволяет вам "подписаться" (зафиксировать) ваш код как... почти любой (автор "foo", email "[email protected]" ).
  Вы можете сделать git config user.name foo или git config user.name whateverNameIFeelToHave, и в нем все ваши фиксации с фиктивным именем.
  Это не очень хорошо сочетается с уникальным централизованным справочником пользователей Active Directory, используемым крупными предприятиями.

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

Ответ (для установки Git) был:

• централизация: для любого репозитория должен быть установлен уникальный сервер для всех пользователей.
  Резервное копирование заботится (инкрементный каждый день, полный каждую неделю).
  DRP (план аварийного восстановления) был реализован со вторым сервером на другом сайте и с репликацией данных в режиме реального времени через SRDF.
  Эта настройка сама по себе не зависит от типа ссылочного или необходимого инструмента (DVCS, Nexus repo или основного планировщика Hudson или...): любой инструмент, который может иметь решающее значение для выпуска в производство, должен быть установлен на серверах с резервным копированием и DR.

.

• аутентификация: только два протокола позволяют пользователям получать доступ к основным репозиториям:
  • ssh, с открытым/закрытым ключом:
    • полезен для пользователей, внешних по отношению к организации (например, оффшорная разработка),
    • и полезно для общих учетных записей, которые менеджер Active Directory не хочет создавать (поскольку это будет анонимная учетная запись): реальный человек должен нести ответственность за эту общую учетную запись, и это будет тот, кто владеет закрытый ключ
  • https-based, с аутентификацией пользователей Apache через параметр LDAP: таким образом, фактический логин должен быть предоставлен для любой операции Git в этих репозиториях.
    Git предлагает его с smart http protocol, позволяя не просто pull (читать) через http, но также push (писать ) через http.

Элемент аутентификации также усилен на уровне Git с помощью post-receive, который гарантирует, что по крайней мере один совершает то, что вы нажимаете на У репо есть "имя коммиттера", равное имени пользователя, обнаруженному через протокол shh или http.
Другими словами, вам необходимо правильно настроить ваш git config user.name, или любой щелчок, который вы хотите сделать для центрального репо, будет отклонен.

.

• авторизация: обе предыдущие настройки (ssh или https) подключены для вызова того же набора perl script, с именем gitolite, с параметрами:
  • фактическое имя пользователя, обнаруженное этими двумя протоколами
  • команда Git (клон, push или pull), который пользователь хочет сделать

gitolite perl script будет анализировать простой текстовый файл, где авторизации (доступ для чтения/записи для всего репозитория или для ветвей в данном репозитории или даже для каталогов в репозитории).
Если уровень доступа, требуемый командой Git, не соответствует ACL, определенному в этом файле, команда отклоняется.

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

Тогда и только тогда DVCS (Git, Mercurial,...) может добавить значения из-за:

• обмен данными между несколькими сайтами: пока эти пользователи проходят аутентификацию через один и тот же Active Directory, они могут быть расположены по всему миру (компании, с которыми я работал, имеют разработки, обычно между командами через две или три страны). DVCS, естественно, предназначен для обмена эффективными данными между этими распределенными командами.

• репликация по средам: настройка, обеспечивающая аутентификацию/авторизацию, позволяет клонировать эти репозитории на других выделенных серверах (для тестирования интеграции, тестирования UAT, предпроизводственного и предварительного развертывания )

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

  • различные задачи (unit test или статический анализ кода)
  • возврат к основному репо, если эти задачи успешны.
  • пока вы все еще работаете в первом репо, не дожидаясь результата этих задач.

.

• функции убийцы: любой DVCS поставляется с теми, главная из которых - слияние (когда-либо пытались сделать сложный процесс слияния с SVN? Или sloooowly объединить 6000 файлов с помощью ClearCase?).
  Только это (слияние) означает, что вы действительно можете использовать ветвление, одновременно имея возможность объединить ваш код с другой "основной" линией разработки, потому что вы будет делать это:
  • сначала локально внутри вашего собственного репо, не нарушая никого.
  • затем на удаленном сервере, нажав результат этого слияния на центральное репо.

Ответ 2

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

Ответ 3

DSCS имеют лучшую историю (как правило), чем централизованные системы для автономных или медленных сетей. Они, как правило, быстрее, что действительно замечательно для разработчиков (с использованием TDD), которые выполняют множество проверок.

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

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

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

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

Ответ 4

Как минимум с tfs 2013 у вас есть возможность работать отключенными локальными рабочими пространствами. Распределенная и централизованная определяется бизнесом и зависит от потребностей и требований разрабатываемых проектов.

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

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

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

http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx

Ответ 5

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

Из коробки Git не предоставляет никаких разрешений - у вас есть крючки для написания собственных.

Большинство популярных менеджеров репо GithubEnterprise, Gitlab, Bitbucket предоставляют отраслевые ограничения на запись. Гитолит позволяет быть более зернистым, предоставляя пути (и более) основанные на записи ограничения.

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

Ответ 6

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

Работа отключена также является огромным плюсом.

Ответ 7

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

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

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

• Эти команды могут иметь свои собственные центральные хранилища с собственными механизмами автоматизации сборки/проверки.
• Они могут работать в любом месте и делать резервную копию своей локальной работы, когда захотят.
• Затем они могут выбрать те проверки, которые они хотели бы разделить между группами.
• У них может быть один индивидуальный интегратор, работающий на собственной машине, выполняющий слияние, без, влияющий на других.

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

Ответ 8

Наша команда использовала TFS около 3 лет, прежде чем переключиться на Mercurial. Поддержка ветвления/слияния HG намного лучше, чем TFS. Это связано с тем, что DVCS полагается на безболезненное слияние.

Ответ 9

Улучшенная синхронизация между удаленными/отключенными местоположениями.