Аннотация: статья о том, как нужно строить инфраструктуру разработки проекта, с какими трудностями придется столкнуться, какие ресурсы следует использовать, каких правил нужно придерживаться, как следует управлять работой. В качестве примера рассмотрим проект на Unity.
Ключевые слова: инфраструктура, разработка, проект, управление.
Термин инфраструктура означает «комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и обеспечивающих основу функционирования системы». Не так давно это слово вошло в обиход, но проще говоря, инфраструктура – это фундамент, который позволяет создавать что-либо, в том числе игровые проекты.
Инфраструктура проекта существует даже тогда, когда ею никто специально не занимается. В качестве примера можно привести постройку какого-нибудь сарая без фундамента, со временем где-то появятся подпорки, пол утрамбуется, то есть образуется инфраструктура. Но это не значит, что инфраструктура проекта возникнет сама по себе и заниматься ею не нужно. Необходимо придерживаться принципа: если известно, что появятся какие-то большие и сложные задачи, то лучше о них подумать заранее, что бы избежать проблем в дальнейшем.
Возьмем большой многопользовательский проект, разрабатываемый в Unity. Можно предположить, что проект будет охватывать несколько областей, либо больших, либо сложных. В ходе реализации проекта планируется задействовать множество людей, сам проект будет долго разрабатываться. Будет использоваться много данных и в процессе производства проекта, и в дальнейшем процессе функционирования проекта. Будет много пользователей, и нужно придумать какие-то решения, какие-то процессы для коммуникаций во время разработки. В процессе работы будут появляться множества знаний, нужно будет заниматься безопасностью, и придумывать массу технических решений.
В первую очередь будет необходимо общаться. Кажется, что это легко, но на самом деле, кода коллектив превышает 10 человек, то это совсем не просто, а когда возникают разнопрофильные команды, а их будет не 2, не 4, а от 6 до 10, это еще сложнее. И это только команда проекта. Также существуют другие сотрудники компании, это менеджмент компании, с ними тоже нужно общаться, потому что они финансируют проект. Также есть люди из внешнего окружения, ими могут выступать партнеры, которые являются держателями платформ. Во время разработки, необходимо будет общаться с ними. Как это все реализуется? Есть средства, для мгновенной коммуникации, которые на первый взгляд кажутся весьма удобными. Это, например, чаты Telegram: чат по командам, чат проекта, чат компании. Это удобно, но проблема в том, что мгновенные сообщения работают, если их прочитали сейчас, здесь, в течение часа или дня. Если человека не было, он болел, был в отпуске или пришел в проект через два дня после сообщения, вся информация в чатах будет для него потеряна. Поэтому достаточно надежным каналом коммуникаций выступает email, но он тоже не решает всех проблем. Это – канал, который точно доставит информацию, которую могут прочитать все участники проекта. Но не все умеют общаться почтой, эту «культуру» нужно прививать. Канал коммуникации должен работать как на внутреннюю, так и на внешнюю среду проекта. Когда запускается проект, всем интересно, что происходит в нем, в итоге все спрашивают, что происходит внутри разработки. Для этого можно создать блог, в котором можно рассказывать о тех или иных интересных решениях. С одной стороны это снимает каждодневные вопросы: «Что у Вас?», «Как у Вас?». С другой стороны это порождает новые, какие-нибудь конкретные советы или вопросы по уже опубликованному материалу. Также можно устраивать ежедневные demo, которые могут опробовать другие коллеги, это позволяет держать всех участников в курсе происходящего. Это полезно тем, что можно узнать «новое» мнение. Это – повод, чтобы задуматься, пересмотреть какие-нибудь подходы.
Когда разрабатывается большой проект, нужно помнить массу вещей. Производится большое количество документов, артефактов, решений, если это где-то не запомнить, то потом будет невозможно понять, для чего делается то или иное в проекте. В процессе разработки и реализации проекта появляется документация, но также важно помнить: «что мы решили?», «почему решили когда-то давно?». Если проект длится не один месяц и не один год, то это необходимо, потому что команда ротируется, команда растет, а если есть несколько человек, которые помнят все о проекте, не факт, что они будут работать над ним через полгода, через год. Важную информацию нужно фиксировать, и ход мыслей «почему что-либо было совершено» тоже лучше фиксировать. Это также касается записи собраний, экспериментов, чтобы что-то не проводить дважды, трижды. Для этого можно использовать GoogleSuite, таблицы, документы. Они удобны, в них могут одновременно работать несколько человек. Так же можно использовать сервис Confluence, он очень удобен для командной разработки.
Нужно работать по правилам. Одной из важных вещей инфраструктуры являются процессы, по которым работают. Нужно создать у команды общее понимание в тех или иных ситуациях, к кому обращаться, что делать, и в этом помогают процессы. Например, если нужно что-то нарисовать, нужно идти к художникам, или к какому-нибудь конкретному художнику, то есть к человеку, который исполняет определенную роль. Роли тоже нужно распределить. Необходимо определять задачи и работать над ними. Все это нужно делать, и это занимает время. Очень важно скоординировать работу между командами. Например, в начале разработки проекта вся команда находилась в одной комнате, потом команда выросла и стала находиться в двух, в трех комнатах, это сильно снижает уровень коммуникации. Если раньше можно было что сказать сидящему рядом коллеге, то сейчас нужно написать в чат, а его могут не прочитать. Получается, что некоторые несложные вопросы зависают и решения по ним не принимаются. Можно начать с простой инфраструктуры – поставить доску и вешать на нее заметки: что нужно сделать, когда, что важно, что неважно и т.д. Это хорошо работает, кода в команде от 4 до 5 человек. Когда людей в команде много, нужно их поделить на новые команды, в которых они будут заниматься определенным процессом. Эти процессы могут меняться.
Нужно управлять работой. Необходимо планировать работу на год, на полгода, потом это разбить на кварталы, на месяцы, на дни. Для мониторинга задач изначально можно использовать доску с заметками, но потом лучше использовать систему Trello или Jira.
Большой частью в разработке проекта являются технические решения. Например, если разработчиков много, то часть вопросов можно решить через внешние сервисы (Чаты, GoogleSuite), но не стоит полагаться только на них. Поэтому нужно предполагать несколько решений. Условно за центр можно взять серверы, которые предлагают много разных решений по обеспечению сохранности кода, по работе с задачами, по работе со знаниями. Также есть файловое хранилище, окружение для работы проекта, игровые «логи» (все данные, которые будут производиться проектом, их нужно хранить, с точки зрения аудита, для разбора каких-то ситуаций у пользователя, а также для аналитики). Необходимо иметь «бэкап», чтобы в случае проблемы все данные можно было восстановить.
Нужно хранить большой объём данных. Требуется хранить проект, потому что там проявляется достаточно много бинарных данных, это могут быть гигабайты, десятки гигабайтов данных. Нужно хранить оригинальные «ассеты», они могут достигать десятки терабайтов, это то, что создают в основном художники, также и аудиоинженеры. Это сырые исходные данные, то, из чего потом собирается проект, импортируются модели, текстуры, все что угодно. В качестве инфраструктуры выступает код. Артефактами являются «логи». В качестве хранилища можно использовать GoogleDrive.
Так как ожидается большое количество пользователей, то важным инфраструктурным вопросом является наличие большого количества «железных машин», которые должны обеспечить сессии пользователям. Хочется, чтобы весь этот «парк машин» работал предсказуемо, чтобы была возможность дополнять новыми машинами, или изымать другие машины. Будут сотни хостов, все это нужно обновлять, ставить «софт», как свой, так и чужой. Так как задача выглядит сложной, то нужно её полностью автоматизировать, то есть всё запрограммировать. Для этого можно выбрать Ansible («Используется для автоматизации настройки и развертывания программного обеспечения. »).
У всех участников проекта есть свои требования, которые могут противоречить друг другу. Часть людей, то есть разработчики хотят работать с нестабильным окружением. Им нужно очень быстро делать «фичи», запускать, смотреть, проверять их функционирование. С другой стороны, тестировщикам нужно стабильное окружение, чтобы провести весь цикл тестов. И, естественно, нужно стабильное окружение на «продакшн». Поэтому нужно развернуть подобные инфраструктуры для всего окружения, и уметь разворачивать разные версии приложений для него.
Важным вопросом является анализ рисков. Его нужно проводить раз в год, полгода, квартал. Могут случаться разные непредвиденные, в том числе форс-мажорные ситуации. Нужно подумать, что требуется сделать, чтобы этого не произошло, либо как можно больше снизить последствия всех этих рисков. Учёт возможных рисков помогает в планировании работы.
Также следует помнить о безопасности. Фактически, это – следствие рисков. Всё это не просто, так как могут быть физические угрозы безопасности (например, воровство компьютера), так и угрозы цифровой безопасности (например, вирусы). Дело в том, что проекты, как правило,стоят дорого, инвестор тратит деньги, и он не хочет, чтобы внезапно код сервера клиента оказался еще у кого-нибудь, и еще кто-то вместо того, кто платит деньги, стал зарабатывать. Необходимо защищать свои инвестиции.
Инфраструктура – это важно, но дорого, если ею серьезно заниматься, то это еще и сложно, и требует затрат времени. Из положительных черт можно выделить то, что в отличие от строителей домов, у разработчиков проекта есть возможность делать инфраструктуру интерактивно. Можно попробовать одно решение, или заменить его другим, может быть, более эффективным.Есть возможность делать фундамент даже во время «постройки» проекта.
Инфраструктура проекта зависит от инфраструктуры всей компании. Эффективные решения, уже используемые в компании, можно применять для управления проектом. Интересные решения, которые появляются в процессе работы над проектом, можно внедрить в деятельность компании для повышения её результативности.