Проект

Проект#

Директория на диске, хранящая файлы для сборки решения.

Структура проекта#

  • module1 - прикладной модуль.

  • module2 - прикладной модуль.

  • moduleN - прикладной модуль.

  • projectModule - проектный модуль.

  • project - метаинформация по сборке.

  • build - каталог, находящийся вне системы контроля версий и содержащий данные, специфичные для локальной сборки:

    • lib - локальные JAR-библиотеки для запуска сервера и утилит прикладной разработки.

    • config.yml - создаётся при необходимости локального переопределения конфигурации проекта.

  • build.sbt - декларация сборки для sbt.

  • project.yaml - конфигурация проекта, подробнее можно посмотреть тут.

Конфигурация проекта#

Конфигурация проекта описывает правила сборки прикладного решения и располагается по пути application/project.yaml

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

Внимание

После отладки исправления необходимо создать pull request в ветку разработки соответствующего модуля и дождаться нового релиза. Если решение требуется выпустить без ожидания релиза комплекта сборки, следует переключиться на режим сборки по исходному коду для всех дочерних модулей.

Источники модуля#

local#

Код модуля находится в системе контроля версий исходного проекта. Подключается по исходному коду.

git#

Код модуля находится в отдельном git репозитории. Подключается по исходному коду.

Совет

Для массовой синхронизации модулей используйте утилиту gsf-cli.

base#

Модуль выпускается в базовом комплекте сборки. Подключается в виде JAR-артефакта.

buildKit#

Модуль выпускается в прикладном комплекте сборки. Подключается в виде JAR-артефакта.

Пример конфигурации#

#Комплект сборки, куда будет происходить публикация прикладных модулей
buildKit:
  name: ru.bitec.app
  version: 1.0.1

#Комплект сборки на основе которого работает проект
#Базовый комплект сборки обычно содержит сервер приложений и базовые модули
baseBuildKit:
  name: ru.bitec.base
  version: 1.0.1

#Источник сервера приложений
#Используется утилитой gs3-cli для подготовки проекта к работе
applicationServer:
  source: "base://"

#Источник плагина для сборки
sbtPlugin:
  source: "base://"

modules:
  #Подключение модуля через jar артефакт из maven репозитория
  - gtkjpa:
      source: "base://"
  - gtk:
      source: "base://"
  - btk: 
      source: "base://"
  #Подключение модуля через исходный код из удаленного репозитория
  - bts:
      source: "git://{host}/bts.git"
      branch: main
      isPublish: true

Примечание

Подробнее ознакомится с конфигурацией можно тут

Конфигурация репозиториев#

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

По умолчанию настройка репозиториев берется из файла: application/project/repositories/default.yaml.

Пример настройки:

repositories:
  - name: maven-global
    url: "https://repo.global-system.ru/artifactory/libs-release"

publishRepository:
  name: app-global
  url: "https://repo.global-system.ru/artifactory/build-kit"
  #Запрашивать данные авторизации из менеджера учетных данных для данного репозитория
  isLoginRequired: true

Работа в изолированной сети#

Если нужно настроить проект на использование только локальных сетевых репозиториев, необходимо:

  1. Настроить глобальную конфигурацию репозиториев sbt - для этого необходимо добавить локальные репозитории в файл ~/.sbt/repositories.

    [repositories]
  maven-proxy: http://host/repository/maven/
  buildkit: http://host/repository/buildkit/

  2. Включить изоляцию репозиториев - это позволить обращаться только к локальным репозиториям, игнорирую репозитории вшитые в программный код. Для этого в файле проекта application/.sbtopts добавьте флаг -Dsbt.override.build.repos=true.

    Примечание

    Включение данного флага не перекрывает настройки авторизации.

Смотрите: Прокси репозитории

Интеграция в vcs#

Исходный код проекта может располагаться в произвольной системе контроля версий.
Модули могут находиться как в репозитории самого проекта, так и в удалённом репозитории. При инициализации проекта код из удалённых репозиториев добавляется в каталог основного проекта.

Совет

Модули из удалённого репозитория рекомендуется добавлять в файл .gitignore (или аналог) основного репозитория проекта.

Стратегии ветвления#

После инициализации проекта можно пользоваться стандартными средствами ветвления используемой vcs.

Предупреждение

При внесении изменений, нарушающих обратную совместимость схемы базы данных, рекомендуется:

  • Вносить такие изменения в основную ветку (master/main), чтобы минимизировать конфликты схемы БД между разработчиками.

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

Публикация решения#

Публикация решения происходит средствами CI, например jenkins.

Команда sbt для публикации решения в локальный каталог:

sbt publishSolution

Публикация комплекта сборки#

Публикация комплекта сборки происходит средствами CI.

Команда sbt для публикации решения в репозиторий:

sbt publish
Содержание