Содержание:
Онлайн-митап по QA и Java, который мы провели 15 декабря, запомнился не только тем, что это была первая совместная конференция с нашим технологическим партнером, компанией IT_One, но и несколькими прозвучавшими со цены парадоксальными, на первый взгляд, утверждениями. Во-первых, о том, что в большой структуре с присущим ей уровнем бюрократии амбициозному айтишнику работать интереснее – масштаб задач там более глобальный. Во-вторых, что деньги при развертывании качественного банковского IT решают далеко не все. Например, в Газпромбанке, самом безопасном банке страны (так было заявлено на митапе) экосистема тестирования базируется на очень недорогом – либо вовсе Open Source – софте.
Митап начался с общей характеристики IT-ландшафта Газпромбанка. По словам зампреда правления банка Дмитрия Зауэрса, который отвечает за инновации и цифровую трансформацию кредитной организации, Газпромбанк серьезно продвинулся по пути цифровизации, несмотря на то, что запустил процессы диджитализации позже конкурентов.
Глубокая цифровая трансформация Газпромбанка началась около трех лет назад, когда он подключился к активной борьбе за розничного клиента. В отличие от конкурентов цифровизация в Газпромбанке в самом разгаре, многое нужно переделывать и перепридумывать. Поэтому наш банк – самое правильное место для амбициозных специалистов, которых привлекают большие и интересные проекты, а не то, что на сленге называется «полировать фичи и болты». «С нами вы можете сильно вырасти», – констатировал Дмитрий Зауэрс.
Для IT-специалистов Газпромбанк перспективен тем, что он довольно стремительно движется по пути перестроения из организации, которая прежде заказывала решения на аутсорсе, в продуктовую компанию. «Поэтому нам нужны сильные инженеры, которым нравится делать интересные и коммерчески успешные продукты, решающие проблемы клиентов банка», – сказал первый вице-президент Алексей Ульенков, курирующий в Газпромбанке продуктовую разработку в рознице. Хотя к нашей команде Алексей присоединился недавно, он уже сделал два любопытных наблюдения и поделился ими с аудиторией митапа. Во-первых, в рознице очень мало унылого legacy, которое так не любят в IT-сообществе и, во-вторых, процесс разработки в Газпромбанке – нескучное и очень динамичное занятие, связанное с огромным количеством новых вызовов, постоянной генераций свежих идей и созданием продуктов, запускаемых буквально каждый день.
Темп разработки будет только нарастать с учетом того, что минувшей осенью Газпромбанк и компания IT_One, которая реализует крупнейшие проекты цифровой трансформации в РФ, создали совместное предприятие – «ГПБ-ИТ1». Руководитель этой компании Андрей Лисневский не сомневается: сообща нам под силу сформировать уникальный клиентский продукт, лучший на рынке. На митапе Андрей поделился некоторыми планами «ГПБ-ИТ1» на ближайшее будущее. Это, в частности, развитие конвейерных технологий, сервисов и услуг в рамках экосистемы Газпромбанка, а также направления Data Science для выработки персонализированных предложений клиентам банка. В зоне пристального внимания – наращивание экспертизы и создание в орбите «ГПБ-ИТ1» мощного технологического комьюнити.
Трек по QA
Что до содержания основных выступлений на митапе, тематически поделенном на два направления, QA и Java, то первыми в треке Quality Assurance выступили Кирилл Гилевич и Антон Кадников из Газпромбанка. Кирилл (отвечает за общую методологию тестирования и автоматизированное тестирование в частности), а Антон (занимается экосистемой автоматизированного тестирования) предложили аудитории подробный обзор технологий и инструментов, применяемых в Газпромбанке.
Основная проблема, с которой несколько лет назад столкнулись команды, состояла в недостаточной коммуникации между тестировщиками, разработчиками и аналитиками во время работ по тестированию, а также в отсутствии единого инструмента для управления тестированием, ведения тестовых моделей и регистрации результатов. Требования к инструменту выдвигали очевидные: возможность хранить тестовые модели, результаты и прочее, верифицировать данные, особенно в тех случаях, когда интеграционным и регрессионным тестированием заняты две (и более) команды и так далее.
При выборе, вспоминает Кирилл Гилевич, исходили из целого комплекса пожеланий. Так, например, среди прочего нужно было минимизировать затраты на интеграцию между существовавшим на тот момент решением для ведения задач (Jira), не зависеть от внешних вендоров, продумать, как упростить его внедрение с учетом строгих банковских требований к ИБ, создать единое пространство для процессов разработки, аналитики и тестирования.
В итоге выбор был сделан в пользу плагина XRay. Из-за того, что это плагин для Jira, он гармонично встроился в производственные процессы и вписался в учет задач по разработке. Наличие хорошей компетенции по развитию и сопровождению продуктов Atlassian помогло нам минимизировать затраты на внедрение и настройку инструмента.
Одна из сложностей, с которой столкнулись коллеги, – отсутствие русифицированной документации. С этим они справились довольно легко, самостоятельно разработав удобный набор инструкций на русском языке. Кроме того, у XRay довольно скудная штатная отчетность. Это недочет обошли благодаря тому, что в Газпромбанке к тому моменту были сформированы довольно серьезные компетенции по построению сквозной отчетности по данным в Jira на стандартных инструментах.
Что в итоге? Связку Jira-XRay в Газпромбанке используют довольно активно: Кирилл Гилевич оценивает количество ее пользователей примерно в 3 три тысячи человек. Иными словами, каждый седьмой сотрудник банка –косвенный пользователь инструмента, а непосредственными участниками различных работ по тестированию являются около 700 пользователей. Заведено более 80 тысяч тестовых сценариев, реализовано более 10 тысяч test execution. Вполне убедительный результат.
Выступивший следом Антон Кадников сосредоточился на инструментах для автоматизации тестирования. Пожелания команды Антона были просты и очевидны: у внедряемого решения должен быть позитивный опыт использования в других организациях; на рынке должны быть сформированы компетенции по его применению, чтобы и у стартовой команды и у тех, кто вольется в коллектив позже, не было проблем с имплементацией; должны наличествовать онлайн-сообщество и документация для быстрого решения возникающих по ходу внедрения проблем, а инструменты – постоянно развиваться.
Набор, выбранный для автоматизации тестирования, не поражает оригинальностью. Зато он добротный, современный и вполне рабочий.
Примечательный момент, связанный с фигурирующим на иллюстрации кроссплатформенным инструментом Appium. Это важный элемент создаваемой в банке лаборатории тестирования на мобильных устройствах. Сейчас мы находимся на этапе ее пилотного проекта и готовимся к промышленной эксплуатации.
Резюмируя. Кирилл и Антон раскрыли много интересных технических и организационных подробностей того, как формировалась экосистема тестирования в Газпромбанке и почему это происходило именно так. Вывод, который они сформулировали, звучит следующим образом: «Если вы работаете в большой организации с ограничениями по инфобезу и условно без ограничений по финансам, это не означает, что нужно выбирать дорогие коробочные решения. Кто хочет, ищет возможности, кто не хочет, найдет дорогое решение».
Трек по Java
Трек по Java открыл Максим Тихонов из Газпромбанка, который рассказал о том, почему стоит переходить на Java 17. Сейчас в банке используется 11-я версия, и сходу перейти на новую не выйдет: нужно дождаться, когда базовые фреймворки начнут ее поддерживать. Но коллеги решили в деле проверить, что может Java 17 уже сейчас. И на личном опыте убедились, что у нее есть ряд существенных преимуществ: новые фичи, скорость и безопасность.
Максим рассказал, как протестировали «сборщиков мусора», чтобы узнать, какой работает лучше в новой «джаве», — ZGC или Shenandoah (спойлер: ZGC) и для интереса сравнили их с коллекторами в JDK 8. Проверили, что лучше , Record или Lombok, а еще ускорили с помощью Native консольное приложение на основе picocli в 20 раз!
От наших технологических партнеров «ГПБ-ИТ1» выступил Никита Калашников с рассказом о том, что нет ничего более постоянного, чем временное. Когда в банке запускался «кредитный конвейер», система хранения документов была еще в разработке, и ее релиз отставал от релиза «конвейера». Поэтому пришлось быстро внедрять временное решение на основе JackRabbit.
Когда пришло время перейти с временной системы на «постоянную», оказалось, что решение на JackRabbit отлично дополняет ее и помогает быстро справляться с некоторыми специфическими задачами, которые не были предусмотрены в новой системе.
Никита рассказал о том, как создавалась и внедрялась система, с какими проблемами пришлось столкнуться (как справки 2НДФЛ нагружали систему) и какие структурные проблемы системы пришлось решать в процессе.
С последним докладом трека выступил Олег Докука, который говорил об особенностях реактивной разработки на Java. Сам автор назвал свой доклад «Доклад об очевидном» и прошелся по основам реактивного программирования, рассказал, стоит ли связываться с ним (стоит, если хотите повысить производительность своих сервисах и лежит душа к функциональному программированию), об инструментах и основных приемах и посоветовал, в какую сторону двигаться, если хотите разобраться в «реактивщине».
