Распределенные системы контроля версий и предприятие - хорошее сочетание?
Я понимаю, почему распределенные системы контроля версий (DVCS - как Mercurial) имеют смысл для проектов с открытым исходным кодом.
Но имеют ли они смысл для предприятия? (через централизованную систему контроля источников, такую как TFS)
Какие функции DVCS делают его лучше или хуже подходит для предприятия со многими разработчиками? (по централизованной системе)
9 ответов
Я только что представил DVCS (в данном случае Git) в крупной банковской компании, где Perforce, SVN или ClearCase были централизованным выбором VCS:
Я уже знал о проблемах (см. Мой предыдущий ответ " Можем ли мы наконец перейти на DVCS в корпоративном программном обеспечении? SVN все еще необходимо для разработки? ")
Мне бросили вызов по трем направлениям:
централизация: хотя у децентрализованной модели есть свои достоинства (и она позволяет осуществлять частные коммиты или работать без сети, имея доступ к полной истории), все же необходимо иметь четкий набор централизованных репозиториев, выступающих в качестве основного ориентира для всех разработчиков.
аутентификация: DVCS позволяет вам "подписать" (зафиксировать) ваш код как... практически любой (автор)
foo", Эл. адрес "foo@bar.com").
Вы можете сделатьgit config user.name foo, или жеgit config user.name whateverNameIFeelToHaveи все ваши коммиты с поддельным именем.
Это плохо сочетается с уникальной централизованной пользовательской ссылкой Active Directory, используемой крупными предприятиями.авторизация: по умолчанию вы можете клонировать, передавать из любого хранилища или извлекать его, а также изменять любую ветвь или любой каталог.
Для чувствительных проектов это может быть проблемой блокирования (банковский мир обычно очень защищает некоторые алгоритмы ценообразования или квантов, которые требуют строгого доступа для чтения / записи для очень ограниченного числа людей)
Ответ (для настройки Git) был:
- централизация: для любого репозитория был установлен уникальный сервер, доступный для всех пользователей.
Забота о резервном копировании (добавочный каждый день, полная каждую неделю).
DRP (План аварийного восстановления) был реализован со вторым сервером на другом сайте и с репликацией данных в режиме реального времени через SRDF.
Сама по себе эта настройка не зависит от типа референц-инструмента или инструмента, который вам нужен (DVCS, или Nexus repo, или основной планировщик Hudson, или...): любой сервер, который может быть критичным для выпуска в производство, должен быть установлен на серверах. с резервной копией и DR.
,
- аутентификация: только два протокола позволяют пользователям получить доступ к основным репозиториям:
- на основе ssh, с открытым / закрытым ключом:
- полезно для пользователей, внешних по отношению к организации (например, оффшорная разработка),
- и полезно для общих учетных записей, которые менеджер Active Directory не хочет создавать (потому что это будет "анонимная" учетная запись): за эту общую учетную запись должен отвечать реальный человек, а тот, который владеет закрытым ключом
- На основе https, с помощью Apache, аутентифицирующего пользователей с помощью параметра LDAP: таким образом, для любой операции git в этих репозиториях должен быть предоставлен фактический логин.
Git предлагает его со своим умным протоколом http, позволяющим не простоpull(читать) через http, но такжеpush(напишите) через http.
- на основе ssh, с открытым / закрытым ключом:
Часть аутентификации также усилена на уровне Git post-receive ловушка, которая гарантирует, что по крайней мере один из коммитов, которые вы отправляете в репо, имеет "имя коммиттера", равное имени пользователя, обнаруженному по протоколу shh или http.
Другими словами, вам нужно настроить свой git config user.name правильно, или любой толчок, который вы хотите сделать в центральном репо, будет отклонен.
,
- авторизация: обе предыдущие настройки (ssh или https) связаны для вызова одного и того же набора сценариев perl, называемого gitolite, с параметрами:
- фактическое имя пользователя, обнаруженное этими двумя протоколами
- команда git (клон, push или pull), которую хочет выполнить пользователь
Perl-скрипт gitolite будет анализировать простой текстовый файл, в котором установлены полномочия (доступ на чтение / запись для всего репозитория, или для веток в данном репозитории, или даже для каталогов в репозитории).
Если уровень доступа, требуемый командой git, не соответствует списку ACL, определенному в этом файле, команда отклоняется.
Выше описано, что мне нужно было реализовать для настройки Git, но, что более важно, перечислены основные проблемы, которые необходимо решить, чтобы настройка DVCS имела смысл в большой корпорации с уникальной пользовательской базой.
Тогда и только тогда DVCS (Git, Mercurial, ...) может добавлять значения из-за:
обмен данными между несколькими сайтами: хотя все эти пользователи проходят проверку подлинности через один и тот же Active Directory, они могут быть расположены по всему миру (компании, в которых я работал, проводят разработки, как правило, между группами из двух или трех стран). DVCS, естественно, создан для эффективного обмена данными между этими распределенными командами.
репликация в разных средах: настройка, обеспечивающая аутентификацию / авторизацию, позволяет клонировать эти репозитории на других выделенных серверах (для тестирования интеграции, тестирования UAT, подготовки к производству и подготовки к развертыванию)
автоматизация процессов: легкость, с которой вы можете клонировать репо, также может использоваться локально на рабочей станции одного пользователя, для целей модульного тестирования с использованием методов "защищенных коммитов" и других умных применений: см. " Что такое самое умное использование исходного репозитория, которое Вы когда-нибудь видели?
Короче говоря, вы можете перейти ко второму локальному репо, отвечающему за:- различные задачи (юнит тест или статический анализ кода)
- откат к главному репо, если эти задачи успешны
- пока вы все еще работаете в первом репо, не дожидаясь результата этих задач.
,
- Возможности убийцы: любая DVCS поставляется с ними, основной из которых является слияние (когда-либо пытались сделать сложный рабочий процесс слияния с SVN? Или слиться с неумелым образом 6000 файлов с ClearCase?).
Одно это (объединение) означает, что вы действительно можете воспользоваться преимуществами ветвления, в то же время имея возможность в любое время объединить ваш код с другой "основной" линией разработки, потому что вы сделаете это:- сначала локально в своем репо, никому не мешая
- затем на удаленном сервере, отправив результат этого слияния в центральный репозиторий.
Чтобы добавить к другим комментариям, я заметил бы, что нет никакой причины, по которой у вас не может быть корпоративного центрального репозитория. Технически это просто еще один репозиторий, но это тот, из которого вы отправляете продукцию. Я использую ту или иную форму VCS уже более 30 лет и могу сказать, что переход на Mercurial был как городской мальчик, впервые дышавший чистым воздухом страны.
У DSCS (как правило) лучше, чем у централизованных систем для автономных или медленных сетей. Они, как правило, быстрее, что действительно заметно для разработчиков (использующих TDD), которые делают много проверок.
Первоначально централизованные системы легче понять, и они могут стать лучшим выбором для менее опытных разработчиков. DVCS позволяют вам создавать множество мини-веток и изолировать новые функции, в то же время выполняя повторную проверку на красный стиль кодирования. Опять же, это очень мощный, но привлекательный только для опытных команд разработчиков.
Наличие единого центрального репозитория для поддержки исключительных блокировок имеет смысл, если вы имеете дело с файлами, которые не подлежат слиянию, например цифровые активы и нетекстовые документы (PDF-файлы, Word и т. Д.), Поскольку это предотвращает попадание в беспорядок и слияние вручную.
Я не думаю, что количество разработчиков или размер кодовой базы играют в этом большую роль, обе системы, как было показано, поддерживают большие исходные деревья и количество коммиттеров. Однако для больших баз кода и проектов DVCS дает большую гибкость в быстром создании децентрализованных удаленных филиалов. Вы можете сделать это с централизованными системами, но вы должны быть более осмотрительными, что хорошо и плохо.
Короче говоря, есть некоторые технические аспекты, которые необходимо учитывать, но вы также должны подумать о зрелости вашей команды и ее нынешнем процессе в SCCS.
Самая большая проблема, с которой мы сталкиваемся с Git в корпоративных настройках, - это отсутствие контроля доступа на основе пути. Архитектуре Git присуща (и я полагаю, что большинство DVCS), что если вы получили доступ для чтения к хранилищу, вы получите все это. Но иногда проект требует разреженной проверки (т. Е. Вы хотите, чтобы чувствительные к управлению версиями данные располагались близко к источнику, или вы хотите, чтобы третье лицо выборочно просматривало часть проекта).
Из коробки Git не предоставляет никаких разрешений - у вас есть хуки для написания своих собственных.
Большинство популярных менеджеров репозитория GithubEnterprise, Gitlab, Bitbucket предоставляют ограничения на запись в филиалах. Gitolite позволяет быть более мелким, обеспечивая ограничения записи на основе пути (и более).
Единственный менеджер репо, который я слышал о поддержке доступа для чтения, - это Perforce Helix, который переопределяет протокол git поверх бэкэнда Perforce, но у меня нет практического опыта работы с ним. Это многообещающе, но меня беспокоит, насколько это совместимо с "простым" git.
Абсолютно модель распределенного источника может иметь смысл на предприятии, но она зависит от структуры ваших команд.
Распределенное управление исходным кодом дает вам гибкость в создании ваших собственных рабочих процессов.
Представьте себе, если хотите, большую команду, в которой есть небольшие команды, работающие над отдельными ветвями функций.
- Все эти группы могут иметь свои собственные центральные репозитории со своими собственными механизмами автоматизации сборки / контроля.
- Они могут работать где угодно и создавать резервные копии своей локальной работы в любое время.
- Затем они могут выбрать, какие чекины они хотели бы разделить между группами.
- У них может быть один отдельный интегратор, работающий на собственной машине, выполняющий слияние, не влияющий на других.
Это то, чего можно достичь с помощью традиционного централизованного сервера, но, как указывает @Brook, централизованная модель должна масштабироваться, тогда как распределенная модель уже сегментирована, поэтому нет необходимости (или, по крайней мере, меньше) в вертикальном масштабировании любых серверов.
По крайней мере, с TFS 2013 у вас есть возможность работать независимо от локальных рабочих пространств. Распределенный и централизованный определяется бизнесом и зависит от потребностей и требований разрабатываемых проектов.
Для корпоративных проектов возможность связать рабочий процесс и документы с изменениями кода может иметь решающее значение при соединении бизнес-требований и элементов более высокого порядка с конкретными изменениями кода, которые касаются определенного изменения, ошибки или добавления функции.
Эта связь между рабочим процессом и хранилищем кода отделяет TFS от решений только для хранилища кода. В некоторых местах, где требуется более высокий порядок аудита проектов, только такой продукт, как TFS, удовлетворит большую часть требований аудита проекта.
Обзор процесса управления жизненным циклом приложения можно найти здесь.
http://msdn.microsoft.com/en-us/library/vstudio/fda2bad5(v=vs.110).aspx
Наша команда использовала TFS около 3 лет, прежде чем перейти на Mercurial. Поддержка веток / слияний в HG намного лучше, чем в TFS. Это потому, что DVCS полагается на безболезненное слияние.
Для меня самая большая вещь, которую они предлагают, это Скорость. Они на несколько порядков быстрее для наиболее распространенных операций, чем централизованное управление источниками.
Работа отключена - это тоже огромный плюс.
Лучшая синхронизация через удаленные / отключенные местоположения.