Перейти к основному содержанию
`Ctrl`+`K`

# Проект

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

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

- `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