Проект#

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

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

  • module1
    Прикладной модуль

  • module2

  • moduleN

  • projectModule
    Проектный модуль

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

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

    • lib
      Локальные jar библиотеки для запуска сервера, и утилиты прикладной разработки

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

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

  • project.yaml
    Конфигурация проекта

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

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

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

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

Внимание

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

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

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#

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

Совет

Модули из удаленного репозитория следует добавить в игнор лист репозитория проекта.

Бранч-стратегии#

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

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

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

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

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

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

sbt publishSolution

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

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

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

sbt publish