НАШИ
РАБОТЫ
Блог Контакты Услуги RU_PORT Наша
команда
Мы
побеждаем
Наши
клиенты
Мы
ищем
Мы —
RUPORT

Portfolio Blog Contacts Team Clients RU_PORT Vacancies Services We are RUPORT Awards
Branding Digital and mobile Media Брендинг Digital и mobile Видео Реклама Video Advertisement

Под капотом IT-проектов Ruport

<p>За окном суббота. Барабанщик моей группы укатил на гастроли со второй командой, а басист испарился из города по случаю отпуска (впрочем басисты часто испаряются и без каких-то случаев). Сегодня от кодинга я решил воздержаться, но внутри что-то свербит и требует действий.</p> <p>&nbsp;</p> <p>Расскажу о том как в нашей компании строятся it-проекты под капотом. Все воспринимают Ruport, как ребят, делающих нечто красивое, забубенное и дорогое. Но это только внешняя часть. Это то, что доступно к оценке глазами или через клик в интерфейсе. Подводная часть всегда остается незамеченной. Про неё вспоминают только тогда, когда случается факап.</p> <p>&nbsp;</p> <p>Я искренне считаю, что внутренняя часть приложения должна полностью соответствовать его одежке. Если красиво и чисто снаружи &mdash; значит так должно быть и внутри. У технических специалистов рассказанное не вызовет удивления. То, о чем я напишу являются стандартами уже лет пять, а то и больше.</p> <p>Начну издалека. Все проекты, которые выходят за рамки &quot;смотрите какие красивые шубы шьет наше ателье&quot; мы пишем на основе домена предметной области. Если предполагается активное взаимодействие пользователей с интерфейсом, которое влечет за собой модификацию данных, включается режим &quot;пишем домен&quot;. Наши менеджеры в теме этого процесса и принимают в нем активное участие.</p> <p>Из терминов, которыми клиент описывает свой бизнес, мы формируем словарь. В дальнейшем, при любом обсуждении проекта мы пользуемся этим словарем. Этот момент может показаться незначительным. На самом деле это самая важная часть разработки.</p> <p>В процессе обсуждения бизнес-логики приложения мы стараемся избегать каких-либо ограничений из ряда &quot;это сделать нельзя или это очень сложно&quot;. Здесь у нас идет чистый поток сознания менеджеров и клиента. Разработчики, присутствующие на встречах, либо выполняют роль слушателей, либо предлагают свои идеи к реализации. Фундамент бизнес-логики закладывается в максимально комфортной среде без каких-то технических ограничений.</p> <p>Дальше прототипы. Как по мне &mdash; код писать гораздо проще (особенно опираясь на хорошие прототипы). Разработчики их отсматривают, но и здесь бэкенд не вклинивается с &quot;а вот это нельзя&quot;. Только в самых экстренных случаях, но такое бывает очень редко.</p> <p>После утверждения прототипов начинается разработка приложения. К этому моменту у нас есть словарь и полное понимание того, как все должно работать. Чаще всего мы делаем SPA и несколько API для каждой части приложения. Это не RESTful, но мы к нему стремимся настолько, насколько это возможно.</p> <p>Разработка бэкенда ведётся по принципу &mdash; написали атомарную часть кода, покрыли тестами, описали её в Apidoc. Тесты, для снижения нагрузки на их сопровождение, всегда сквозные. Что это значит? На вход приложения подается запрос (как настоящий), после чего тест проверяет наличие правильно модифицированных данных на уровне их хранения (база данных или файловая система). Таким образом мы можем крутить как угодно все, что между &quot;вошло&quot; и &quot;вышло&quot;.</p> <p>Документирование API в разработке бэкенда является жестким требованием. Таким образом фронтенд разработчики имеют всегда актуальную версию описания. Эта документация является главной связью между нашими командами бэкенд и фронтенд.</p> <p>Бэкенд пишется слоями. Это не &quot;чистый&quot; домен (как в книгах), но достаточно близко к нему. Приложение режется вертикально на контексты (например identity, market, exchange и пр. в зависимости от приложения) и горизонтально на слои (model, application, ui). Главная цель - разбить весь код на небольшие фрагменты с четко очерченными зонами ответственности.</p> <p>Были прецеденты, когда мы делали сложные изменения бизнес-логики за несколько дней благодаря именно этому подходу. Конечно же у нас были тесты. Тесты пишутся на любой новый код сразу. Это тоже жёсткий регламент.</p> <p>Дальше в Gitlab мы собираем конвейер CICD который обеспечивает:</p> <ul> <li>1. Запуск статических анализаторов кода</li> <li>2. Запуск юнит тестов</li> <li>3. Запуск сквозных тестов</li> <li>4. Билд клиентской части приложения</li> <li>5. Доставку новой версии на сервера</li> </ul> <p>Попадание кода в репозиторий и, в конечном счёте, на сервер возможно только при условии успешного выполнения всех этапов конвейера. Код-ревью делается только для кода, который успешно прошел все автоматические тесты.</p> <p>Приложение имеет сервера:</p> <ul> <li>1. Production (веб, обработчики очередей и заданий)</li> <li>2. Release &mdash; используется для проверки Production версии перед попаданием на продуктовый сервер</li> <li>3. Develop &mdash; используются для проверки нового функционала в ручном режиме</li> </ul> <p>Для управления кодом мы используем Gitlab. Для управления нашими серверами Ansible. Деплоим атомарно. Атомарный деплой означает, что приложение переключается на новую версию в один момент. В качестве базы чаще всего мы используем Postgresql. Ничего против других решений не имеем, просто эта база нам нравится больше. Вкусовщина во всей красе.</p> <p>Мониторинг. Конечно же он есть. Мониторим через Prometheus и Grafana три слоя:</p> <ul> <li>1. Сервер</li> <li>2. Софт</li> <li>3. Приложение</li> </ul> <p>Уровень мониторинга приложения отслеживает:</p> <ul> <li>1. Медленные ответы бэкенда</li> <li>2. Ответы с ошибками</li> <li>3. Распределение времени генерации ответа по слоям (код, база, кэш, ответы внешних систем и пр.)</li> <li>4. Критичные бизнес-события (логины, регистрации и пр.)</li> <li>5. Счетчики всех сущностей</li> <li>6. ...</li> </ul> <p>Дмитрий Демидович, senior back-end разработчик.&nbsp;</p>