Я вижу, почему распределенные системы управления источниками (DVCS - как Mercurial) имеют смысл для проектов с открытым исходным кодом.
Но имеют ли они смысл для предприятия? (через централизованную систему управления источниками, такую как TFS)
Какие особенности DVCS делают его лучше или хуже подходит для предприятия со многими разработчиками? (над централизованной системой)
В этом случае я только что представил 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) был:
.
pull (читать) через http, но также push (писать ) через http.Элемент аутентификации также усилен на уровне Git с помощью post-receive, который гарантирует, что по крайней мере один совершает то, что вы нажимаете на У репо есть "имя коммиттера", равное имени пользователя, обнаруженному через протокол shh или http.
Другими словами, вам необходимо правильно настроить ваш git config user.name, или любой щелчок, который вы хотите сделать для центрального репо, будет отклонен.
.
gitolite perl script будет анализировать простой текстовый файл, где авторизации (доступ для чтения/записи для всего репозитория или для ветвей в данном репозитории или даже для каталогов в репозитории).
Если уровень доступа, требуемый командой Git, не соответствует ACL, определенному в этом файле, команда отклоняется.
Выше описано, что мне нужно реализовать для параметра Git, но что более важно, в нем перечислены основные проблемы, которые необходимо решить для настройки DVCS, чтобы иметь смысл в большой корпорации с уникальной базой пользователей.
Тогда и только тогда DVCS (Git, Mercurial,...) может добавить значения из-за:
обмен данными между несколькими сайтами: пока эти пользователи проходят аутентификацию через один и тот же Active Directory, они могут быть расположены по всему миру (компании, с которыми я работал, имеют разработки, обычно между командами через две или три страны). DVCS, естественно, предназначен для обмена эффективными данными между этими распределенными командами.
репликация по средам: настройка, обеспечивающая аутентификацию/авторизацию, позволяет клонировать эти репозитории на других выделенных серверах (для тестирования интеграции, тестирования UAT, предпроизводственного и предварительного развертывания )
автоматизация процессов: легкость, с которой вы можете клонировать репо, также может использоваться локально на одной пользовательской рабочей станции, для целей тестирования модулей с помощью методов "охраняемых коммитов" и других умных использует: см. "Какое самое умное использование исходного репозитория, который вы когда-либо видели?.
Короче говоря, вы можете нажать на второе местное репо, отвечающее за:
.
Чтобы добавить к другим комментариям, я бы заметил, что нет причин, по которым вы не можете иметь корпоративный центральный репозиторий. Технически это просто еще один репозиторий, но это тот, с которого вы отправляете продукцию. Я использую ту или иную форму VCS уже более 30 лет, и я могу сказать, что переход на Mercurial был таким же, как городской мальчик, дышащий чистым воздушным воздухом в первый раз.
DSCS имеют лучшую историю (как правило), чем централизованные системы для автономных или медленных сетей. Они, как правило, быстрее, что действительно замечательно для разработчиков (с использованием TDD), которые выполняют множество проверок.
Централизованные системы несколько легче понять первоначально и могут быть лучшим выбором для менее опытных разработчиков. DVCSes позволяют создавать множество мини-ветвей и изолировать новые функции, сохраняя при этом проверку красного-рефакторинга на зеленый стиль кодирования. Опять же, это очень мощная, но только привлекательная для довольно опытных групп разработчиков.
Наличие единого центрального хранилища для поддержки эксклюзивных блокировок имеет смысл, если вы имеете дело с файлами, которые не сжимаются, как цифровые активы и нетекстовые документы (PDF файлы и Word и т.д.), поскольку это мешает вам запутаться и слить вручную.
Я не думаю, что количество разработчиков или размер кодовой базы играет в этом так много, обе системы демонстрируют поддержку больших деревьев источников и числа коммиттеров. Однако для больших кодовых баз и проектов DVCS дает большую гибкость в быстром создании децентрализованных удаленных веток. Вы можете сделать это с помощью централизованных систем, но вам нужно быть более преднамеренным, что хорошо и плохо.
Короче говоря, есть некоторые технические аспекты, которые следует учитывать, но вы должны также подумать о зрелости вашей команды и об их текущем процессе вокруг SCCS.
Как минимум с tfs 2013 у вас есть возможность работать отключенными локальными рабочими пространствами. Распределенная и централизованная определяется бизнесом и зависит от потребностей и требований разрабатываемых проектов.
Для корпоративных проектов возможность подключения рабочего процесса и документов к изменениям кода может иметь решающее значение для подключения бизнес-требований и элементов более высокого порядка к конкретным изменениям кода, которые затрагивают конкретные изменения, ошибки или добавление функций.
Это соединение между документооборотом и репозиторием кода отделяет TFS от решений только для репозитория кода. Для некоторых мест, где требуется более высокий порядок аудита проекта, только такой продукт, как TFS, удовлетворяет требованиям аудита проекта.
Обзор процесса управления жизненным циклом приложения можно найти здесь.
http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx
Самой большой проблемой, с которой мы сталкиваемся с Git в настройках предприятия, является отсутствие контроля доступа на основе пути. Он присущ архитектуре Git (и я бы предпочел большинство DVCS), что, если вы получили доступ к доступу к репозиторию, вы получите все это. Но иногда для проекта требуется редкая проверка (т.е. Вы хотите, чтобы данные контроля над версией были близкими к источнику, или вы хотите дать третьему лицу выборочный вид части проекта).
Из коробки Git не предоставляет никаких разрешений - у вас есть крючки для написания собственных.
Большинство популярных менеджеров репо GithubEnterprise, Gitlab, Bitbucket предоставляют отраслевые ограничения на запись. Гитолит позволяет быть более зернистым, предоставляя пути (и более) основанные на записи ограничения.
Единственным менеджером репо, который я слышал о поддержке доступа к чтению, является Perforce Helix, которая перегружает протокол Git поверх бэкэнда perforce, но у меня нет практического опыта с ним. Это многообещающе, но я был бы обеспокоен тем, насколько совместим он с "обычным" git.
Для меня самая большая вещь, которую они предлагают - скорость. Они на порядок быстрее для наиболее распространенных операций, чем централизованное управление источниками.
Работа отключена также является огромным плюсом.
Абсолютно распределенная модель источника может иметь смысл на предприятии, но она зависит от структуры ваших команд.
Управление распределенным источником дает вам гибкость для создания собственных рабочих процессов.
Представьте себе, если хотите, более крупную команду, в которой работают небольшие команды, работающие над отдельными ветвями функций.
Это то, что вы могли бы достичь с помощью традиционного централизованного сервера, но, как указывает @Brook, централизованная модель должна масштабироваться, тогда как распределенная модель уже, поэтому нет (или, по крайней мере, меньше) нужно вертикально масштабировать любые серверы.
Наша команда использовала TFS около 3 лет, прежде чем переключиться на Mercurial. Поддержка ветвления/слияния HG намного лучше, чем TFS. Это связано с тем, что DVCS полагается на безболезненное слияние.
Улучшенная синхронизация между удаленными/отключенными местоположениями.