Описание

Суть проблемы

Редактирование неактуальных версий внешних отчетов и обработок.
Ручной процесс применения изменений сразу в несколько информационных баз.
Отсутствие контроля за процессом изменения внешних отчетов и обработок.

Цели

Хранение внешних обработок в одном месте для различных информационных баз.
Использование системы контроля версий.
Автоматизированная доставка изменений до информационных баз.

Связь с целями и стратегией

Однотипность процесса разработки, уменьшение затрат на разработку, разработка в любой среде, контроль качества кода.

Инструменты разработки

Разработка ведется в EDT не ниже 2020.4.0+425. Проект создан на основе bootstrap-1c;
Платформа 1С не ниже 8.3.16.1502;
Модульные тесты через 1CUnits - в расширении конфигурации EDT, см. ./GitlabServices.Tests;
Среда для разработки разворачивается с помощью docker-compose, а сам продукт поставляется в виде образов docker

Процесс разработки

Предполагается следующий цикл при работе над проектом:

Начинаем...

Pull проекта из удаленного репозитория;
Разворачивание среды;
Разработка в EDT в развернутой среде (база-данных, веб-сервис, утилиты);
Тестирование в развернутой среде;
Push изменений и PR (MR) в удаленный репозиторий;
Прогон автоматических тестов, сборка релиза и документации на сервере;

...повторяем.

Сборка проекта

Установка требуемого ПО

Например, для windows, можно воспользоваться менеджером пакетов chocolatey:

> tools\install-env.cmd

Клонирование проекта из удаленного репозитория

> git clone https://github.com/astrizhachuk/gitlab-services.git

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

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

ONEC_USERNAME - учётная запись на http://releases.1c.ru

ONEC_PASSWORD - пароль для учётной записи на http://releases.1c.ru

ONEC_VERSION - версия платформы 1С:Преприятия 8.3, для которой собирается проект

DOCKER_USERNAME - учетная запись на Docker Hub или в корпоративном registry

Настроить в проекте подключение к серверу лицензий в файле nethasp.ini

Операции с окружением

Разворачивание окружения с предварительной сборкой образов:

> docker-compose up -d --build

Запуск всех сервисов:

> docker-compose start

Запуск выборочных сервисов:

> docker-compose start srv db ws

Остановка всех сервисов:

> docker-compose stop

BPMN: изменение внешней обработки

Архитектура решения

Описание API тут или тут.
GitLab Enterprise Edition не ниже 11.4.0-ee.
На конечных точках (базах получателях) должен быть реализован API обновления внешний отчетов и обработок: см. тут или тут. Пример реализации сервиса для базы-приемника - gitlab-services-receiver

@startuml
GitLab -> "1C:Transmitter" ++ : webhook
"1C:Transmitter" -> "1C:Transmitter:BackgroundJobs" ** : start job
return 200
"1C:Transmitter:BackgroundJobs" -> "1C:Transmitter:BackgroundJobs" ++ : prepare
GitLab <- "1C:Transmitter:BackgroundJobs" ++ : request files
return 200
"1C:Transmitter:BackgroundJobs" -> "1C:Transmitter:BackgroundJobs" ++ : send file
"1C:Transmitter:BackgroundJobs" -> "1C:Receiver" : file
"1C:Transmitter:BackgroundJobs" <- "1C:Receiver" : status
return
return
@enduml

В основной ветке удаленного репозитория на GitLab осуществляется commit изменений.
На сервере GitLab срабатывает webhook в виде запроса по методу POST в HTTP-сервис (REST) веб-сервера 1С ИБ-распределителя.
HTTP-сервис 1С проводит аутентификацию и корректность тела запроса, который передается в формате JSON (application/json). Если аутентификация пройдена и данные корректны, то сразу возвращается HTTP-ответ с кодом 200, либо код ошибки и соединение с GitLab закрывается.
ИБ-распределителя в фоновом задании обрабатывает тело запроса одним пакетом, подготавливая данные для каждого commit внутри этого пакета:
- с сервера GitLab для каждого commit забирается своя версия файла настроек маршрутизации данных в ИБ-получатели (файл .ext-epf.json в корне репозитория);
- с сервера GitLab для каждого commit забирается своя версия бинарного файла с расширением .epf,.erf;
- данные сохраняются в ИБ-распределителе для возможности анализа и аварийной отправке данных в ИБ-получатели;
- подготавливаются данные для отправки согласно маршрутам доставки; каждый файл или действие асинхронно через Web-сервис отправляется в ИБ-получатель с получением ответа об успехе;
В ИБ-получателе производятся действия согласно правилам настроек маршрутизации.
Мониторинг ИБ-распределителя осуществляется либо через web-client, либо через тонкий клиент.

Включение и отключение функционала

Включить или отключить процесс обработки событий от GitLab и доставку внешних обработок в базы-получатели можно в ИБ-распределителе через "Сервисы GitLab" - "Сервис" - "Настройки сервисов GitLab" флажок "Включить загрузку файлов из внешнего хранилища".

Диагностика веб-сервисов

Проверить работоспособность веб-сервисов (отклик и ответ) можно в настройках сервисов (1):

Нажав "Проверить" можно увидеть как статус сервиса (доступен, недоступен, включен, выключен) (3), так и тело ответа (4):

Аутентификация и авторизация

На сервере Gitlab для каждого репозитория в Settings → Integrations устанавливается секретный ключа (Secret Token), который будет добавляться в заголовки POST запросов для аутентификации этих запросов на стороне HTTP-сервиса 1С. Данный ключ необходимо указать в качестве идентификатора в справочнике "Обработчики событий" в ИБ-распределителе. При срабатывании webhook в справочнике "Обработчики событий" осуществляется поиск элемента справочника с требуемым ключом (идентификатором) с последующей привязкой этого элемента к обрабатываемому webhook. Если таких элементов несколько, то будет выбран первый.
На сервере GitLab выбирается или добавляется новый пользователь, под которым будут забираться данные с репозитория (файлы настроек маршрутизации и бинарные файлы). На сервере данная настройка находится в персональных настройках пользователя в разделе User Settings → Access Tokens → Personal Access Tokens. Необходимо с установить дату до которой действует ключ и Scopes = api. На стороне 1C значение этого ключа прописывается в константу "GitLab user private token" ИБ-распределителя.
Для ИБ-распределителя создается два файла-публикации: один для HTTP-сервиса (с урезанным доступом для тонкого клиента), другой - для доступа к базе через web-client. В самой же информационной базе создается специальный пользователь с ролью HTTPСервисGitLab (пользователь с этой ролью указывается в .vrd файле публикации), остальным пользователям, которым дается право на мониторинг сервисов GitLab, назначается роль ПользовательGitLab (см. каталог проекта ../web).
Для всех информационных баз, в которые необходимо отправлять внешние обработки, выбирается или добавляется новый пользователь с ролью WSGitLab. Он должен быть одним и тем же для всех этих баз. Имя такого пользователя и его пароль указывается в настройках подключения к конечной точке в ИБ-распределителе.

//TODO ...

AlexPCRus/gitlab-services

ErrorLooks like something went wrong!

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Languages

Error
Looks like something went wrong!

Packages