Обзор новой версии 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 можно на нашем сайте.