Обзор новой версии GigaIDE
Недавно вышел новый релиз GigaIDE, c момента прошлого релиза прошло значительное количество времени, а значит, команда создающая инструмент, скорее всего не сидела без дела, а неустанно штормила и реализовывала фичи. Завариваем чаю и пробуем. Тем более выход новой версии сопровождался новостями на различных медиа площадках и ребята обещают нам свой собственный маркетплейс.
Дисклеймер: Предлагаемая к прочтению статья получилась довльно громоздкой. Для нетерпеливых читателей и быстрого перемещения к интересующим разделам предлагается использовать оглавление:
Оглавление
Недавно мой коллега опубликовал отличную статью, в которой проверил IntelliJ IDEA Ultimate на прочность и удобство при разработке Spring-приложения — от идеи до продакшена. Сегодня мы попробуем повторить его путь, но уже используя GigaIDE. Ссылка на статью, сценарий которой мы будем брать за основу, прилагается: https://habr.com/ru/companies/haulmont/articles/952644/
На сайте нас встречает доступная для скачивания версия 2025.1 с пометкой New. Скачиваем, устанавливаем и приступаем к работе.
Среда успешно установлена, можно начинать знакомство. Открываем тестовый Java-проект Spring Petclinic в GigaIDE.
После краткой прогулки по проекту обнаружим, что поддержки Spring Framework из коробки не предоставлено. Однако, Giga Code активно помогает при работе с кодом и подсказывает в нужных местах.
Вообще, классно, что есть Giga Code. Было бы классно, если б�� он умел интегрироваться со сторонними инструментами через MCP. Однако, на данный момент такого функционала не обнаружено.
Про LLM, AI-агентов, MCP и удобные инструменты генерации можно прочитать вот в этой статье: https://habr.com/ru/companies/haulmont/articles/925088/
Это приятно, но вряд ли это все, что реализовано для поддержки Spring Framework в новом релизе. Значит, пора обратиться к маркетплейсу и изучить его содержимое. И действительно, поддержка фреймворка реализована в виде отдельных плагинов.
И действительно, поддержка фреймворка реализована в виде отдельных плагинов. Пробуем установить их — и испытываем лёгкое разочарование: установка требует наличия GigaIDE Pro, получение которой возможно только после отправки заявки.
Отправка заявки и её рассмотрение занимают время, а исследовать IDE хочется уже сейчас.
Маркетплейс OpenIDE и подготовка среды разработки
К счастью, у коллег из OpenIDE недавно вышла статья о том, как подключить в GigaIDE маркетплейс OpenIDE.
Ссылка на статью: https://habr.com/ru/articles/968808/
Это отличный повод воспользоваться представленной там инструкцией. В той же статье подробно рассмотрено и текущее наполнение маркетплейса GigaIDE. Чтобы не дублировать материал, оставим эту тему читателю для самостоятельного изучения.
Меняем адрес маркетплейса и выполняем перезапуск среды. После этого все необходимые плагины становятся доступны.
Устанавливаем из маркетплейса Docker Plugin, Amplicode, MapStruct Support, Lombok и Database Navigator. Эти инструменты сделают изучение проекта и внесение изменений простым и приятным мероприятием.
Работа с Docker и properties-файлами проекта
После установки необходимых плагинов и перезапуска IDE можно снова прогуляться по проекту. Теперь в распоряжении разработчика появился удобный инструментарий для создания сервисов, контроллеров, репозиториев, сущностей, конфигураций и любых иных элементов Spring-приложения.
Работу с Docker-файлами и docker-compose упрощают плагины Amplicode и Docker Plugin, а для написания HTTP-запросов к сервису доступен встроенный HTTP-клиент Amplicode — ConneKt.
У Docker-плагина есть отдельная панель, позволяющая удобно просматривать и запускать контейнеры и сервисы. Работа с контейнерами сегодня — это минимально необходимый навык для гибкой и удобной локальной разработки. Всё нужное всегда под рукой.
Ниже приведён пример того, как Amplicode помогает работать с docker-compose: инструмент автоматически генерирует содержимое файла в соответствии со структурой проекта и его потребностями при локальной разработке.
Если в проекте уже существуют сервисы или необходимо изменить имеющиеся параметры и настройки, необязательно генерировать файл заново — достаточно открыть Amplicode Inspector и внести изменения.
Работа с properties-файлами также проходит комфортно: при описании свойств появляются своевременные подсказки, а Amplicode Designer предлагает тонкие настройки.
Amplicode отлично справляется с типовыми задачами Spring-проекта. Ниже приводится пример того, как просто создать описание DataSource в application.properties — ведь работа с данными в большинстве Spring-приложений стоит на первом месте.
Работа с данными и объектным представлением
Раз уж речь зашла о работе с данными, логично разобраться, какие технологии используются в проекте и как именно происходит взаимодействие с базой. Здесь на помощь приходит Amplicode Explorer — инструмент, позволяющий «с высоты птичьего полёта» изучать структуру проекта, состав его компонентов и просматривать ключевые сущности без переключения контекста, благодаря удобным всплывающим окнам.
В проекте Spring Petclinic работа с данными реализована через Spring Data JPA. Хотя Amplicode одинаково удобно работает и с MongoDB, и с Spring Data JDBC, в рамках статьи подробнее рассмотрим именно JPA.
При формировании кодового представления структуры базы данных мы оперируем классами и аннотациями. Amplicode отлично справляется как с генерацией кода для таких случаев, так и с последующим его редактированием.
Начнём с создания сущности. В панели проекта, на нужном пакете, выбираем New → JPA Entity, указываем тип идентификатора — и на выходе получаем готовую сущность. Помощь оказывается на всех этапах: генерация сущности и идентификатора, добавление атрибутов, настройка связей, а также подсветка возможных ошибок и акцентирование внимания на важных деталях.
На самом деле, не важно, с чего вы начинаете. Можно сначала создать DTO — Amplicode поможет и в этом — а затем сгенерировать сущности на его основе. Подход API First сейчас используется довольно часто, и инструмент обеспечивает полноценную поддержку.
Более того, нередки ситуации, когда структура базы уже существует, а приложение создаётся или переписывается поверх неё. Многие команды придерживаются подхода Database First. Если вам требуется восстановить сущности по существующей схеме БД — Amplicode также предоставляет всё необходимое.
Версионирование БД
Когда структура данных в проекте описана, неизбежно возникает следующи�� этап — миграции.
В Spring Petclinic уже используется инструмент для версионирования — Flyway.
Amplicode помогает не только в описании изменений структуры данных, но и в автоматическом формировании миграций. Плагин сам распознаёт внесённые изменения, сравнивает текущее состояние с подключённой базой данных и генерирует корректный SQL.
Если инструмент версионирования ещё не подключён, Amplicode также поможет — подскажет, как добавить Flyway или Liquibase, настроить конфигурацию и затем работать с миграциями.
Для выполнения описанных операций необходимо открыть Amplicode Explorer, вызвать контекстное меню на элементе Configurations → Add Configuration → DB Migration Configuration. В появившемся окне нужно выбрать Flyway, указать место хранения скриптов, выбрать базу данных, с которой планируется работать, а затем одну из доступных опций, например Create init DB scripts.
Работа с репозиториями
Раз уж мы последовательно рассматриваем работу с данными, после описания структуры и настройки доступа к базе логично перейти к операциям над этими данными. В случае Spring Data JPA такую работу обеспечивают репозитории. Amplicode позволяет создавать их прямо из классов сущностей, без переключения контекста и лишних действий.
Spring Data JPA предоставляет довольно широкий API, однако иногда для реализации бизнес-логики требуются методы, которые не покрываются стандартными возможностями. И в таких случаях мы снова не остаёмся без помощи — нас выручает уже неоднократно упомянутый инструмент, имя которого легко угадать по первой букве: A — Amplicode.
Amplicode предоставляет полноценную поддержку для создания derived-методов. Достаточно открыть Amplicode Designer → Derived Method, выбрать нужный вариант, указать параметры и условия — и на выходе вы получите готовый метод. Такой подход избавляет от необходимости держать в голове тонкости построения имён методов и ускоряет работу.
В случае, когда вы находитесь вне репозитория, можно использовать генерацию derived-метода по имени и создать его не переходя в репозиторий. Amplicode предоставит для этого необходимый code-completion.
Derived-методы часто получаются длинными и громоздкими. Разработчики со стажем справедливо замечают: «Мы пишем подобные вещи через @Query, а названия делаем короткими и отражающими бизнес-смысл». Эта возможность также предусмотрена. Для уже созданного метода можно автоматически сгенерировать аннотацию @Query, а затем переименовать метод. Amplicode будет сопровождать работу с JPQL, подсказывать и предотвращать ошибки.
Кроме того, при необходимости можно сразу создать метод с @Query — достаточно выбрать соответствующий пункт в Amplicode Designer.
Созданный и дополненный репозиторий легко подключается в сервисах и других компонентах. Доступна удобная навигация между связанными объектами, а Amplicode Explorer и понятные иконки помогают не терять контекст и быстро перемещаться по проекту.
REST/MVC-эндпоинты и работа с DTO
Как уже отмечалось ранее, Amplicode работает «на одном языке» со Spring Framework и помогает создавать большинство инфраструктурных элементов — контроллеры, сервисы, компоненты. Теперь, когда у нас есть схема данных, сущности и репозитории, а инструмент для миграций настроен, логично перейти к REST/MVC-эндпоинтам.
Для генерации Rest/MVC-endpoint’ов и методов плагин предоставляет всеобъемлющее сопровождение. В Amplicode есть удобный инструмент для их генерации.
Если вам кажется скучным вручную создавать методы для CRUD-операций, Amplicode предлагает более быстрый путь — генерацию целого CRUD-контроллера.
Во время генерации плагин создаст всё необходимое: DTO, репозитории, сервисы и сам контроллер. В итоге на выходе получается готовый, рабочий набор классов.
При работе с DTO Amplicode предлагает несколько вариантов маппинга:
MapStruct
ModelMapper
генерация маппера вручную — в том стиле, в каком его обычно пишут разработчики
Сгенерированный маппер выглядит так же, как если бы вы написали его самостоятельно.
На практике DTO чаще всего создают на основе уже существующих объектов — сущностей или других DTO. Плагин прекрасно справляется с подобной задачей: удаляет ненужные поля, добавляет недостающие, корректно формирует структуру.
Работа с DTO часто воспринимается рутинной и утомительной. Казалось бы, генерация при помощи ИИ должна решать такие задачи, но даже ИИ приходится перечислять поля явно — что порой сложнее обычного ручного создания.
Amplicode предлагает несколько способов генерации DTO. Один из наиболее удобных — указать в коде несуществующий тип, затем использовать стандартное действие IDE для исправления ошибки и выбрать Create DTO… от Amplicode.
После этого открывается окно создания DTO. В качестве Domain entity можно указать созданную ранее сущность, а формат результата выбрать, например, Java Record. В нижней части окна отображается дерево атрибутов, позволяющее гибко выбирать поля, включая вложенные, и управлять их отображением.
Прежде чем продолжить далее, хотелось бы отметить, что Amplicode предлагает очень широкий диапазон возможностей. Обозреть их все невозможно в рамках одной даже очень большой статьи, так что в тексте приведены лишь некоторые из возможных сценариев. Ощутить всеобъемлющую поддержку проще всего, если самостоятельно попробовать использование плагина.
HTTP-клиент и ручное тестирование API
Когда API готово, первое, что хочется сделать — протестировать его вручную. Amplicode предоставляет для этого удобный инструмент — HTTP-клиент ConneKt.
Генерация HTTP-запросов доступна прямо из класса контроллера. Несколько кликов — и вы получаете готовый запрос, который можно сразу же отправить. Для генерации http-запроса для метода стоит нажать на иконку "бина" радом с ним и выбрать Generate Request in Connekt.
Также можно воспользоваться генерацией через секцию Endpoints на панели Amplicode Explorer подобно тому, как это сделано в примере ниже.
Если в работе с ConneKt возникают сложности, можно обратиться к примерам, которые предоставляет команда Amplicode. Эти примеры охватывают все основные возможности инструмента и помогают быстро разобраться с форматом запросов, параметрами и вариантами использования.
Сгенерированные HTTP-методы можно:
вызывать прямо из IDE,
добавлять проверки,
собирать полноценные тестовые сценарии,
выполнять операции с данными в рамках одного запроса или цепочки запросов.
В результате ConneKt оказывается не просто генератором запросов, а полноценным инструментом локального тестирования API.
Тестирование Web-слоя и Unit-тесты
Тестирование Web-слоя
Для тестирования Web-слоя доступна генерация Web-тестов.
Про сам процесс можно рассказывать долго, но лучше один раз попробовать.
Проще всего сгенерировать Spring Web Test прямо из контроллера или его метода:
Откройте контроллер.
Слева от названия класса нажмите на иконку бина.
В выпадающем списке выберите Generate Spring Web Tests….
В появившемся окне нажмите + (Create Web Test), укажите имя тестового класса и выберите Spring Application Context как контекст выполнения.
В списке методов контроллера отметьте нужные.
Если в проекте используется Spring Security, Amplicode корректно распознает конфигурацию и добавит всё необходимое для корректной работы теста.
Останется лишь поправить тело запросов и добавить проверки через Assert.
Unit-тесты и Mock
Для сервисов Amplicode позволяет создавать Unit-тесты с mock или spy. Необходимая библиотека (Mockito) будет автоматически добавлена в зависимости проекта.
Сгенерировать тесты можно прямиком из класса сервиса, подобно тому, как мы сделали это для контроллеров.
Генерация тестов из класса сервиса происходит так же просто, как и для контроллеров:
Вызываете генератор,
получаете готовый каркас тестового класса,
вносите необходимые правки.
В созданном классе уже будут подготовлены заготовки методов. Вам нужно:
описать поведение и ответы Mock-объектов, в чём Amplicode также помогает,
добавить вызов тестируемого метода,
указать проверки результата.
Даже такой рутинный набор действий сопровождается подсказками, что делает процесс заметно проще и быстрее.
Генерация OpenAPI-схемы
Для реализации описания API, составления документации проекта, а также для интеграции с другими приложениями часто требуется возможность составления OpenAPI-схемы. Amplicode включают удобные инструменты генерации OpenAPI-схемы на основе описания в RestController. На выходе можно выбрать формат (YAML/JSON) и область, для которой выполнить генерацию.
Как выполнить генерацию:
Откройте нужный контроллер.
Нажмите на иконку слева от имени класса.
Выберите действие Generate OpenAPI Schema.
В появившемся окне укажите формат, область и место сохранения.
После нажатия OK схема будет создана.
В рассматриваемом проекте это первая генерация, поэтому мы сохраняем результат в файл и публикуем его вместе с приложением.
Развертывание приложения в production-окружении
Сегодня Deployment-процесс все чаще отдан на откуп DevOps-инженерам, однако это не всегда так. Умение деплоить приложение в production всегда было важным навыком разработчика и по сей день остается таким. Еще 3–5 лет назад часто использовали серверы приложений или UberJar. Сейчас стандартом де-факто стал Kubernetes и работа с контейнерами. Kubernetes не единственный доступный вариант, но явно наиболее часто используемый и доминирующий.
Кластер Kubernetes можно получить разными способами. Для разработки и тестирования удобно использовать локальные решения — Minikube или Rancher. Production-кластер проще всего заказать у облачного провайдера — это значительно дешевле, чем разворачивать и поддерживать его своими силами (если, конечно, речь не о большой компании, где этим занимается отдельная команда). Облака сегодня в моде — одевайтесь по погоде! Amplicode и здесь не оставляет разработчика/DevOps-инженера одного и всячески сопутствует в процессе развертывания приложения. Об этом и поговорим далее.
Идеальный сценарий выглядит так:
подготовка конфигурации локально (быстрый фидбек при изменениях),
деплой приложения в Kubernetes выбранного облака без изменений,
при проблемах (цена, стабильность) производим перенос решения к другому провайдеру.
На практике всё редко бывает столь гладко, однако многие сложности смягчаются благодаря вспомогательным инструментам.
Существует множество решений, упрощающих работу с конфигурациями. Два самых популярных — Helm и Kustomize. Helm, помимо поддержки разных окружений (test, prod, разные облака), является пакетным менеджером. Это упрощает деплой приложения и всей необходимой инфраструктуры. В дальнейшем мы будем использовать именно Helm. Подготовка и последующее развертывание будут происходить в несколько этапов.
Подключение к Kubernetes-кластерам в IDE
Для тестирования конфигурации необходимо подключиться к Kubernetes-кластеру. Это можно сделать средствами самой IDE.
Как подключиться к кластеру представлено ниже:
После подключения кластер будет отображаться в панели Services.
Инфраструктура: PostgreSQL через Helm
В простейшем случае приложению нужна только база данных — PostgreSQL. Развернуть ее в Kubernetes можно с помощью Helm. Есть два варианта: развернуть как сервис или как оператор. Оператор имел бы смысл, когда вы строите собственное облако.
В репозитории Helm-чартов ArtifactHub доступно множество пакетов PostgreSQL. С одной стороны, это хорошо, с другой — возникает вопрос, на каком остановиться. В ArtifactHub нет метки «официальный», как на DockerHub, но указаны вендоры — Bitnami, Celtic и т.д. Долгое время чарт от Bitnami был выбором по умолчанию, но недавно они изменили политику распространения: теперь доступны только latest-версии. Сообщество ждет, кто займет их место, но для нас сейчас это не критично — используем Bitnami.
Работать PostgreSQL будем в собственном Helm-чарте. Для этого создадим пустой Helm Chart. Это делается в Amplicode Explorer в разделе Kubernetes или через через контекстное меню. Нажмем New…. и создадим пустой чарт. Amplicode позволяет сгенерировать пустой чарт, Spring Boot-чарт и т.д. Выбираем тип - Empty Helm Chart, имя — postgresql. Далее добавляем зависимость. Ниже приведен материал, который показывает, как это сделать:
Список прочих доступных для добавления зависимостей можно найти в панели Amplicode Designer:
После генерации видно, что зависимость добавлена точно так же, как если бы мы делали это вручную, а в values.yaml сразу появилась готовая конфигурация.
Осталось развернуть конфигурацию.
В Amplicode Explorer откройте контекстное меню для postgresql и выберите Run.
Укажите namespace (если его нет, он создастся автоматически).
Amplicode запустит Helm с нужными параметрами (Helm должен быть установлен). Проверить успешный запуск можно в панели Services — раздел Workloads.
Инфраструктура готова, можно переходить к деплою приложения.
Деплой Spring Boot приложения (Helm, Ingress)
Точно так же, как мы создавали Helm для PostgreSQL, можно создать Helm для нашего Spring Boot-приложения. Отличие лишь в том, что на втором шаге нужно выбрать Spring Boot Application вместо Empty Helm Chart. В открывшемся окне выбираем приложение, проверяем, что Amplicode корректно считал конфигурацию actuator для readiness/liveness-проб, а также порт приложения.
Здесь же можно разрешить внешний доступ к приложению — установите галочку Enable Ingress. Ingress требует DNS-имя и установленный в кластере Ingress-контроллер. Большинство провайдеров Kubernetes предустанавливают контроллер, интегрированный с их инфраструктурой. Локальные инсталляции часто включают Traefik или NGINX. Если контроллер отсутствует, его можно поставить из Helm Chart, как PostgreSQL.
Сгенерированный Helm Chart уже учитывает специфику Spring Boot-приложения, но его нужно доработать. В частности, в values.yaml отсутствуют параметры конфигурации DataSource. Чтобы добавить их, редактируем шаблон deployment.yaml.
Helm-шаблоны используют Go Template, убедитесь, что включен соответствующий плагин. Плагин JetBrains предоставляет автодополнение, навигацию и другие удобства. В настоящее время он не представлен ни в одном из описанных выше маркетплейсов. Скачать его можно с сайта JetBrains по приложенной выше ссылке.
Amplicode дополнять Helm-шаблоны и понимает специфику Spring Boot.
Переопределять свойства Spring Boot можно разными способами, самый популярный — через переменные окружения.
В deployment.yaml в секцию env добавляем переменные.
Среда разработки здесь не помогает, но Amplicode подсказывает доступные опции. Для name выбираем SPRING_DATASOURCE_URL. Значение берем напрямую из values.yaml, выбрав его через completion. После этого задаем базовое значение — Amplicode предложит быстрое исправление. Аналогично добавляем переменные для имени пользователя и пароля.
Запускаем конфигурацию так же, как раньше:
в Amplicode Explorer для Helm Chart вызываем действие Run,
указываем тот же namespace, куда был задеплоен PostgreSQL.
Если что-то пошло не так, в панели Services можно посмотреть логи приложения. Если приложение задеплоено, но не отвечает по имени, можно сделать port forwarding для ресурса — действие доступно в контекстном меню.
Пройдя довольно долгий путь мы обозрели и попробовали полный цикл от создания приложения до деплоя в production. И все это время нам помогал и подсказывал Amplicode.
Заключение
Безусловно, команды GigaIDE и GigaCode проделали большую работу для выпуска новой версии IDE и ассистента, который подсказывает необходимое во время разработки, однако и команда Amplicode приложила немало усилий для того, чтобы сделать разработку по настоящему полноценной и комфортной. Комбинирование данных инструментов разработки позволяет добиться невероятной эффективности и с легкостью и задором преодолеть весь перечень задач встречающихся на пути разработчика, имея обширную поддержку и богатый арсенал инструментов под рукой.
Актуальные новости о продукте проще всего получать, подписавшись на наш телеграм канал. Получить актуальную версию Amplicode можно на нашем сайте.
