Прошло уже три месяца с тех пор, как я опубликовал свою первую статью о наших попытках масштабировать Git для очень крупных проектов при помощи инициативы, которую мы назвали «Git Virtual File System». Напомню: GVFS в сочетании с некоторыми правками в Git позволяет работать с ОЧЕНЬ большими репозиториями, виртуализируя как папку .git, так и рабочую директорию. Вместо того, чтобы скачивать репозиторий целиком и проверять все файлы, инструмент динамично скачивает только те фрагменты, которые вам нужны, выявляя их на основании того, над чем вы работали до этого момента.
За это время много чего произошло, и я хочу поделиться с вами новостями. Три месяца назад GVFS был только мечтой. Не в том смысле, что его не существовало — у нас была готовая реализация — но в том, что он еще не показал себя в деле. Мы опробовали его на больших репозиториях, но не успели внедрить в рабочий процесс для сколько-нибудь значимого количества разработчиков. Поэтому у нас было только умозрительное убеждение, что все будет работать. Теперь же у нас есть подтверждение этому.
Сегодня я хотел быть представить результаты. Кроме того, мы озвучим для пользователей следующие шаги, которые планируем предпринять в целях развития GVFS: в частности, добавление возможности вносить свой вклад в открытый код и улучшение функционала в соответствии с потребностями нашей компании, партнеров и клиентов.
Windows на Git: прямая трансляция
За эти три месяца мы практически завершили процесс внедрения Git/GVFS для команды, работающей с Windows в Microsoft.
Если в двух словах: кодовая база Windows состоит из 3.5 миллионов файлов; когда заливаешь ее на Git, получается репозиторий размером где-то в 300 гигабайт. Более того, в компании работает около 4000 инженеров; инженерная система ежедневно производит 1,760 сборок по 440 веткам, вдобавок к pull-запросам на валидацию билдов. Все эти три обстоятельства (количество файлов, размер репозитория, темп работы) сильно усложняют дело даже по отдельности, а взятые вместе делают обеспечение позитивного опыта невероятно сложной задачей. До перехода на Git мы пользовались Source Depot и код был распределен по 40 с лишним репозиториям, у нас даже был специальный инструмент, чтобы управлять операциями.
На момент выхода моей первой статьи три месяца назад весь наш код хранился в одном Git репозитории, которым пользовались несколько сотен программистов для обработки очень скромного процента билдов (менее 10%). С тех пор мы в несколько этапов выкатили проект для всего инженерного состава.
Первый, и самый массовый, скачок произошел 22 марта, когда мы перевели на новую систему всю команду Windows OneCore целиком — а это около 2000 человек. Эти 2000 инженеров еще в пятницу работали с Source Depot, а вернувшись в офис после выходных, обнаружили, что их ждет радикально новый опыт с Git. Все выходные моя команда просидела скрестив пальцы и молясь, чтобы в понедельник нас не разорвала разъяренная толпа инженеров, у которых застопорилась вся работа. На самом деле, команда Windows очень хорошо продумала запасные планы на случай, если что-то пойдет не так; к счастью, нам не пришлось к ним прибегнуть.
Но все прошло неожиданно гладко и разработчики с первого же дня сумели приспособиться к новым условиям без ущерба продуктивности — честно говоря, я даже удивился. Несомненно, возникали и сложности. К примеру, команде Windows из-за ее огромных размеров и специфики работы, часто приходилось производить слияние ОЧЕНЬ крупных ветвей (речь идет о десятках тысяч изменений и тысячах конфликтов). Уже в первую неделю стало ясно, что наш интерфейс для pull-запросов и разрешения конфликтов слияния просто не приспособлен для таких масштабных изменений. Пришлось в срочном порядке вирутализировать списки и получать данные командой fetch поэтапно, чтобы интерфейс не подвисал. Через пару дней мы с этим справились и, в целом, неделя прошла на более позитивной ноте, чем мы рассчитывали.
Один из способов, которые мы использовали, чтобы оценить успешность всего мероприятия — это опрос инженеров. Главный вопрос, который мы им задали — это «Довольны ли вы?», хотя, конечно, не забыли расспросить и о подробностях. Первый опрос состоялся через недели после запуска проекта и показал следующие результаты:
(Полностью довольны: 54;
Скорее довольны: 126;
Скорее недовольны: 54;
Крайне недовольны: 17)
Показатели не такие, чтобы запрыгать от радости, но учитывая, что у команды только что, можно сказать, мир перевернулся, им пришлось учиться работать по новой схеме и они все еще находились в процессе перехода — результаты показались мне вполне приличными. Да, из 2000 сотрудников откликнулись только 251, но добро пожаловать в мир тех, кто пытается заставить людей участвовать в опросах.
Другой способ, который мы применяли для оценки успешности, — отслеживание деятельность инженеров, чтобы проверить, выполняется ли необходимый объем работы. Например, мы фиксировали количество залитых фрагментов кода для всех официальных подразделений. Разумеется, половина компании все еще оставалась на Source Depot, в то время как вторая половина уже перешла на Git, поэтому наши замеры отражали некую смесь из их результатов. На графике, приведенном ниже, вы можете заметить ощутимый спад в числе залитых файлов на Source Depot и ощутимый подъем в pull-запросах на Git, но суммарное количество остается примерно одинаковым на всем отрезке. Мы решили, что на основании этих данных можно сделать вывод: система работает и существенных препятствий к использованию не содержит.
22 апреля мы выкатили продукт еще для 1000 инженеров; чуть позже, 12 мая — для следующих 300-400. Адаптация каждой следующей волны происходила по тем же паттернам, что и у предыдущих, и в данный момент 3500 из 4000 инженеров Windows перешли на Git. Оставшиеся команды в данный момент доводят свои проекты до завершения и пытаются определиться с оптимальным временем для перехода, но, думаю, к концу месяца будут охвачены все сотрудники.
Количество данных, с которыми работает система, потрясает воображение. Давайте посмотрим на конкретные цифры:
- В общей сложности за 4 месяца существования репозитория было совершено более 250,000 Git коммитов;
- 8,421 пушей в среднем за день;
- 2,500 pull-запросов и 6,600 инспекторов кода в среднем за рабочий день;
- 4,352 активных ответвлений;
- 1,760 официальных сборок в день.
Как вы сами видите, это огромное количество операций на очень обширной кодовой базе.
Производительность GVFS при работе на масштабных проектах
По результатам опроса видно, что существующим положением вещей довольны не все. Мы собрали много данных на этот счет, и причины самые разные — от того факта, что не все инструменты поддерживают Git, до досады, что приходится осваивать что-то новое. Но основная проблема — производительность, и ее-то я и хочу разобрать досконально. Выкатывая Git, мы знали, что с точки зрения производительности он еще недоработан, да и в процессе внедрения многому научились. Мы отслеживаем производительность для ряда ключевых операций. Вот данные, которые собрали телеметрические системы, по работе 3500 инженеров, использующих GVFS.
Здесь вы видите «цель» (мы рассчитывали ее как худшее из допустимых значений — не то, к чему мы стремимся, а порог, ниже которого нельзя опускаться, чтобы система вообще работала). Также приведены результаты по 80му перцентилю за последние семь дней и разница с результатами предыдущей недели. (Как можете заметить, все замедляется — мы поговорим об этом подробнее чуть позже).
Чтобы вам было с чем сравнивать, скажу так: если бы мы попытались проделать что-то подобное на «классическом Git», прежде чем начали работу над ним, многие из команд выполнялись бы от тридцати минут до нескольких часов, а некоторые вообще никогда бы не дошли до завершения. То, что большинство сейчас обрабатывается за 20 секунд и меньше — это огромный шаг вперед, хотя в постоянных 10-15 секундных интервалах ожидания тоже, конечно, ничего хорошего.
Когда мы только-только выкатили проект, результаты были куда лучше. Это стало для нас одним из главных открытий. Если вы прочитаете вводный пост, где я даю общее представление о GFVS, там говорится о том, как мы работали над Git и GVFS, чтобы сделать ряд операций пропорциональными не общему числу файлов в репозитории, но числу «прочитанных» файлов. Как выясняется, со временем инженеры расползаются по кодовой базе и прикасаются к все большему числу файлов, что приводит к проблеме, которую мы называем «over hydration» (перенасыщение). В итоге мы имеем кучу файлов, которых кто-то когда-то касался, но после этого не использовал и определенно не вносил никаких изменений. Как следствие, производительность падает. Люди могут «подчищать» свои списки заходов, но это лишняя морока и никто этого не делает, а работа системы все замедляется и замедляется.
Это вынудило нас запустить очередную серию модификаций для улучшения производительности под названием «O(modified)», которые меняют многие ключевые команды, делая их пропорциональными количеству измененных файлов (в смысле, что имеются изменения, для которых коммит еще не был сделан). Мы добавим эти изменения в основную версию на той неделе, так что у меня еще нет статических данных, но тестирование пилотной версии показало неплохие результаты.
У меня пока что нет всех значений, но я отобрал для примера несколько полей из таблицы выше и вставил соответствующие цифры в колонку O(hydrated). В добавленной колонке O(modified) я привел результаты, которые мы получили по тем же командам с применением оптимизированной версии, которую собираемся выкатить на следующей неделе. Единица измерения там и там — секунды. Как видите, в целом и общем наблюдается заметный прогресс: где-то скорость возросла незначительно, где-то — в два раза, а где-то — в пять. Мы возлагаем большие надежды на эти улучшения и рассчитываем, что они качественно изменят пользовательский опыт. Я не совсем доволен (не успокоюсь, пока Status не станет занимать меньше секунды), но все-таки мы здорово продвинулись.
Другая немаловажная область производительности, которой я не коснулся в предыдущем посте — это географическое распределение команд. Инженеры Windows разбросаны по всему земному шару — США, Европа, Средняя Азия, Индия, Китай и так далее. Pulling большие объемы данных на больших расстояниях, зачастую с далекой от идеала пропускной способностью — серьезная проблема. Чтобы с ней справиться, мы создали прокси-решение на Git для GVFS, которое позволяет кэшировать данные с Git на выходе. Также мы использовали прокси, чтобы разгружать очень большие объемы траффика (скажем, серверы билдов) из главного сервиса Visual Studio Team Services, чтобы пользовательский опыт не страдал даже в часы, когда нагрузка максимальная. В общей сложности у нас 20 прокси для Git (которые, кстати, мы просто инкорпорировали в уже существующий Team Foundation Server Proxy) по всему свету.
Чтобы вы лучше представляли, какой это дало эффект, позвольте привести пример. Аккаунт Windows Team Services находится в дата-центре Azure, на западном побережье США. Выше я указывал, что для инженера Windows операция клонирования по 80му перцентилю занимает 127 секунд. Так как большая часть инженеров работает из Редмонда, это значение актуально в первую очередь для них. Мы провели тест в отделении в Северной Каролине, которое и более удалено от центра, и располагает меньшей пропускной способностью. Без применения прокси на ту же операцию потребовалось около 25 минут. С настроенным и обновленным прокси время сократилось до 70 секунд (то есть быстрее, чем в отделении Редмонда — там команда не пользуется прокси и от Azure их отделяют сотни миль интернет-кабелей). 70 секунд против 25 минут — это улучшение почти на 95%.
В целом, Git с GVFS абсолютно готов к употреблению и может применяться к проектам невероятного масштаба. Результаты показывают, что продуктивность наших инженеров при этом не страдает. Однако нам предстоит еще много работы, прежде чем система будет усовершенствована настолько, чтобы сотрудники были ей довольны. Работа, проделанная в O(modified), которую мы выкатим на следующей неделе, станет большим шагом в этом направлении, но потребуется несколько месяцев дополнительных доработок, чтобы с чистой совестью сказать, что все, что нужно, сделано.
Если хотите подробнее узнать о тех технических сложностях, с которыми мы столкнулись в процессе масштабирования Git и обеспечения хорошего уровня производительности, рекомендую цикл статей о масштабировании Git и GVFS от Saeed Noursalehi. Очень увлекательное чтение.
Попробуйте GVFS сами
GVFS — это проект с открытым кодом, и мы приглашаем всех желающих попробовать с ним поработать. Все, что от вас требуется — скачать и установить его, завести аккаунт в Visual Studio Team Services с репозиторием Git, и можно приступать. С первой публикации GVFS мы основательно продвинулись. Среди самых существенных изменений можно назвать:
1. Мы стали регулярно обновлять кодовую базу, постепенно переходя на «открытую» модель разработки. На данный момент все последние изменения (включая все, что было сделано для O(modified)) опубликованы, и мы планируем периодически загружать обновления и в дальнейшем.
2. На момент первой публикации мы были не готовы принимать вклад от сторонних разработчиков. Сегодня мы дошли до того этапа, когда можем официально заявить, что открыты для этой практики. Нам представляется, что базовая инфраструктура уже в достаточной степени заложена, чтобы дать людям возможность брать и развивать ее вместе с нами. Если кто-то хочет подключиться и помочь — мы будем только рады.
3. GVFS опирается на файловую систему Windows, которую мы называем GVFlt. До сих пор драйвер, доступ к которому мы обеспечили, был неподписанным (так как над ним еще активно велась работа). Очевидно, это значительно усложняло жизнь тем, кто хотел его опробовать. Теперь же мы выпустили подписанную версию GVFlt, в которой устранены все шероховатости (так, вам больше не придется отключать BitLocker для установки). Но хотя у нас появился подписанный GVFlt драйвер, это только временное решение. Мы планируем внедрить соответствующие функции в будущую версию Windows и в данный момент прорабатываем детали.
4. После выступления на конференции Git Merge мы стали активнее обсуждать нюансы масштабирования Git и, в частности, GVFS с широким кругом специалистов, заинтересованных в этой теме. Мы очень продуктивно пообщались с другими крупными компаниями (Google, Facebook), которые сталкиваются с такими же сложностями, и стали делиться своим опытом и подходом. Также мы провели работу с несколькими популярными Git-клиентами, чтобы убедиться, что они совместимы с GVFS. В их число вошли:
- Atlassian SourceTree — SourceTree стал первым инструментом, который прошел валидацию на совместимость с GVFS; уже вышло обновление, в котором были введены некоторые изменения для более гладкого рабочего процесса.
- Tower — команда Tower рада сообщить, что они работают над добавлением поддержки GVFS в версию приложения для Windows. В ближайшем будущем соответствующий функицонал будет доступен в бесплатном обновлении.
- Visual Studio — само собой, неплохо бы и нашему собственному Visual Studio Git нормально работать с GVFS. Мы внедрим поддержку GVFS в версию 2017.3, первое превью которой (со всем необходимым для поддержки) выйдет в начале июня.
- Git на Windows — в рамках своей инициативы по масштабированию Git мы внесли ряд изменений под Git в Windows (к примеру, командная строка Git), включая поддержку GVFS. Сейчас у нас на Git создано особое ответвление для Windows, но со временем мы хотим все перенести в основную версию кода.
Обобщая сказанное
Мы будем и дальше упорно работать над масштабированием Git, чтобы приспособить его для крупных команд и массивных кодовых баз в Microsoft. С тех пор, как мы впервые заговорили об этом проекте три месяца назад, много чего произошло. В частности, мы:
- успешно внедрили проект для 3500 инженеров;
- подключили прокси и доработали продуктивность;
- обновили открытый код и дали другим пользователям возможность вносить правки/вклады;
- обеспечили signed GVFlt драйвер, чтобы проще было воспользоваться сервисом;
- стали сотрудничать с другими командами, чтобы внедрить поддержку в популярные инструменты — SourceTree, Tower, Visual Studio и так далее;
- опубликовали несколько статей, где с технической точки зрения подробно рассматривается наш подход к масштабированию Git и GVFS.
Это был захватывающий опыт для Microsoft и серьезный вызов для моей команды и команды Windows. Я в восторге от того, чего мы уже добились, но не склонен недооценивать объем работы, который еще остается. Если вы тоже часто оказываетесь в ситуациях, когда приходится работать с кодовыми базами очень больших размеров, но при этом всей душой хотите перейти на Git, призываю вас попробовать GVFS. В данный момент Visual Studio — это единственное бэкенд-решение, которое поддерживает GVFS протокол со всеми нововведениями. В дальнейшем, если проект окажется востребован, мы добавим поддержку GVFS также в Team Foundation Server; также мы провели переговоры с другими сервизами Git, создатели которых рассматривают возможность обеспечить совместимость в будущем.
Автор: nanton
