Max Home IndustryMicrosoft уверенно движется к переносу кодовой базы Windows в единый репозиторий Git, размещенный в Visual Studio Team Services. Это включало масштабирование Git для очень больших проектов и команд с проектом под названием «Виртуальная файловая система Git».
Еще в феврале Microsoft сделала неожиданное заявление. Было решено использовать Git, систему управления версиями с открытым исходным кодом, созданную Линусом Торвальдсом для кодовой базы Windows, и было внедрено GVFS, набор улучшений для Git, которые, по словам Брайана Гарри, позволят Git масштабироваться до ОЧЕНЬ больших репозиториев за счет виртуализации. как папка .git, так и рабочий каталог.
Ранее Windows, как и другое программное обеспечение Microsoft, использовала Source Depot, проприетарную версию коммерческой системы контроля версий Perforce, которая была адаптирована для работы с огромным размером кодовой базы Windows.
Репортаж о передаче Брайан Гарри пишет в своем блоге:
Напомню, что база кода Windows составляет примерно 3,5 млн файлов, и при регистрации в репозитории Git получается репозиторий размером около 300 ГБ. Кроме того, команда разработчиков Windows насчитывает около 4000 инженеров, а инженерная система ежедневно производит 1760 «лабораторных сборок» в 440 филиалах в дополнение к тысячам проверочных сборок запросов на вытягивание. Все 3 измерения (количество файлов, размер репо и активность), независимо друг от друга, создают непростые задачи масштабирования, а вместе они делают невероятно сложным создание отличного опыта. До перехода на Git в Source Depot он был распределен по более чем 40 хранилищам, и у нас был инструмент для управления операциями, которые охватывали их.
Перенос производился поэтапно. В первом и самом крупном переходе в марте участвовала команда WindowsOneCore, состоящая из 2000 инженеров.
Гарри пишет:
Эти 2000 инженеров работали в Source Depot в пятницу, уехали домой на выходные и вернулись в понедельник утром, чтобы испытать новый опыт, основанный на Git. Люди в моей команде все выходные затаили дыхание, молясь, чтобы нас не избила толпа разъяренных инженеров, которые пришли в понедельник, не имея возможности выполнить какую-либо работу. По правде говоря, команда Windows проделала огромную работу по подготовке планов резервного копирования на случай неудачи, и, к счастью, нам не пришлось использовать ни один из них.
Честно говоря, к моему большому удивлению, все прошло очень гладко, и инженеры работали продуктивно с первого дня. Без сомнения, у нас были некоторые проблемы. Например, Windows из-за размера команды и характера работы часто имеет ОЧЕНЬ большие слияния между ветвями (10 000 изменений и 1 000 конфликтов). В ту первую неделю мы обнаружили, что наш пользовательский интерфейс для запросов на вытягивание и разрешения конфликтов слияния просто не масштабируется для таких значительных изменений. Нам пришлось бороться за виртуализацию списков и постепенную выборку данных, чтобы пользовательский интерфейс не зависал. Мы решили это за пару дней, и в целом настроения на той неделе были намного лучше, чем мы ожидали.
Еще 1000 инженеров были заменены месяцем позже, 22 апреля, и, как показывает этот график, это очень мало повлияло на общую схему ежедневных проверок, что можно использовать в качестве индикатора того, что люди выполняли свою работу без серьезных сбоев. . Оранжевая кривая показывает, что количество проверок Git увеличивается с течением времени, заменяя синие проверки SourceDepot, а серая линия — общее количество.
Еще 300-400 инженеров переместили Git в мае, оставив около 500, которые еще предстоит переместить. Гарри комментирует:
Остальные команды в настоящее время работают в срок и пытаются выяснить, когда лучше всего запланировать свой переезд, но я ожидаю, что в ближайшие несколько месяцев мы завершим работу всей группы инженеров.
Он также предоставляет следующие статистические данные, чтобы указать масштаб, в котором работает система:
Более 250 000 достижимых коммитов Git в истории этого репо за последние 4 месяца.
8 421 нажатие в день (в среднем)
2500 запросов на вытягивание, 6 600 рецензентов в день (в среднем)
4352 ветки с активными темами
1760 официальных сборок в день
Технические детали миграции и проблемы ее масштабирования обсуждаются Саидом Нурсалехи в документе под названием Git at Scale. Его объяснение того, что намеревается делать виртуальная файловая система Git, и проблемы клонирования репозитория Windows без этого заслуживают рассмотрения. Он объясняет это:
GVFS виртуализирует файловую систему под репозиторием Git для решения двух основных проблем:
Загружайте только тот контент, который нужен пользователю
Сделайте так, чтобы локальные команды Git учитывали только те файлы, которые интересуют пользователя, а не все файлы, существующие в рабочем каталоге.
Нашим целевым вариантом использования является репозиторий Windows, в рабочем каталоге которого находится более 3 миллионов файлов, всего 270 ГБ исходных файлов. Это 270 ГБ в рабочем каталоге, на кончике мастера. Чтобы клонировать это репо, вам нужно будет загрузить файл пакета размером около 100 ГБ, что займет несколько часов. И как только вам удастся его клонировать, локальные операции git, такие как checkout (3 часа), status (8 минут) и commit (30 минут), по-прежнему будут выполняться слишком долго, потому что все эти команды линейны на количество файлов.
В Git at Scale, главный менеджер программы, Visual Studio Team Services дает полный и интересный отчет о том, почему проект был реализован и как он достиг своих целей. В приведенном ниже видео из Git Merge 2017 Нурсалехи обсуждает, как Microsoft использует git для внутренних целей, уделяя особое внимание большим репозиториям, и описывает архитектуру сервера VSTS git вместе с настройками, которые Microsoft пришлось внести как в него, так и в git. exe, чтобы git мог масштабироваться все дальше и дальше.
Сама GVFS теперь является проектом с открытым исходным кодом под лицензией MIT. Для его создания требуется Visual Studio 2017 Community Edition или выше вместе с Windows 10 SDK и средствами разработки .Net Framework 3.5.