Назад | Перейти на главную страницу

Соответствие в администрировании DVCS в контексте предприятия, чего ожидать от перехода от CVCS (Perforce)?

Я работаю в крупной многонациональной компании инженером-программистом, и в настоящее время я веду очень приятный разговор с ИТ и другими разработчиками о внедрении DVCS (Mercurial и / или Git).

Одним из вопросов, поднятых ИТ-отделом, было соответствие и интеллектуальная собственность (BTW, Perforce громко говорит об этом и в отношении Git). Мне кажется, что у ИТ-специалистов сложилось впечатление, что, поскольку Mercurial / Git распределены, наличие репозиториев на каждой машине разработчика является неконтролируемым сценарием, и им придется проверять каждый репозиторий.

Еще одна вещь, которая, как мне кажется, беспокоит ИТ-отдел, - это факт наличия «100» репозиториев вместо «10» огромных репозиториев. У меня сложилось впечатление, что они думают, что их административные усилия по их обслуживанию / мониторингу вырастут на «десять». сложить ". Я думаю, что программное обеспечение для управления репозиториями (Rhodecode, Atlassian Stash) станет первым шагом к обеспечению контроля доступа и прослеживаемости.

Мои вопросы:

  1. Достаточно ли программного обеспечения для управления репозиториями для компании такого размера (допустим, ~ 2000 разработчиков и ~ 50 хранилищ Perforce на ~ 10 серверах) ?, чтобы оно соответствовало (и отвечало другим требованиям предприятия?)

  2. Что именно входит в это требование "соответствия"? Есть ли какие-либо ссылки, которые вы можете дать (например, стандарт IEEE или что-то в этом роде)?

Моя компания использует Perforce около 10 лет.

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

Я сомневаюсь, что у ИТ-специалистов есть какие-то причины для беспокойства по этому поводу. Тот факт, что git и mercurial распространяются, не означает, что вы будете развертывать / доставлять прямо с рабочего стола какого-либо разработчика. По-прежнему возможно - и почти наверняка необходимо - продолжать использовать некоторые центральные репозитории, которые все проверяют, для тестирования, контроля качества и окончательного выпуска.

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

Что ты усиление с точки зрения ИТ, вы не попадаете в центральные репозитории каждые несколько минут (или секунд!) всякий раз, когда разработчики делают коммит. Разработчики могут закончить работу над чем-то, а затем продвинуть это только тогда, когда это будет готово, но при этом все еще будут иметь полный контроль версий на своей рабочей станции, почти не обращаясь к сети.

Наконец, вам необходимо более подробно поговорить с ИТ-отделом о точном характере проблем соответствия, о которых они говорят. Это может быть что угодно, от управления интеллектуальной собственностью, ISO 9000 или некоторых государственных законов / постановлений.

(Всем: не стесняйтесь улучшать этот ответ; это не моя область знаний ...)