entaxy-esb

Подробная документация: описание системы.
Инструкция по установке: установка.

• connector - коннекторы к системам/шлюзам/прочему - пополняемая часть продукта
  • file-connector - (Бородина Валерия) модуль для работы с системами, которые работают через файловую систему(собирает сообщения в течение часа и собирает их в архив)
  • 1c-exchange-service - (Алексей Князев, Бородина Валерия) модуль обработки сообщений, универсальный сервис 1с
    • 1c-exchange-endpoint - выставленный универсальный soap-сервис 1с
    • 1c-exchange-service-endpoint - выставленный служебный soap-сервис 1с
    • connector - хранятся входящий и исходящий коннектор к 1c-exchange-endpoint и 1c-exchange-service-endpoint
    • support - маршруты, которые нужны для корректной работы коннектора
• features - там вообще должна быть одна фича, которая подтягивает фичи по отдельным компонентам. Установив ее мы и устанавливаем продукт в караф
• integrations - (Алексей Князев) рукотворные интеграции, сделанные без продукта
  • nsi - (Алексей Князев, Бородина Валерия) модуль обработки сообщений nsi
  • nsi-soap - (Алексей Князев) модуль с выставленным soap nsi
  • db-connector - (Алексей Князев) коннектор к промежуточной базе, преобразует xml в java объекты и потом через jpa сохраняет в бд, и также обратно
  • db-hyperjaxb3-naming-extension - (Алексей Князев) - плагин для плагина hyperjaxb3 который делает более человекочитаемые имена для генерируемых из xsd столбцов и таблиц
• storage - (Моисеев Михаил) все, что относится к хранению данных с общей точки зрения
• system - (Андрей Филиппов) собственно, продукт
  • auth - (Сергей Крючков, Моисеев Михаил) все, что относится к авторизации, включая бандлы для конкретных схем авторизации, общий интерсептор для CXF и т.д.
  • bridge - (Моисеев Михаил) мост между шинами с использованием брокеров
  • common - общие библиотеки
  • core - ядро системы, что там будет, пока сложно конкретизировать, но что-то наверняка будет
    • dispatcher -
    • events - (Моисеев Михаил) работа с топиками, наша реализация доставки сообщений
    • permission - (Моисеев Михаил) права доступа
    • template - (Бородина Валерия) работа с шаблонами для создания профилей, коннекторов и т д
    • error-handler - (Сергей Крючков) маршруты для обработки ошибок и вспомогательные классы.
  • deployer - (Бородина Валерия) все, что относится к процессу обработки данных из gui, их преобразования в blueprint и деплоя этого blueprint в шину
    • cellar-deployer - (Бородина Валерия) деплой blueprint в кластер карафа с помощью cellar
    • deployer-api - (Моисеев Михаил, Бородина Валерия) интерфейс deployer
    • nexus-deployer - (Бородина Валерия) деплой сгенерированных blueprint в nexus
    • file-system-deployer - (Моисеев Михаил) деплой сгенерированных blueprint в файловую систему
  • files - (Алексей Князев) сервис больших пакетов
  • registry - (Моисеев Михаил) реестры, определенные в продукте, должна содержать systems, system-groups, services для реализаций конкретных реестров
    • systems - описание внешней системы в нашей.
    • system-groups - группы систем, обобщённые по какому-либо признаку
    • profile-commons - может быть связан коннектором с точкой коммуникации.
    • processes -
    • service - это точка коммуникации. (что-то, развернутое под CXF)
    • connectors - нечто, что связывает профиль с точкой коммуникации
  • system-management - (Бородина Валерия) управление системами, профилями и коннекторами систем
  • transformer - видимо, друг deploer’а, реализация трансформаций данных gui -> blueprint
• test - тесты для postman, функциональность которая не пошла в дело

Правила работы с репозиторием

Коммиты в мастер глубоко нежелательны, но если нельзя поступить по-другому, предупредите коллег в общем чате с описанием причины.

Кратко:

Feature branching - любая разработка ведётся в отдельных ветках(бранчуемся от master/release) после чего делаем pull request.

Полно:

Ветки:

• master - develop ветка от неё бранчуемся, в неё сливаемся

• release- - стабильная релизная ветка от неё бранчуемся в случае hotfix-ов.
  Условия хранения релизной ветки:

  1. заказчик платит за поддержку
  2. не истек срок нашей поддержки этого релиза
  3. заказчик не произвел переход на новый релиз

• feature-branch - ветки разработок, хранится до проверки и слияния с целевой веткой
  Именование веток:

  • номером задачи из Jira
  • особо осмысленным кратким названием функционала

• hotfix-branch - ветки для hotfix-ов, хранится аналогично feature-branch
  Именование веток - префикс “hotfix-” далее:

  • номер задачи из Jira
  • особо осмысленное краткое название исправления

Pull request

• Для фиксов и мелких доработок назначаем в рецензенты: ведущего разработчика - Алексея Князева и ответственных за функционал/заинтересованных лиц ответственных и заинтересованных можно посмотреть в описании проекта выше.

• Для крупных доработок к описанным выше лицам добавляем Андрея Филиппова и Сергея Старовойтенкова

Если не планируется больше доработок в ветке направленной на мерж, при создании pull request-а помечаем Close branch