CI/CD в геймдеве. Интервью с Александром Наливайко
Даже в игре есть свой офис, где здесь место для DevOps`а?
Один амбициозный и смелый парень, которого зовут Саша, настолько вдохновился практикой CI/CD в работе, что готов всем вещать, что за ней будущее. Вдохновились и мы: провели интервью и расспросили об опыте внедрения этой практики, о том, почему же CI/CD точно будет инструментом будущего и курсе Слёрм по CI/CD, который Саша изучал.
Для начала расскажи в паре предложений о себе, чтобы у читателя появилось четкое понимание, почему именно ты делишься опытом и чем он может быть полезен.
Я работаю в Банке ВТБ (ПАО) на позиции старшего Java-разработчика. Помимо основной работы у меня есть подработка в сфере, которую я очень люблю, — видеоигры. Игры — мое хобби с детства. Для меня они стали толчком для развития в IT-сфере, где я уже чуть больше 5 лет. За это время я успел воспитать пару Junior-разработчиков и запустить несколько MVP стартапов. Мне нравится делиться информацией, поэтому хочу рассказать о своем видении важности DevOps-инженеров в геймдеве, а в частности о CI/CD методологии и почему её, к моему удивлению, внедряют не все игровые проекты.
В геймдеве ты подрабатываешь тоже разработчиком?
Нет, создавать игры не было желания, был интерес просто быть в этой сфере, помогать командам, автоматизировать процессы, которые бы улучшали всевозможные механики. Поэтому я выбрал для себя роль самоучки DevOps-инженера. Выбрал для себя нишу мультиплеерных игровых серверов игры Grand Theft Auto. Там я оттачиваю навыки и мастерство, которые точно пригодятся в будущем.
Какие основные проблемы в сфере геймдева ты бы выделил?
Через сарафанное радио я понял, что всё там очень плохо, к сожалению. Только единицы проектов могут позволить себе автоматизацию рабочих процессов, CI/CD ту же. От этой ситуации становится грустно. Почему сейчас, когда существует так много крутых технологий, эта сфера, которая настолько популярна, ими не прокачана? В интервью хочу донести важность и полезность CI/CD в работе для многих людей, вовлеченных в процесс разработки игровых серверов в данной нише. Я готов помогать, мне это нравится.
Когда ты прошел обучение в Слёрме? Чем оно тебе помогло?
Сначала скажу, что на обучение меня сподвиг вопрос, который я озвучил ранее: почему в геймдеве не используют CI/CD? Я прошел обучение по работе с этим инструментом. Это очень крутой курс, ребята. Я получил мощный толчок и мотивацию к освоению этой сферы. Это было летом 2021 года.
С момента твоего обучения прошел примерно год. За это время ты успел убедиться в том, что инструмент CI/CD действительно так важен в работе, как тебе казалось?
Абсолютно. Я еще больше убедился в том, какую огромную нагрузку из задач, не всегда нужных, дают разработчикам. Мне кажется, разграничение ответственности очень важно. Сейчас далеко не везде оно есть, и это грустно. CI/CD как раз помогает навести этот порядок и снять нагрузку с тех, кому она изначально и не нужна была. То есть разработчики пишут код, продумывают архитектуру. Тестировщики могут не отвлекая разработчиков самостоятельно установить на внутренние сервера проекта те или иные сборки с новым функционалом и протестировать их. Системные администраторы и DevOps-инженеры автоматизируют процессы, чтобы все изменения без перебоев и вовремя доезжали до production-контура, чтобы тестирование шло так, как надо, и обратная связь приходила также вовремя.
Как думаешь, почему CI/CD пока еще мало распространен?
На практике я вижу, что не все руководители проектов понимают, зачем им этот инструмент. Они скорее наймут больше разработчиков или начнут нагружать текущих, а обучаться новому долго и дорого. К тому же обучение «техникам DevOps«а» не из легких, надо это тоже понимать, не все проекты и люди к этому готовы, как материально, так и физически. А еще многое зависит от бюджета проекта: часто руководители не хотят тратиться на что-то незнакомое и новое.
Чем хорош CI/CD?
Она помогает скорее выпускать фичи на стенды. Чем быстрее разработчик предоставит новый функционал, тем быстрее ее протестируют и тем быстрее получат обратную связь, например, о необходимости доработки. Особенно это заметно при работе с микросервисной архитектурой. Непрерывная доставка — это главное достоинство CI/CD. Обычно время установки обновлений на игровых проектах — это поздняя ночь. Мало кому хочется, скажем, в четыре утра сидеть и что-то устанавливать. Проще запланировать автоматическую установку и пойти спать. Вот в этом в том числе CI/CD и помогает упрощать и жизнь, и работу. Еще при применении риски что-то поломать сведены к минимуму, так как процесс автоматизирован. Всегда можно безболезненно сделать регресс, и никто ничего не заметит.
Может ли вообще понадобиться откат до предыдущей версии?
Может. Например, в случае, если кто-то что-то недоглядел. Но это скорее человеческий фактор, такое нечасто случается, но бывает. Если все процессы продуманы и выстроены грамотно, то нерабочая версия просто не пройдет. Хотя в IT бывает много мистики необъяснимых вещей.
Ты обучился, полон знаний и вдохновения. К какому проекту ты пришел со всем этим, чтобы реализовать полученное на практике?
За этот год у меня было несколько проектов: два из них скоропостижно закрылись, поскольку закончилось финансирование, а над третьим я работаю до сих пор. Это один из самых популярных в СНГ комплекс игровых серверов на сегодняшний день — GTA Province, игра в жанре реальной жизни (Role Play). Основатели данного проекта, Дмитрий и Данил, ответственно подошли к разработке. У них есть семь игровых серверов. Суммарный пиковый онлайн достигал 5200 человек, но это далеко не рекорд.
Сейчас проект дополнительно движется в другом направлении с целью расширения аудитории, но все так же в игровом. Мне же предложили взяться за настройку с нуля всей технической инфраструктуры. Хочется продумать все до мелочей, использовать накопленный опыт. Мы решили использовать микросервисы, потому что хотим получить отказоустойчивую, легко изменяемую, масштабируемую систему: сегодня у нас 5000 игроков, а завтра уже 20000. Важно быть готовыми к таким изменениям.
С чего ты начал прорабатывать задачу?
Я начал с разграничений серверов, предоставленных для внутренних нужд. Необходимо было четыре контура для разработки:
develop — автоматически развертывается код из репозитория в ветке development. Не всегда стабильна, но и не должна быть таковой, «песочница» для разработчиков;
test — тестировщики (или любой другой член команды) может поставить свою сборку тех или иных сервисов вручную;
staging — стабильная копия production;
сервер-пустышка под создание фото/видео контента (красивые картиночки лишним не будут).
Мы любим Docker, и активно применяем его в работе. Сервисы упаковываются в контейнеры, проходят от первого до третьего этапа, тестируются. Только в таком случае можно гарантировать его работоспособность.
На мой взгляд, этого вполне достаточно для старта разработки. Добившись стабильной работы этих контуров и развертывания сервисов на них через CI/CD, можно сказать, что скелет заложен. Мы используем self-hosted GitLab и его встроенные возможности, начиная от хранения общих библиотек для микросервисов, образов контейнеров, и заканчивая CI/CD скриптами, статическим анализатором кода.
После того как все настроено, нужен ли какой-то дополнительный контроль с твоей стороны? Или настроил — и забыл?
Скорее да, чем нет. Если говорить конкретно про мой текущий проект, то там я слежу за тем, что происходит. Дополнительно нас есть telegram-бот, который информирует нас о всех важных событиях из GitLab: пуш, сборки, merge request«ы. Наша команда тоже уведомляет меня, если где-то что-то не работает. Мы изначально договорились использовать Prometheus. В планах сделать публичную страницу с информацией о работоспособности всех наших публичных сервисах, например, как продукт от Atlassian Opsgenie, чтобы игроки могли понимать, что сейчас происходит.
Если нет CI/CD, как тогда выглядит процесс?
Коллеги из других проектов рассказывают, что это bash скрипты, разбросанные по всем серверам, если их несколько. Их основная задача — из директории A положить файлы в директорию B, перезапустить требуемый сервис. Это в лучшем случае. Порой проекты остаются на той стадии, когда надо вручную через sFTP положить скомпилированные файлы, и также перезапустить сервис. Такая организация работы называется полуручной.
Но с таким подходом мне жалко людей и их время.
Я заметил, что ⅓ проектов, которые не применяют в практиках CI/CD методологию, после открытия практически сразу закрываются, не успевают за потоком быстрых доработок, получая негодование и огорчение игроков. Они, скорее всего, уйдет в другой игровой проект. А если нет игроков — ты бесполезен на рынке.
Пробовал ли ты внедрить свои идеи в уже существующих проектах?
В моей практике пока были лишь небольше стартапы. С ними такая история: им терять нечего, если что-то где-то сломается, то не страшно. Те проекты, которые закрепились на рынке и имеют свою постоянную аудиторию, относятся к внедрению чего-то нового скептически.Чувствуется недоверие, что придет какой-то человек, начнет что-то ломать, пусть и во благо. В этом они видят сплошные риски и страх, какие бы положительные доводы я ни приводил. И их можно понять, это психология, мы все так устроены, поэтому никогда не настаиваю.
К счастью, изменения в проекте, которым я сейчас занимаюсь, видят основатели. Они понимают, что это важно быть в тренде технологий, если хочешь быть на данном рынке и действительно работает на практике. Но как бы ни хотелось всё бесконечно улучшать, важно напоминать себе, что «лучшее — враг хорошего». Если всё и так работает, не надо без особой надобности в это лезть. Баланс всегда важен.
После внедрения CI/CD ускоряется разработка?
Конечно. Это происходит за счет того, что код разработчика быстрее попадает на тестирование, быстрее появляется обратная связь. Как следствие, все укладываются в обозначенный дедлайн. Мне кажется, что в IT всё особенно быстро и автоматизировано должно происходить.
Ты говоришь о внедрении CI/CD в своей работе на фрилансе. А в своей основной работе это тебе не нужно?
Благо и у нас на работе есть DevOps«ы, но CI/CD именно там для меня пока что некая магия. Есть определенные шаги, которым нужно следовать в работе, чтобы функционал уехал на тот или иной контур, к слову, их гораздо больше, чем 3. Нам о них рассказал DevOps-инженер. Там всё и без меня уже хорошо работает, мое участие в этом особо и не нужно. А вот на фрилансе я рассказываю и сталкиваюсь с тем, что я знаю. В банке отлаженные процессы очень важны. Там ведь высокий уровень обеспечения безопасности. Для меня DevOps-инженеры в банке — это супергерои. Не представляю, как в такой системе можно угодить всем.
Везде ли можно внедрять CI/CD, или существуют какие-то ограничения или исключения?
Если речь идет об IT-сфере, то, я думаю, что везде. Критерием может являться масштаб проекта. Небольшому стартапу на пару дней это может и не нужно, но на долгосрочную перспективу для быстрорастущего проекта никуда, потому что, если нет внедрения, то появляются те проблемы, о которых я сказал ранее.
Уменьшилась ли твоя вовлеченность в процесс развертывания изменений на продакшене после внедрения?
Не скажу, что она уменьшилась, местами она даже увеличилась. Как правило, я что-то постоянно улучшаю, поправляю, ведь появляется обратная связь. Но тут важен баланс, о котором я тоже уже говорил. CI/CD не столько уменьшает вовлеченность, сколько упрощает работу и помогает членам команды не дергать друг друга лишний раз по разным вопросам.
Что такое динамическое окружение? Нужно ли оно в работе?
На курсе Слёрма об этом говорят, кстати. Динамическое окружение — это временная среда, которая помогает разработчику сразу же протестировать изменения на этапе код-ревью. Предоставляется из коробки внутри сервиса GitLab. Для использования нужно подружить GitLab и ваш Kubernetes кластер, после чего прописав необходимые скрипты в файл gitlab-ci.yml. На мой взгляд, оно нужно, но на практике не видел применения. Возможно, причина в том, что не все проекты используют GitLab, а то и вовсе обходятся без системы контроля версий. Постараюсь на одном из следующих проектов реализовать это, попробовать, собрать экспертизу и обратную связь.
Можешь выделить наиболее частые ошибки при внедрении CI/CD?
Главная ошибка — нечеткая проработка того, что именно требуется от системы. Например, если нужно просто установить сервис на сервере, то этого мало. Потенциальный заказчик не всегда может сформулировать то, что ему нужно. Если использовать слишком много возможностей CI/CD, то можно уйти в такие дебри, создать такого монстра, который на каждый чих будет реагировать. Но заказчик явно хотел не этого. Именно поэтому важно четко определить, что именно нужно от сервиса, а инженер должен уметь и понимать, что ему нужно делать.
Получается, главная ошибка не столько техническая, сколько коммуникационная. Какие последствия могут быть, если на берегу нет четких целей и задач?
Одно из основных последствий — финансовые потери. Если в штате нет DevOps-инженера, его приглашают со стороны на те или иные доработки. Он видит процесс по-своему. Если четко не оговорить всё, что нужно, он может углубляться и углубляться в задачу, а компания будет оплачивать всё большее количество часов его работы. Отсюда нагрузка на бюджет, на сервис, но впоследствии может оказаться, что заказчик вообще хотел что-то другое, и вся работа проделана чуть ли не зря. Если нет недопониманий, то нет и лишних додумываний о том, кто что имел в виду. Настройка CI/CD довольно сложная, поэтому важно заранее учесть все возможные составляющие.
Как думаешь для кого был бы полезен курс по CI/CD от Слёрма?
В первую очередь, для очень любознательных Junior разработчиков и DevOps-инженеров. Джунам вообще полезно знать все этапы от разработки до выхода кода в production.
Посоветую курс и Middle-разработчикам, увязшим только в программировании. Очень важно расширять кругозор, чтобы больше зарабатывать. Чем больше человек знает сейчас, тем лучше для него. Чем он компетентнее, тем больше нужен рынку и больше пользы может принести. Я думаю, если человеку интересно изучать что-то новое, то попробовать стоит. Никто же требует полностью лезть в методологии и практики DevOps, но понимать этапы деплоя и какие-то базовые вещи все-таки важно.
Хватило ли тебе полученной информации или пришлось что-то где-то доучивать?
Доучивал и досматривал. Не существует серебряной пули, получив которую я бы знал то, что мне нужно здесь и сейчас. Так устроена наша IT-сфера, что учиться нужно постоянно. Курсы Слёрма дают хороший толчок и мотивацию для освоения чего-то нового. Курс по CI/CD был очень крутой: в программе не было воды, можно было попрактиковаться, изучить базу на понятном языке. Меня он раззадорил: я хоть и джавист, но мне нравится DevOps, и что теперь делать? Хотя Java разработчики со знанием DevOps на рынке высоко ценятся: в этом я убедился, когда искал работу. Чем больше знаний ты знаешь и опыта имеешь, тем выше на тебя спрос.
Habrahabr.ru прочитано 6428 раз
