КАК PROJECT BOREALIS ИСПОЛЬЗУЕТ GIT
Здравствуйте и добро пожаловать в наш самый первый блог технологий! Во время разработки проекта Borealis мы хотим оставаться открытыми и коммуникабельными, и хотя наши видео обновления разработки направлены на предоставление обзора нашего прогресса на высоком уровне, мы хотели бы воспользоваться возможностью время от времени углубляться в некоторые особенности. Это первый том, из серии тех.блогов о разработке.
Сегодня мы хотели бы поговорить о том, как мы эффективно сотрудничаем в крупномасштабном игровом проекте в совершенно удаленной обстановке, сохраняя при этом минимальные затраты. Мы не поняли этого с первой (или второй) попытки, поэтому сначала рассмотрим некоторые из наших менее успешных систем, что с ними пошло не так, и что мы узнали. Наконец, мы подробно расскажем о нашей текущей настройке и о том, как она эволюционировала, чтобы масштабироваться для команды из почти 100 разработчиков игр, работающих по всему миру. Не стесняйтесь переходить ко второй части, если вы хотите сразу перейти к техническим деталям того, что мы в настоящее время используем, но мы считаем, что неудачи наших первых попыток обеспечивают некоторый полезный контекст.
ЕСЛИ ПОНАЧАЛУ У ВАС НИЧЕГО НЕ ПОЛУЧИТСЯ, ПОПРОБУЙТЕ ЕЩЕ РАЗ.…
В первые дни нашего проекта, когда "Epistle 3" только был опубликован, все шло как по маслу. Мы фактически создавали студию разработки игр с нуля, и она должна была быть полностью удаленной. Разработка игр традиционно осуществляется в физической студии, из-за больших активов, которые трудно передать через Интернет, а также многих проблем совместной работы и итерации, обычно решаемых в одной комнате с людьми, с которыми вы работаете.
После того, как команда успокоилась и мы приняли некоторые более важные решения (например, какой движок использовать!), мы инстинктивно обратились к Git и Git LFS (большому файловому хранилищу), чтобы разместить наше игровое repo
Repo V1
Сначала мы остановились на использовании GitLab.com. мы смогли найти Git LFS для хранения наших художественных активов и GitLab.com предусмотреное бесплатное хранение для ОРС. Какое-то время это работало хорошо, поскольку на тот момент наше игровое REPO было в основном кодом наши художники работали независимо в своих художественных инструментах, а дизайн находился на стадии подготовки к производству, поэтому нам не нужно было беспокоиться об уровнях. Программисты будут отходить от нашей основной ветви и отправлять запросы на вытягивание (запросы на слияние в GitLab). Пока все хорошо. Как только художники начали представлять активы, мы просто позволяли им ветвиться, как они хотели, и сливаться обратно, когда они хотели. Мы столкнулись с некоторыми небольшими дорожными ухабами, такими как отсутствие у художников двоичных файлов редактора для запуска редактора игр - программисты просто инструктировали художников о том, как установить Visual Studio, чтобы они могли скомпилировать его сами. Эта система работала по большей части...но не очень хорошо. Он также не был дружелюбен к художникам, которые не были знакомы с этими системами. Но мы столкнулись с более серьезной проблемой, чем техническая простота использования: размер REPO GitLab.com он был довольно нестабильным в то время, когда мы его использовали, и с большими размерами репозитория он мог регулярно вырезаться, особенно для новых людей, клонирующих все REPO. Члены команды также должны были загрузить весь проект для своей работы, даже если они не нуждались во всем этом. В дополнение к этому мы также быстро приближались к предельному размеру РЕПО на 10 ГБ, добавляя все новые арт-активы и начальные уровни. В попытке смягчить эти проблемы мы изменили структуру нашего репозитория. Это было, вероятно, одно из худших технических решений, которые мы приняли.
REPO V2
Сначала мы разделили REPO на подмодули, сгруппированные по типу проекта, а затем по типу активов. Они были названы общими, для всех основных активов, импортированные из Source для Unreal Engine 4, подготовка, к любым испытаниям активов, писать особенности, для всех техно-демок конкретным активам, и Episode 3. Каждая из этих групп имела подмодули для частиц, моделей, материалов, музыки, звука и т. д. И все это было подкреплено обязательным скриптом командной строки под названием Icebreaker, который, по крайней мере теоретически, будет управлять всеми этими подмодулями для вас. Это звучало здорово и казалось, что это решит все наши проблемы, однако это быстро превратилось в запутанный кошмар.
Фактический результат был целым рядом ошибок, технических проблем и запутанных художников, очень мало пользы. К сожалению, мы загнали себя в угол этой системой. Огромное количество подмодулей и рабочие процессы, построенные вокруг них, были слишком громоздкими, чтобы использовать их с чем-либо еще, кроме Icebreaker'a. Вот мы и разобрались с этим. Запросы на поддержку шли через крышу, и было много разочарований с получением контента в хранилище. В конечном счете это была огромная трата времени, но мы не могли взять на себя обязательства по изменению, поскольку проблемы накапливались, потому что мы приближались к обновлению разработки 4 и должны были показать Равенхолм. Мы не могли приостановить разработку, чтобы переработать REPO до тех пор, пока это не произойдет. После обновления 4 наша команда сделала заслуженный перерыв, и программисты начали свободно реструктурировать REPO еще раз. И на этот раз мы хотели сделать масштабируемое и надежное решение для совместной работы, которое было бы простым в использовании.
REPO V2 Episode 1
Мы многому научились у наших предыдущих REPO и хорошо изучили, где были проблемы, чтобы увидеть, как мы могли бы лучше всего их решить.
Первое решение, которое мы приняли, было перейти на автономный сервер GitLab. Это было сделано для того, чтобы избежать простоя и нестабильности, которая мучила GitLab.com, и снять ограничение на размер REPO. Это позволило нам снова создать единый репозиторий, что было отличным первым шагом.
Далее мы хотели рассмотреть ветвящуюся структуру "все идет", которая вызвала так много конфликтов слияния (когда люди изменяют один и тот же файл, и изменения из одной версии не могут быть сохранены), а также общую путаницу со стороны наших художников. Был составлен официальный документ о структуре филиала с подробными сведениями о жизненном цикле программного обеспечения, политике слияния и расписании. Мы создали ветвь dev, из которой программисты создавали ветви, ветвь master, которая содержала последний в целом стабильный код, готовый к использованию креативщиками, а затем ветви контента от master. Через некоторое время мы поняли, что не получаем большой пользы от git flow для креативщиков, и поэтому просто создали контент-основную ветвь, которую все креативщики подталкивали и вытягивали напрямую, и она будет объединена в master для стабильных релизов сборки игр. В конечном счете, эта структура была не столь эффективна, как могла бы быть при управлении изменениями, происходящими при подготовке к выпуску сборки игры.
На стороне хостинга мы управляли распределенной сетью хранения объектов с некоторым кэшированием пограничных серверов через CloudFlare для объектов LFS,которые стали большей частью нашей пропускной способности. Мы также использовали интеллектуальную маршрутизацию Argo для сокращения задержки запросов, в основном для блокировки файлов. Это значительно увеличило скорость, но мы все еще были узким местом из-за пропускной способности при обновлении объектов git и диффинга на наш собственный сервер. Это также была новой инфраструктуры, чтобы поддерживать себя.
Наконец, для инструментов мы начали с простого пакетного сценария для извлечения последней версии из REPO, обновления нашего пользовательского движка с помощью ue4versionator и запуска проекта. Остальная часть управления версиями (извлечение файлов, фиксация, выталкивание) была выполнена в плагине UE4 Git, к которому мы добавили хак для параллельной блокировки, чтобы ускорить операции извлечения в Редакторе вместо блокировки по одному, а также несколько других улучшений. Однако этот простой пакетный сценарий стал громоздким с течением времени, когда мы повзрослели в нашем рабочем процессе управления версиями, чтобы охватить общие проблемы, упростить получение последних изменений и управлять бинарными зависимостями. Так появились PBSync и PBGet.
НАШЕ РЕШЕНИЕ ДЛЯ РАЗРАБОТКИ ВЫСОКОРАСПРЕДЕЛЕННЫХ ИГР
REPO V3
третий раз-это обаяние. Для нашей последней итерации репозитория мы создали PBSync и PBGet (теперь с открытым исходным кодом!) масштабировать в соответствии с нашими требованиями полное решение для управления хранилищами и зависимостями.
PBSync-это надежный, проверенный в боях набор скриптов Python, которые помогают пользователям синхронизировать проект, обрабатывать пограничные случаи управления версиями, обновлять двоичные файлы, восстанавливать плохие репозитории в хорошее состояние, развертывать сборки игр и многое другое! Это произошло, когда наши предыдущие пакетные сценарии стали слишком громоздкими для нас. Теперь мы синхронизируем файлы DLL редактора проектов через Nuget, а не в системе управления версиями. Это делает нашу систему управления версиями легче и использует менеджер пакетов для того, для чего она была создана: обработки двоичных пакетов. Мы также можем поддерживать сложную логику и крайние случаи, чтобы оптимизировать синхронизацию проекта даже в плохих состояниях репозитория и свежих клонах, с управляемой настройкой.
PBGet-это базовая платформа для работы с Nuget для загрузки пакетов, которые связаны с их ожидаемым местоположением для UE4 с помощью соединений. Это также позволяет программистам поднять нашу версию проекта и протолкнуть новые исходные файлы в Nuget.
Но наличие программиста, управляющего всем этим, не будет работать в масштабе, поэтому, используя эти надежные инструменты, мы смогли создать полностью автоматизированную систему непрерывной интеграции, которая помогает нам в этих конвейерах и потоках управления версиями. В настоящее время мы используем TeamCity для автоматического создания двоичных файлов и слияния изменений для креативов, чтобы использовать их в своей собственной ветви, а также для синхронизации изменений контента обратно в ветку разработки программистов. Особенность кода филиалы автоматически статически анализируется, и мы также проверим стиле Doxygen для документирования сборки с пылеобразования. Это гарантирует, что проверка кода не пропустит никаких небольших изменений, и мы применяем наши правила для поддержания чистой и хорошо функционирующей базы кода.
Кроме того, мы перенесли наш репозиторий на GitHub из нашей собственной GitLab, чтобы облегчить некоторое давление на обслуживание с нашей стороны и снять некоторые проблемы с производительностью, воспользовавшись большими инженерными усилиями GitHub по созданию надежной и эффективной распределенной инфраструктуры управления версиями. Это был в значительной степени простой процесс благодаря децентрализованной природе Git.
Наконец, мы скорректировали нашу конфигурацию git, чтобы воспользоваться преимуществами предстоящих функций производительности и улучшения удобства использования, чтобы в дальнейшем сделать разработку игр на git быстрой и легкой. Мы используем график фиксации для оптимизации многих локальных операций, watchman как монитор файловой системы git для пассивного отслеживания изменений файлов и многие другие оптимизации для репозиториев с большим количеством файлов. Мы также используем ребазинг для нашего метода вытягивания проекта по умолчанию, чтобы не было конфликтов блокировки в коммитах слияния, и это также облегчает и очищает креативы, чтобы убедиться, что они находятся на последних изменениях.
Все это вместе взятое вызвало исключительно позитивный отклик. Программисты и креативщики одинаково любят систему, которую мы построили, и находят ее оптимизированной и безболезненной! Наша статистика отражает это: билеты на техническую поддержку упали более чем на 95%! Таким образом, теперь мы имеем дело с высокоскоростным, с низкой задержкой управлением версиями, которое работает с нашим репозиторием с более чем 14 000 файлами общим объемом более 28 ГБ для полностью удаленной команды, распределенной по всему миру от Калифорнии до Германии и Новой Зеландии.
Мы еще поговорим о нашем конвейере сборки (вплоть до релизов сборки игр) и политике слияния в будущем посте, но до тех пор вы можете просмотреть наш новый проект wiki, где мы публикуем некоторые внутренние документы о нашей системе управления версиями. Следите за новостями в нашем Твиттере и не стесняйтесь задавать вопросы о наших разногласиях.
И в качестве бонуса за то, что мы добрались до конца блога, у нас есть новое видео, которое визуализирует долгую и богатую историю нашего репозитория проектов через Gource!
