Содержание:
Для разработки банковских сервисов надо использовать самые свежие версии языков разработки, операционных систем и прочего ПО. Но для этого нужна почти непрерывная миграция с одной версии на другую. При этом переход должен быть плавным, чтобы не возникали проблемы совместимости, ошибки и сложности при изучении новых инструментов.
Сергей Богданов, начальник Управления технологий универсальных омниканальных сервисов, рассказал, как сообщество разработчиков Газпромбанка мигрирует с одного языка разработки на другой и зачем это нужно.
Эксперимент с миграцией на Kotlin
В 2018 году мы решили протестировать новый инструмент — язык программирования Kotlin. Это усовершенствованная версия Java c некоторыми дополнительными возможностями. Нам хотелось узнать плюсы и минусы Kotlin и понять, можно ли использовать его как основной язык для разработки омниканальных сервисов в Газпромбанке.
Раньше мы работали на Java 8. До сентября 2018 года это был основной релиз Java для коммерческой разработки инструмента. На эксперимент выделили полгода — за это время нужно было сравнить Kotlin с Java 8 и решить, меняем ли мы язык. Задачи полностью перевести на Kotlin всех разработчиков не было, но хотелось дать ребятам возможность совершенствоваться в профессии.
Эксперимент решили не выносить в отдельный процесс. Несколько разработчиков, которые захотели изучить Kotlin, просто стали использовать его вместо Java 8.
Сложности во время эксперимента
Сама по себе миграция на Kotlin была несложной. Хороший Java-программист может разобраться в Kotlin за 2–3 недели. Но если использовать два языка в одном проекте, могут появиться непредвиденные сложности.
Kotlin и Java — легко совместимые языки. Kotlin, по сути, расширенная версия Java: у языков схожие синтаксис и функциональность. Но выяснилось, что при определенных условиях конфликты всё равно возникают.
Например, если в микросервисе на Java используется внешняя библиотека Lombok, то добавлять код на Kotlin нельзя. Проект при компиляции выдает ошибку. Она связана с тем, что в Kotlin функции из Lombok реализованы нативно, без внешней библиотеки. Решить проблему можно, только если переписать микросервис целиком на одном языке.
Дополнительной сложностью стало то, что в IDEA не подгружала исходные тексты кода, который был написан на Kotlin. Это усложняло ревью и поддержку кода. В проектах на чистом Java такого не происходило: всегда можно было посмотреть исходный код.
Результаты эксперимента
В начале 2019 года эксперимент закончился. Мы считаем, что он прошел удачно: некоторые разработчики перешли на Kotlin и стали постоянно использовать его в своих проектах. Но большинство вернулись к более привычному Java. Сейчас на Kotlin пишут примерно 10% разработчиков розничного бизнеса в Газпромбанке.
Мы разрешаем командам выбирать, какой язык они будут использовать. Единственное ограничение — ключевые сервисы, от которых зависит работоспособность всей системы, можно писать только на Java. К ним относится, например, сервис управления справочниками. Его постоянно используют разные команды в своих проектах, поэтому нужно избежать даже маловероятных проблем с совместимостью.
Еще на Java обязательно пишут общие библиотеки, которые многократно переиспользуют. Для библиотек важно, чтобы любой разработчик мог получить доступ к их исходному коду, а Котлином на нужном уровне владеют далеко не все.
Миграция на Java 11
В 2020 году мы использовали в основном Java 8. К этому времени уже вышла 11-я версия, поэтому мы решили, что пришло время для обновления. На тот момент миграция была нужна, чтобы:
- Не отстать от отраслевых стандартов. Чтобы успевать за требованиями и задачами банковской сферы, нужны современные инструменты. Если бы мы продолжили работать с Java 8, мы со временем отстали бы от конкурентов.
- Привлечь лучших сотрудников. Одно из конкурентных преимуществ работодателя — свежие технологии в стеке разработки. Благодаря миграциям с одного языка на другой, наши инструменты не устаревают.
- Соблюсти требования безопасности. Важно, чтобы каждая система вовремя обновлялась. Старые версии часто не обновляются вообще или делают это с опозданием.
Для перехода важны были возможности Java 11, которых не было в старых версиях:
- компактные строки, которые экономно используют память;
- улучшенная работа в контейнерах;
- автоматический вывод типов переменных.
Результат миграции на Java 11
Java — один из языков, который можно автоматически совместить с его предыдущими версиями. Поэтому особых трудностей во время миграции не было.
Возникали небольшие сложности, которые быстро разрешались. Например, часть старых протоколов и библиотек, которые работали в Java 8, в 11-й версии были по умолчанию отключены. Их нужно было подключить вручную — это позволило избежать проблем.
Другой пример: некоторые библиотеки из стандартных стали внешними, то есть их тоже надо было руками подключать в коде.
Мы завершили миграцию в 2021 году. Главный ее результат — смогли наладить и отработать процесс технологического обновления. Это важно, потому что переход происходит в одно время на разных инструментах: нужно обновлять операционную систему, переносить базы данных, устанавливать новые версии фреймворков.
Теперь у нас есть алгоритм, который позволит заранее планировать миграции и не нарушать при этом процесс разработки.
Какие этапы миграции мы выделили
Для любого инструмента, не только языка программирования, мы предусматриваем семь этапов.
- Знакомство с новым релизом инструмента или с новым продуктом. На этом этапе узнаём, что интересное появилось, читаем информацию о продукте, изучаем различия между версиями.
- Локальное тестирование инструмента. Один или несколько человек пробуют новую версию или продукт. Затем, через одну или две недели, они делятся впечатлениями. Обратная связь помогает решить, нужна миграция или нет.
- Начало миграции. На этом этапе инструмент тестируют разработчики. Некоторое время они изучают его все вместе, ищут проблемы и ошибки совместимости.
- Миграция тестовых сред. Когда становится понятно, что на этапе разработки с новым инструментом не возникает проблем, его устанавливают на тестовые среды. При этом всё еще обеспечиваем полную совместимость со старой версией. Например, не используем фичи, которые доступны только в новой версии.
- Обновляем боевые среды. Еще раз проверяем, что все старые проекты совместимы с новой версией инструмента или обновлены. Несколько недель ждем, чтобы найти какие-то редкие проблемы.
- Завершаем миграцию. Отключаем совместимость с предыдущей версией платформы и начинаем использользовать фичи новой версии.
Разные инструменты могут одновременно находиться на разных этапах. Мы не заменяем разом всё, а планируем будущие обновления плавно, по мере необходимости.
Например, сейчас миграция на Java 11 завершена, а переход на новую версию PostgreSQL в самом разгаре. После нее мы можем сразу запланировать новую. Так, в 2022 году мы начали миграцию на Java 17. Думаем, что сможем завершить ее к лету.
Для наших сотрудников переход с одного языка программирования на другой — привычная часть работы. Применение новых технологий дает разработчикам опыт, который помогает им расти внутри компании.
