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

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

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

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

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

У меня есть вопросы:

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

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

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

решение1

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

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

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

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

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

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

Связанный контент