Миграция со старых версий ПО на свежие: опыт Газпромбанка
На этой странице

Эксперимент с миграцией на Kotlin

Сложности во время эксперимента

Результаты эксперимента

Миграция на Java 11

Результат миграции на Java 11

Какие этапы миграции мы выделили



Тэги
технологии разработка
Миграция со старых версий ПО на свежие: опыт Газпромбанка

Для разработки банковских сервисов надо использовать самые свежие версии языков разработки, операционных систем и прочего ПО. Но для этого нужна почти непрерывная миграция с одной версии на другую. При этом переход должен быть плавным, чтобы не возникали проблемы совместимости, ошибки и сложности при изучении новых инструментов.

Сергей Богданов, начальник Управления технологий универсальных омниканальных сервисов, рассказал, как сообщество разработчиков Газпромбанка мигрирует с одного языка разработки на другой и зачем это нужно.

Эксперимент с миграцией на 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-я версия, поэтому мы решили, что пришло время для обновления. На тот момент миграция была нужна, чтобы:

  1. Не отстать от отраслевых стандартов. Чтобы успевать за требованиями и задачами банковской сферы, нужны современные инструменты. Если бы мы продолжили работать с Java 8, мы со временем отстали бы от конкурентов.
  2. Привлечь лучших сотрудников. Одно из конкурентных преимуществ работодателя — свежие технологии в стеке разработки. Благодаря миграциям с одного языка на другой, наши инструменты не устаревают.
  3. Соблюсти требования безопасности. Важно, чтобы каждая система вовремя обновлялась. Старые версии часто не обновляются вообще или делают это с опозданием.

Для перехода важны были возможности Java 11, которых не было в старых версиях:

  • компактные строки, которые экономно используют память;
  • улучшенная работа в контейнерах;
  • автоматический вывод типов переменных.

Результат миграции на Java 11

Java — один из языков, который можно автоматически совместить с его предыдущими версиями. Поэтому особых трудностей во время миграции не было.

Возникали небольшие сложности, которые быстро разрешались. Например, часть старых протоколов и библиотек, которые работали в Java 8, в 11-й версии были по умолчанию отключены. Их нужно было подключить вручную — это позволило избежать проблем.

Другой пример: некоторые библиотеки из стандартных стали внешними, то есть их тоже надо было руками подключать в коде.

Мы завершили миграцию в 2021 году. Главный ее результат — смогли наладить и отработать процесс технологического обновления. Это важно, потому что переход происходит в одно время на разных инструментах: нужно обновлять операционную систему, переносить базы данных, устанавливать новые версии фреймворков.

Теперь у нас есть алгоритм, который позволит заранее планировать миграции и не нарушать при этом процесс разработки.

Какие этапы миграции мы выделили

Для любого инструмента, не только языка программирования, мы предусматриваем семь этапов.

  1. Знакомство с новым релизом инструмента или с новым продуктом. На этом этапе узнаём, что интересное появилось, читаем информацию о продукте, изучаем различия между версиями.
  2. Локальное тестирование инструмента. Один или несколько человек пробуют новую версию или продукт. Затем, через одну или две недели, они делятся впечатлениями. Обратная связь помогает решить, нужна миграция или нет.
  3. Начало миграции. На этом этапе инструмент тестируют разработчики. Некоторое время они изучают его все вместе, ищут проблемы и ошибки совместимости.
  4. Миграция тестовых сред. Когда становится понятно, что на этапе разработки с новым инструментом не возникает проблем, его устанавливают на тестовые среды. При этом всё еще обеспечиваем полную совместимость со старой версией. Например, не используем фичи, которые доступны только в новой версии.
  5. Обновляем боевые среды. Еще раз проверяем, что все старые проекты совместимы с новой версией инструмента или обновлены. Несколько недель ждем, чтобы найти какие-то редкие проблемы.
  6. Завершаем миграцию. Отключаем совместимость с предыдущей версией платформы и начинаем использользовать фичи новой версии.

Разные инструменты могут одновременно находиться на разных этапах. Мы не заменяем разом всё, а планируем будущие обновления плавно, по мере необходимости.

Например, сейчас миграция на Java 11 завершена, а переход на новую версию PostgreSQL в самом разгаре. После нее мы можем сразу запланировать новую. Так, в 2022 году мы начали миграцию на Java 17. Думаем, что сможем завершить ее к лету.

Для наших сотрудников переход с одного языка программирования на другой — привычная часть работы. Применение новых технологий дает разработчикам опыт, который помогает им расти внутри компании.

Другие статьи по теме

1 Декабря, 2022

Запуск за два дня: кейс первой цифровой карты UnionPay для рублевых расчетов

Обычно запуск цифровой карты занимает две недели. Рассказываем, как нам удалось сделать это за два дня

Читать

24 Ноября, 2022

Хочешь собрать транспортное решение? Спроси меня как

О том, как мы собрали транспортный сервис, который позволяет оплачивать проезд банковской картой.

Читать

25 Октября, 2022

Банковская разработка: футбол на лыжах

О том как мы строим аджайл и упрощаем жизнь команд не пытаясь бороться с требованиями.

Читать

11 Октября, 2022

Value Streams, MVP, прототипы: решения, которые помогают бизнесу и IT

С помощью каких инструментов удалось наладить взаимодействие между IT-направлением и бизнесом в команде сайта.

Читать

6 Октября, 2022

Платформа управления качеством данных на Open Source

Настроили контроль качества данных в разумные сроки, без огромного бюджета и перестройки всего ИТ-ландшафта.

Читать

5 Октября, 2022

Всё под контролем: как в Газпромбанке работают с клиентскими обращениями

Рассказываем, как банк автоматизирует работу с обращениями клиентов.

Читать