Управление сборкой. Расширение для конфигурации СППР

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

Арт.: 1650163

2022-04-24_9-48-08.jpg
1650801837749.png
1650880866869.png
1650881945245.png
1650969964968.png
1650972531198.png
1650974232860.png
1650974518761.png
2022-05-01_21-48-26.jpg
2022-05-01_22-14-53.jpg
1651432581955.png
2022-05-01_23-29-22.jpg
2022-05-02_12-36-40.jpg
2022-05-01_22-51-52.jpg
1651483657429.png
1651483657429.png
1651509939458.png
1651510076214.png
1651510701288.png
1651515392346.png
1651515625900.png
merge_when_pipeline_succeeds_enable.png
1651604533091.png
1651609259428.png
1651609493107.png
1651772684668.jpg
1651777872172.png
1651778368151.png
1651778368151.png
1651778979191.png
1652121514072.png
1652122116809.png
1652122615103.png
1652123498677.png
1652124323415.png
1652124392803.png
1652125166019.png
1652125459237.png
capture-61 (1).gif
1652127827687.png
1652128167089.png
Тех.архитектура.png
capture-62.gif
1652203847240.png
1652204148767.png
1652207017153.png
1652207243912.png
1652207337977.png
1652207372517.png
1652207773255.png
1652207845013.png
image.png
1652212514951.png
1652213846936.png
2022-05-11_0-24-14.jpg
1652215516835.png
1652215640317.png
1652216130289.png
1652216023966.png
1652216533380.png
1652217137511.png
1652217317830.png
1652218397618.png
1652218722364.png
1652218885754.png
1652219216003.png
2022-05-11_23-43-55.jpg
2022-05-11_23-43-55.jpg
1652302595420.png
1652303132130.png
1652304314547.png
1652304435365.png
1652304498255.png
1652306052922.png
1652306853148.png
1652307163514.png
1652308046246.png
2022-05-12_2-39-34.jpg
1652309612109.png
RunningPipes1.gif
1652372914256.png
2022-05-12_20-31-21.jpg
2022-05-12_20-35-09.jpg
1652377078480.png
1652382000253.png
1652390023450.png
Онлайн-демо
2022-04-24_9-48-08.jpg
1650801837749.png
1650880866869.png
1650881945245.png
1650969964968.png
1650972531198.png
1650974232860.png
1650974518761.png
2022-05-01_21-48-26.jpg
2022-05-01_22-14-53.jpg
1651432581955.png
2022-05-01_23-29-22.jpg
2022-05-02_12-36-40.jpg
2022-05-01_22-51-52.jpg
1651483657429.png
1651483657429.png
1651509939458.png
1651510076214.png
1651510701288.png
1651515392346.png
1651515625900.png
merge_when_pipeline_succeeds_enable.png
1651604533091.png
1651609259428.png
1651609493107.png
1651772684668.jpg
1651777872172.png
1651778368151.png
1651778368151.png
1651778979191.png
1652121514072.png
1652122116809.png
1652122615103.png
1652123498677.png
1652124323415.png
1652124392803.png
1652125166019.png
1652125459237.png
capture-61 (1).gif
1652127827687.png
1652128167089.png
Тех.архитектура.png
capture-62.gif
1652203847240.png
1652204148767.png
1652207017153.png
1652207243912.png
1652207337977.png
1652207372517.png
1652207773255.png
1652207845013.png
image.png
1652212514951.png
1652213846936.png
2022-05-11_0-24-14.jpg
1652215516835.png
1652215640317.png
1652216130289.png
1652216023966.png
1652216533380.png
1652217137511.png
1652217317830.png
1652218397618.png
1652218722364.png
1652218885754.png
1652219216003.png
2022-05-11_23-43-55.jpg
2022-05-11_23-43-55.jpg
1652302595420.png
1652303132130.png
1652304314547.png
1652304435365.png
1652304498255.png
1652306052922.png
1652306853148.png
1652307163514.png
1652308046246.png
2022-05-12_2-39-34.jpg
1652309612109.png
RunningPipes1.gif
1652372914256.png
2022-05-12_20-31-21.jpg
2022-05-12_20-35-09.jpg
1652377078480.png
1652382000253.png
1652390023450.png
Лицензия

7000 руб.

3000 руб.

Подсистема позволяет:

  • Вести список информационных баз (ИБ) в нескольких кластерах и СУБД. Справочник "Информационные базы"
    • Для каждой ИБ допустимо указание имени пользователя и пароля, сохраняемые в настройках пользователя.
    • Информационные базы представлены в виде иерархического списка, где не первом уровне это исходные (эталонные) ИБ, а остальные уровни это клоны эталонных баз для тестирования функционала разрабатываемой системы.
    • Для каждой ИБ возможно исполнение различных командных файлов, из которых четыре предопределены (копирование из родителя, удаление, получение параметров и получения списка ИБ). Остальные могут добавляться по усмотрению. Командные файлы хранятся в виде шаблонов, для каждого шаблона предусмотрены алгоритмы подготовки (заполнения) переменных шаблона и алгоритмы обработки результата на встроенном языке.
    • Каждая информационная база может быть связана с некоторым объектом разработки:
      • Ветки версий, основная ветка проекта, ветка тестирования
      • Технические проекты
      • Ошибки
  • Вести справочник "Сборочных линий", представляющих собой динамически формируемый шаблон сборочной линии проекта, подключаемый в конвейере Gitlab одной строкой и не требующих модификации корневого файла проекта .gitlab-ci.yml. 
  • Поддерживать консистентность ветки версии, в которой содержится только проверенный код, и позволяющий выпустить релиз в любой момент согласно требованиям Разработка плановой версии п. 3.2 за счёт использования ветки тестирования
    • Автоматически формировать запросы на слияние в ветку тестирования ошибок, исправляемых в выделенных ветках, не имеющих связи с ИБ и отмеченных как "Исправлено". (Подробнее см. дополнение к справке в справочнике "Ошибки")
    • Автоматически формировать запросы на слияние в ветку версии подтверждённых ошибок
  • Максимально облегчить подготовку описания релиза. (в том виде, в котором это предусмотрено в БСП)
  • Автоматически создавать элементы в справочнике ветки, созданные в при помещении в гит из локального репозитория гит для технических проектов и исправляемых ошибок.
  • Создавать и принимать (их при отсутствии конфликтов) запросы на слияние в ветку тестирования при отметке исправления ошибок разработчиком как исправленные.
  • Создавать запросы на слияние в ветку версии при подтверждении исправления ошибок и при завершении технических проектов.
  • Уведомлять пользователей об окончании сборочного конвейера и функционале, включённом в него через систему взаимодействия, или при её недоступности или отсутствию по электронной почте. Электронная почта используется по умолчанию в качестве резервного канала уведомлений.
  • Уведомлять администраторов сборок обо всех событиях сборочного конвейера, не только об успешных.
  • Уведомлять разработчика о проблемах при принятии запроса на слияние его кода в ветку тестирования.
  • Уведомлять разработчика о создании ветки технического проекта или исправления ошибки в Git и привязывать созданную ветку к техпроекту или ошибке.
  • Загружать результаты тестирования VA из артефактов сборочной линии (доработка к загрузке результатов тестирования из CI)

Ограничения:

  • Предполагается, что имя базы в кластере и сервере СУБД совпадает.
  • Не допускается одновременная работа с двумя и более клонами Gitlab хранилищ, но допускается быстрое переключение между ними изменением настроек. Например, когда в публичное хранилище результаты работы могут выкладываться не сразу, а отладка некоторого функционала проводится в защищённом тестовом контуре, обособленным от публичного. В этом случае будут корректно обрабатываться входящие запросы через API, этого будет достаточно для обработки событий pipeline, push, merge-request, но чтобы заработала исходящая интеграция, необходимо в проекте указать новую строку подключения к хранилищу Git.
  • Не поддерживается интеграция по issue Gitlab
  • Если с сервера СППР доступа к СУБД нет, скорее всего использовать функционал не получится, либо будут ограничены операции с копированием эталонных баз. Для элемента справочника СУБД, к которым доступа с сервера СППР нет нужно включить флаг "Не опрашивать доступность СУБД"
  • Начиная  релиза 1.0.4.29 доступна функциональность подключения к тестовому контуру  и управления им по протоколу SSH, в том числе и через интернет. В этом случае достаточно организовать доступ всего по одному порту 22. См. описание изменений к релизу 1.0.4.29 в конце раздела.
  • Предопределённые и произвольные пакетные задания доступны только пользователю, имеющему "Полные права", либо "Администратору сборок" в будущем планируется снять это ограничение, разрешив разработчикам в некоторых случаях исполнять некоторые пакетные задания.

Детально возможности описаны в разделе "Подробное описание коммерческого продукта"

 
 Документация, повторяющая справку

 

Руководство пользователя
Расширение 1С:СППР: «Управление сборкой GLI».

Оглавление

Руководство пользователя Расширение 1С:СППР: «Управление сборкой GLI». 1

Назначение подсистемы 1

Подсистема позволяет: 1

Ограничения: 2

Порядок подключения и начала использования: 2

Объекты расширения 4

Справочник СУБД 4

Подчиненный справочник Размещения баз на СУБД 5

Справочник Кластеры 1С 5

Справочник Информационные базы 5

Справочник Сборочные линии 9

Справочник Типы СУБД 13

Подчиненный справочник Пакетные задания 14

Справочник Алгоритмы определения переменных 15

Отчет Подготовка описания версии по техпроектам и ошибкам 17

Расширение объектов основной конфигурации 19

Справочник Ошибки 19

Справочник Технические проекты 21

Справочник Ветки 22

Подчиненный справочник Сборки версии 22

Обработка Настройка уведомлений о сборках и подключение к GitLab API 23

Варианты и особенности сценариев учета исправления ошибок в СППР при использовании расширения «Управление сборкой GLI» 24

В ветке с типом «Ветка для исправления ошибок»: 25

В ветке версии: 27

В ветке технического проекта 28

Сценарии создания веток в Git и взаимосвязь веток Git с одноименным справочником «Ветки» в СППР. 28

Создание веток из СППР 28

Создание веток в СППР при первичном помещении ветки в удаленное хранилище 28

Назначение подсистемы

Подсистема предназначена для упрощения рутинных операций в части выпуска новых релизов системы и поддержки сборочных линий Gitlab CI/CD в актуальном состоянии. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Использует систему взаимодействия. Без системы взаимодействия функциональность будет сильно ограничена.

Подсистема позволяет:

  • Вести список информационных баз (ИБ) в нескольких кластерах и СУБД. Справочник "Информационные базы"

    • Для каждой ИБ допустимо указание имени пользователя и пароля, сохраняемые в настройках пользователя.

    • Информационные базы представлены в виде иерархического списка, где не первом уровне это исходные (эталонные) ИБ, а остальные уровни — это клоны эталонных баз для тестирования функционала разрабатываемой системы.

    • Для каждой ИБ возможно исполнение различных командных файлов, из которых четыре предопределены (копирование из родителя, удаление, получение параметров и получении списка ИБ). Остальные могут добавляться по усмотрению. Командные файлы хранятся в виде шаблонов, для каждого шаблона предусмотрены алгоритмы подготовки (заполнения) переменных шаблона и алгоритмы обработки результат на встроенном языке.

    • Каждая информационная база может быть связана с некоторым объектом разработки:

      • Ветки версий, основная ветка проекта

      • Технические проекты

      • Ошибки

  • Вести справочник "Сборочных линий", представляющих собой динамически формируемый шаблон сборочной линии проекта, подключаемый в конвейере Gitlab одной строкой и не требующих модификации корневого файла проекта .gitlab-ci.yml. Пример шаблона.

  • Поддерживать консистентность ветки версии, в которой содержится только проверенный код, и позволяющий выпустить релиз в любой момент согласно требованиям Разработка плановой версии п. 3.2 за счет использования ветки тестирования (подробнее Ещё/? Справка (GLI)*)

    • Автоматически формировать запросы на слияние в ветку тестирования ошибок, исправляемых в выделенных ветках, не имеющих связи с ИБ и отмеченных как "Исправлено". (Подробнее см. дополнение к справке по справочнику "Ошибки")

    • Автоматически формировать запросы на слияние в ветку версии подтвержденных ошибок

  • Максимально автоматически подготавливать описание релиза.

  • Автоматически создавать элементы в справочнике ветки, созданные при помещении в гит из локального репозитория гит для технических проектов и исправляемых ошибок. (Частично требуется СВ, в случаях, когда пользователь начал редактировать объект и в этот момент разработчики поместил новую ветку в удаленное хранилище) (Подробнее см. дополнение к справке в справочнике "Ошибки")

  • Уведомлять пользователей об окончании сборочного конвейера и функционале, включенном в него через систему взаимодействия. (Требуется СВ)

  • Уведомлять администраторов сборок обо всех событиях сборочного конвейера, не только об успешных. (Требуется СВ)

  • Уведомлять разработчика о проблемах при принятии запроса на слияние его кода в ветку тестирования (Требуется СВ)

Ограничения:

  • Предполагается, что имя базы в кластере и сервере СУБД совпадает.

  • Не допускается одновременная работа с двумя и более клонами Gitlab хранилищ, но допускается быстрое переключение между ними изменением настроек. Например, когда в публичное хранилище результаты работы могут выкладываться не сразу, а отладка некоторого функционала проводится в защищённом тестовом контуре, обособленным от публичного. В этом случае будут корректно обрабатываться входящие запросы через API, этого будет достаточно для обработки событий pipeline, push, merge-request, но, чтобы, заработала исходящая интеграция, необходимо в проекте указать новую строку подключения к хранилищу Git.

  • Не поддерживается интеграция по issue Gitlab

  • Если с сервера СППР доступа к СУБД нет, скорее всего использовать функционал не получится, либо будут ограничены операции с копированием эталонных баз. Для элемента справочника СУБД, к которым доступа с сервера СППР нет нужно включить флаг "Не опрашивать доступность СУБДПодробнее здесь.

  • Предопределенные и произвольные пакетные задания доступны только пользователю, имеющему "Полные права", либо "Администратору сборок" в будущем планируется снять это ограничение, разрешив разработчикам в некоторых случаях исполнять некоторые пакетные задания.

Порядок подключения и начала использования:

Подключение и настройка

  • Для подключения необходимо инициализировать систему взаимодействия 1С в ИБ СППР, если она ещё не используется, инструкции по активированию 1С:Система взаимодействия

  • Опубликовать, обособленно от основной публикации ИБ СППР, на веб сервере http сервисы расширения BS и GetPipeline. Подробнее здесь. 

  • Настроить gitlab-runners для этапов сборки и обновления ИБ. У gitlab-runners не должно быть ограничений по доступу к серверу СУБД и кластерам 1С, включая и прилегающий к тестовому продуктивному контуру. В противном случае, возможность сборки ИБ ветки версии с одновременным обновлением тестовых данных из продуктивного контура будет невозможна.

  • Настроить веб хуки. Подробнее здесь.

  • Предоставить службе сервера СППР доступ в тестовый контур: открыть порты СУБД, 1С, организовать постоянное сетевое подключение к тестовому контуру сервера, на котором работает СППР. 

  • Создать в Gitlab пользователя СППР, добавить его в проект как maintainer. Сгенерировать для пользователя приватный ключ и указать идентификатор проекта и приватный ключ в настройках, там же создать служебного пользователя в СППР, о лица которого будет работать интеграция и рассылаться уведомления в СВ.
    https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! При создании пользователя – бота профиль «HTTP Сервис» создаётся автоматически, в нём используются две роли: Типовая «Запуск внешнего соединения» и роль расширения «Чтение интеграция Gitlab». Роль расширения использует вид доступа «Проекты», по умолчанию в созданном профиле сервису доступны все проекты, даже если ограничение доступа на уровне записей выключено. Если Вам нужно ограничить доступ к каким-либо проектам, установите настройки профиля и скорректируйте группу доступа, в которую будет включен бот, соответствующим образом. Роль «Чтение интеграция GitLab» необходима потому, что несмотря на то, что код HTTP сервисf, отдающий тест сборочной линии исполняется в привилегированном режиме, определение переменных производится исполнением кода в безопасном режиме, для этого роль содержит с учётом RLS права на чтение всех справочников расширения, а так же справочников технические проекты, ошибки, ветки, версии проектов, сборки версий, пользователи. Этих доступов достаточно для работы сборочной линии в демонстрационной базе. Если вы в алгоритмах определения переменных задумаете использовать ещё какие-то другие справочники то соответствующие роли, разрешающие доступ на чтение нужно будет добавить в профиль «HTTP Сервис».

  • Описать тестовые контур и прилегающие к нему элементы продуктивного в справочниках "СУБД" и "Кластеры"

Инициализация разработки первой версии системы

  • Создать первую версию в справочнике «Версии проекта» связать её с веткой версии

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

  • Добавить эталонные базы в кластер(ы) и на СУБД тестового контура, зарегистрировать соответствующие корневые элементы в справочнике "Информационные базы", связать из с объектом сборки основной ветки разработки. Обеспечить средствами СУБД сохранность ИБ в режиме FULL.

  • Создать ветку(и) тестирования для ветки версии проекта. Подробнее см. описание справочника "Ветки" и справочника "Ошибки"

  • Создать подчиненные ИБ для ветки версии от эталонных баз, и привязать эти ИБ к веткам версии, заполнить пользователей, получателей уведомления в ветке версии. К каждому объекту тестирования может быть прикреплено различное, необходимое количество собираемых ИБ, имеющие разную наполняемость тестовыми данными.

  • Создать подчиненные ИБ от веток версии ИБ ветки тестирования и связать их с ветками тестирования.

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

  • Система готова к работе.

Описание процесса работы с подсистемой

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

  • Реализация доработок системы с использованием справочника «Технические проекты» на основании ЧТЗ** в справочнике «Идеи» в СППР

  • Исправление ошибок в системе, обнаруженных в разных тестовых базах, преимущественно в основной эталонной базе моделирования.

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

Помимо двух основных процессов существуют процессы:

  • Инициализации разработки первой версии системы (описано выше)

  • Обновление системы новым функционалом от поставщика, встраивание и обновление библиотек

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

    • Создать новую версию в справочнике «Версии проекта» и добавить ветку версии для новой версии и ветку тестирования

    • Создать копии эталонных баз для ветки версии и ветки тестирования, отключить автоматическое копирование в справочнике «Информационные базы»

    • При необходимости добавить этапы для ветки версии и ветки тестирования в сборочном конвейере

    • Новые, не критичные ошибки (критичными признают ошибки, блокирующие работу пользователей, и не имеющие способов обхода проблемы) найденные в текущей версии откладывать до получения новой версии

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

    • Провести обновление и протестировать изменения в ветке новой версии

    • Заморозить регистрацию и исправление ошибок, а также разработку функционала

    • Перенести исправления критичных ошибок в новую версию кумулятивно из ветки текущей версии

    • Протестировать работоспособность критичных исправлений в ветке новой версии

    • Слить новую версию в основную ветку проекта

  • Сборка очередного релиза системы

    • Провести ревизию подтвержденных исправлений и технических проектов, подлежащих закрытию(задачи которых либо выполнены, либо отменены).

    • Принять запросы на слияние в ветку версии, устранить конфликты при необходимости

    • Сформировать отчет по подтвержденным исправлениям и новому функционалу, встроить его в описание подсистемы и зафиксировать изменения веткой с маркером RDef в наименовании, слить ветку RDef в ветку версии и собрать новый релиз в ветке версии

    • Слить ветку версии в основную ветку проекта, добавить тег в Gitlab и ссылки артефакты сборки CF/CFU нового релиза из конвейера вставить во вложения нового релиза

* Аналогичные пункты присутствуют в адаптированных формах элементов справочников:

  • Ветки (Форма списка и элемента)

  • Сборки версии (Форма элемента)

  • Технические проекты (Форма элемента)

  • Ошибки (Форма списка и элемента)

** Частное техническое задание

Объекты расширения

Справочник СУБД

Предназначен для описания СУБД, используемых при сборке информационных баз.

Имя сервера СУБД: наименование, по которому идентифицируется именно этот сервер СУБД в скриптах, например в sqlcmd для сервера типа MS-SQL.

Тип СУБД: элемент справочника "Типы СУБД" описывающего основные и дополнительные алгоритмы для работы с выбранным типом сервера СУБД

Имя пользователя, Пароль: логин и пароль супервизора на сервере, либо логин и пароль, допускающий основные действия: создание/удаление, архивирование/восстановление, получение информации об информационных базах на указанном в имени сервера.

Кодировка вывода: в подсистеме используется обращение к утилитам командной строки для выполнения манипуляций с ИБ, для правильной интерпретации результатов с кириллицей нужно указать в каком формате командная строка возвращает текстовый вывод. Например, sqlcmd, запускаемый в Windows из командного процессора CMD использует кодировку DOS OEM 866.

Локальный каталог для создания архивов: может использоваться в скриптах для получения каталога по умолчанию.

Путь к переменной: Параметры.ИБ.СУБД.ЛокальныйКаталогДляАрхивов

Общий каталог на сетевом ресурсе для архивов: может быть полезен если используются разные СУБД для продуктивного и тестового контуров, и между ними требуется делать перемещение копий ИБ. Все сервера СУБД должны иметь возможность создавать и восстанавливать архивы с этого ресурса.
Путь к переменной: Параметры.ИБ.СУБД.ОбщийКаталогНаСетевомРесурсеДляАрхивов

Не опрашивать доступность СУБД: используется в тех случаях, когда некоторые СУБД не доступны серверу СППР, но к которым есть доступ с бегунов (runners) GitLab. В этом случае с списке информационных баз такие ИБ будут отмечены как недоступные.

Подчиненный справочник Размещения баз на СУБД

Подчиненный справочнику СУБД, определяющий физическое расположение внутри сервера для хранения файлов данных и журналов транзакций
Полное имя каталога нужно указывать обязательно с закрывающим слешем "\" или "/" для путей в формате Linux.

Примеры: заполнения:
W:\SQLData\

/var/lib/pgpro/1c-11/data/base/

Справочник Кластеры 1С

Справочник предназначен для хранения информации о кластерах 1С, на которых размещаются информационные базы.

Имя кластера необходимо вводить в либо формате FDQN, либо в кратком формате, указывая только имя сервера, при необходимости дополняя его номером порта, если кластер размещён не нас стандартном порту.

Примеры корректных наименований:

1. MyServer.MyDomain.MyZone (FDQN)

2. MyServer сокращенное, только имя сервера

3. MyServer:1641 - имя с указанием порта

Релиз: Используемая версия в кластере – справочное значение, во встроенных алгоритмах не используется, может использоваться в алгоритмах определения переменных.

Имя администратора: Имя администратора кластера

Пароль администратора: Пароль администратора кластера

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

Доступные функции в алгоритмах подготовки переменных и разбора результата справочника "Пакетные задания":
GLI_АдминистрированиеКластера.ПустойСписокСеансов(ИБ), возвращает Истина, если нет сеансов с ИБ.

GLI_АдминистрированиеКластера.СоздатьИБВКластере(ИБ), создаёт базу в кластере, если она не создана. Для создания ИБ используются наименования из переданного элемента справочника "Информационные базы". Возвращает Истина - удачно, или не требуется создание, Ложь - если создание закончилось неудачей. Причины неудачи сообщаются в сообщении. База создаётся с расчетом, что на сервере СУБД уже присутствует одноименная ИБ. Если на сервере СУБД база не существует, будет выдано сообщение об ошибке.

GLI_АдминистрированиеКластера.УдалитьИБВКластере(ИБ), удаляет базу в кластере, возвращает Истина, если удаление прошло успешно, Ложь, если удалить базу не получилось. База из кластера удаляется без удаления с сервера СУБД.

GLI_АдминистрированиеКластера.ПолучитьБазуВКластере(ИБ), возвращает объект АдминистрированиеИнформационнаяБаза либо Неопределено при ошибке

GLI_АдминистрированиеКластера.ПолучитьКластер(ИБ), возвращает объект АдминистрированиеКластер либо Неопределено при ошибке

Параметр ИБ - ссылка на элемент справочника "Информационные базы"

Сервер RAS: имя сервера администрирования

Порт RAS: номер порта сервера администрирования

Справочник Информационные базы

Информационные базы, механизм, позволяющий хранить информацию о собираемых и/или тестируемых базах в контуре CI. 

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

Каждая информационная база (ИБ) привязывается к своему объекту сборки:

  • Технический проект

  • Ошибка

  • Общая ветка тестирования ветки версии

  • Ветка версии

  • Ветка проекта

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


Одной из важных особенностью списка информационных баз является возможность отслеживать доступность информационных баз, для этого необходимо настроить для СУБД (см. Справочник "Типы СУБД") скрипт получения списка информационных баз с сервера. 

Пример скрипта для MS SQL: sqlcmd -S ~!ServerName -U ~!UserName -P ~!Password -h -1 -b -Q "SELECT name FROM master.dbo.sysdatabases", где ServerName, UserName, Password - переменные. описанные в справочнике "Алгориты определения переменных":

ServerName Параметры.ИБ.СУБД.Наименование
UserName Параметры.ИБ.СУБД.ИмяПользователя
Password Параметры.ИБ.СУБД.Пароль

Результат такого запроса является простой список ИБ на сервере СУБД. Полученные имена ИБ сопоставляются с реквизитом "Полное имя" элементов справочника ИБ.

При выводе дерева информационные базы, которые физически присутствуют на сервере СУБД маркируются полем "Доступность", для недоступных (тех базах, которые присутствуют в справочнике, но отсутствуют в СУБД) Доступность будет равно Ложь.

Состав реквизитов корневого элемента и подчинённых элементов немного отличается, но в целом одинаков:

Наименование реквизита Назначение для корневого элемента Назначение для подчиненного элемента Примечание
Основное      
Наследуемая ИБ - ИБ, с которой была получена копия В некоторых случаях можно "Скопировать [базу] из родителя", затем переподчинить её другой. Вручную реквизит не редактируется, используется штатный перенос drag & drop.
Настройка сборки      
Основной объект сборки Ссылка на элемент справочника Ветки с типом "Основная ветка проекта" или "Ветка версии"  Для первого уровня: ссылка на ветку версии
Для второго уровня: ссылка на технический проект, ошибку, или общую ветку тестирования.
Общая ветка тестирования - специальный механизм, вместе с привязанной к ней ИБ для тестирования позволяет в удобной форме поддерживать сценарии тестирования и исправления ошибок, подробнее см. Справочник "Ветки"
Замещается при сборке - Перед сборкой информационной базы, база будет скопирована из родительской

Удобно, когда родительская база содержит тестовые примеры с ошибками, например копия продуктивной базы или это база прототипа (моделирования), в этом случае ошибочная ситуация, присутствующая в родительской базе после сборки базы исправления ошибки, которая подчинена родительской, должна отсутствовать. При этом после сборки базы будут содержать идентичные тестовые данные.

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно - не следует в таких "Замещаемых" базах создавать и хранить какие-то контрольные примеры, так как они будут уничтожены при очередной сборке.

Не собирать При наступлении события сборки (фиксации изменений в ветку, или по расписанию) ИБ не будет обновлена изменениями в связанной с объектом сборки веткой Git.  Удобно для долгоживущих стендов, например для баз тестирования интеграции. По окончании разработки можно наполнить ИБ тестовыми примерами, и дать коллегам с нею работать, при этом ИБ гарантированно не будет изменена. При необходимости можно в любой момент подключиться к такой ИБ в отладке, например, чтобы расследовать проблемные ситуации.  
Табличная часть "Дополнительные объекты сборки"      
Табличная часть предназначена для хранения ссылок на объекты сборки полученные в связанной с объектом сборки ветке через запросы на слияние. Механизм в основном предназначен для отображения баз в объектах сборки (техпроекты и исправления ошибок), в которых можно посмотреть разрабатываемый функционал или исправление ошибки. Доступно по навигационной ссылке "Информационные базы" у объектов сборки.      
Формирование наименования ИБ      
Полное наименование Заполняется вручную, содержит имя эталонной ИБ. Формируется автоматически, из имени или псевдонима корневой базы . имя ветки объекта сборки . произвольный суффикс  Должно быть таким же, как и на сервере СУБД, если изменить имя только в справочнике, база станет не доступной (см. описание механизма выше)
Псевдоним для клонов Заполняется вручную - Используется для автоматического формирования наименования ИБ. 
Например, если корневая база имеет Полное имя "MainDB"  не имеет псевдонима, а объект сборки привязан к ветке 
"TP/00-00000077", и суффикс не заполнен то автоматическое имя подчиненной будет "MainDB.TP.00-00000077"
Наименование корневой ИБ - Не изменяется, определяется по цепочке родительских ИБ. Заполняется псевдонимом для клонов (см. ниже) при его отсутствии Полным именем корневой ИБ.
Ветка (на форме заголовок скрыт) - Заполняется автоматически ссылкой на ветку при выборе объекта сборки, связанного с веткой разработки, исправления ошибки, либо непосредственно к ветке версии. Для корневого элемента поле скрыто.
Суффикс имени - Заполняется вручную, требуется, если к одному объекту сборки необходимо две или более тестовых ИБ. Например "MainDB.TP.00-00000077.ThisYear" и "MainDB.TP.00-00000077.LastYear"
Настройки ИБ - секция скрыта по умолчанию для подчиненных ИБ, видимость можно включить параметром ниже      
Индивидуальные параметры ИБ - Включает видимость секции Настройки ИБ для подчиненной базы При создании подчинённой ИБ поля ниже копируются из родительской базы.
Пользователь Определяет имя пользователя ИБ в кластере 1С, этот пользователь должен обладать административными привилегиями     
Пароль Пароль пользователя ИБ в кластере    
Кластер Элемент справочника "Кластеры 1С", в котором хранятся параметры кластера 1С, в котором размещена ИБ.    
СУБД Элемент справочника "СУБД", в котором хранятся настройки доступа и параметры СУБД, в которой будет храниться ИБ    
Каталог СУБД Элемент справочника "Размещения баз на СУБД", подчинён справочнику "СУБД". Содержит ссылку на каталог сервера СУБД, где будут физически храниться файлы ИБ    
Табличная часть "Дополнительные переменные"      
Переменная Служит для обозначения имени переменных, используемых в скриптах конвейера и пакетных файлах Можно задавать любые идентификаторы, по правилу регулярных выражений [A-Za-zА-Яа-я0-9_]+  
Алгоритм получения Выражение на встроенном языке 1С, выполняется в безопасном режиме. В контексте выражения Структура Параметры, имеющая три поля: ИБ - ссылка на текущий элемент справочника "Информационные базы", Этап - имя текущего этапа (Stage) конвейера строкой, СборочнаяЛиния - ссылка на элемент справочника "Сборочные линии", результат выражения может быть строкой, либо типом, допускающим неявное преобразование в строку.  
Кнопка "Заполнить дополнительные переменные" Запускает алгоритм скрипт, указанный на закладке "Информация об ИБ" справочника "Типы СУБД" скрипт, например sqlcmd -S ~!ServerName -U ~!UserName -P ~!Password -u -s "~!Delimiters" -h -1 -d ~!DBName -b -Q "SELECT type,name,physical_name FROM sys.database_files" должен возвращать текст, далее текст передаётся в алгоритм разбора на встроенном языке 1С, который обрабатывает полученный текст и извлекает из него необходимые дополнительные переменные информационной базы, например для ИБ MS-SQL важными дополнительными характеристиками являются логические имена файлов данных и лога транзакций, а так же физический путь хранения данных файла с данными и журнала транзакций. Эти параметры необходимы для корректного автоматизированного копирования ИБ, например для функции "Скопировать из родителя"    

Перед копированием ИБ функцией "Скопировать из родителя" можно поменять у приёмной базы: Кластер, СУБД, Каталог СУБД. В этом случае база будет скопирована и размещена на другой СУБД и в другом кластере. Это удобно, когда проект ИБ находятся в разных контурах проекта (Продуктивный, Тестовый контур, Контур разработки).

При ручном переносе информационной базы в другое месторасположение, необходимо вручную указать конечный кластер 1С и СУБД, далее заполнить дополнительные переменные, каталог СУБД будет скорректирован автоматически.

Для толстого клиента УФ в форме списка (дерева) дополнительно отображаются оперативные параметры ИБ в кластере: 

  • Установлена и действует (по дате окончания)/не установлена блокировка базы

  • Установлена или не установлена блокировка регламентных заданий

  • Количество сеансов

  • Количество активных сеансов

Для определения параметров используются настройки сервера RAS для кластера. 

Кнопка - команда "Установить пользователя и пароль" позволяет установить выбранные имя пользователя и пароль для отмеченных в списке информационных баз, в дальнейшем эти параметры будут использоваться при запуске информационной базы из СППР.

Кнопка - команда "Открыть ИБ" запускает текущую ИБ в пользовательском режиме (ENTERPRISE)

Флаг отбора "Только активные, либо неопределяемые" включает фильтр, при котором отображаются только доступные базы. Скрываются те, которые физически отсутствуют на сервере СУБД, если это возможно определить: флаг "Не определять доступность" у СУБД выключен.

Штатная команда пометки на удаление отключена, вместо неё открывается диалог, в котором нужно указать - следует ли удалять также базу с сервера СУБД и из кластера.

Справочник Сборочные линии

Справочник предназначен для хранения и динамического формирования файла конвейера сборки в формате yml.

Для работы со справочником должен быть опубликован HTTP сервис GetPipeLine. 

Gitlab при наступлении определенных событий, таких как push, merge-request получает файл конвейера с HTTP сервиса.

Файл конвейера формируется системой СППР на основании данных о доступности информационных баз, необходимости их сборки и формирует

текст сборочной линии динамически.

К сожалению,  Gitlab не поддерживает передачу каких либо переменных в секцию include, например имени текущей ветки, поэтому текст сборочной линии генерируется сразу для всех веток, требующих сборки (по данным СППР с учетом доступности ИБ на сервере СУБД), а Gitlab CI выбирает из него подходящие для текущей ветки задания.

Для этого необходимо в ключевой файл .gitlab-ci.yml разместить строку вида:

include: 

    - 'http://gitlab.test.ru/sppr/hs/GetPipeline/CI_YML_TEST/ci-module.yml' 

где CI_YML_TEST -  Имя сборочной линии, sppr/hs корневой каталог HTTP сервисов, опубликованный из ИБ СППР. Если сама СППР опубликована на веб сервере для работы в браузере, то http сервисы рекомендуется публиковать отдельно, с другим способом авторизации, например в IIS для олицетворения может быт использована отдельная УЗ Windows связанная с УЗ пользователя - бота GitLab в СППР.

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! В случае, если по ссылке Вы получаете сообщение:

500 - Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed.

Попробуйте получить текст сборочной линии нажав на кнопку "Получить текст сборочной линии" из формы списка или в форме элемента. Если получите текст, и не получите ошибок, значит проблема в публикации на веб сервере, или проблема самого веб-сервера, чтобы окончательно убедиться в этом рекомендуется проверить, работают ли веб-хуки отправляемые из Gitlab в СППР. (подробнее про настройку и проверку веб хуков смотрите здесь).

Если по ссылке текст корректно получается, но Gitlab CI/CD при запуске сборки вручную в разделе сборочные линии пишет ошибку синтаксиса:

Pipeline cannot be run.

Included file `http://gitlab.test.ru/sppr/hs/GetPipeline/CI_YML_TEST/ci-module.yml` does not have valid YAML syntax!

Необходимо скопировать полученный по кнопке "Получить текст сборочной линии" в валидатор CI Iint:  CI/CD/Pipelines/CI lint.

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

На закладке "Состав этапов" определяются этапы сборки (stages). Для каждого этапа генерируется своя закладка, на которой размещаются постоянная часть, в ней, например, можно разместить шаблон задания и повторяемые части, которые используют шаблон задания либо полностью текст задания без использования шаблона.

На первом этапе обязательно должны присутствовать строки:

stages:

    - ~!Stages

определяющие состав этапов сборочного конвеера, список на закладке этапов будет подставлен вместо этого шаблона, например, если есть список этапов:

StagesAndVariables
Lock
Copy
GetCF
Fetching
Convertation
Build
TestQQ
Update
Unlock
OnFailureUnlock

?
И этап StagesAndVariables содержит

stages:

    - ~!Stages

То в сгенерированный текст конвейера будут включены строки:

# шаблон этапа StagesAndVariables

stages:

    - StagesAndVariables

    - Lock

    - Copy

    - GetCF

    - Fetching

    - Convertation

    - Build

    - TestQQ

    - Update

    - Unlock

    - OnFailureUnlock

Для имени этапа определен литерал [\w\d_]+, т.е. символы латинского алфавита заглавные или прописные, числа и символ подчеркивания.

Порядок этапов можно изменять стрелками  и 

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! Не создавайте одинаковых имён этапов разными регистрами символов латинского алфавита, например BUILD и Build. Уникальность имен этапов на уровне 1С поддерживается регистронезависимой.

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

В постоянной части этапа рекомендуется размещать шаблон задания, представлящий неизменную часть задания, например основные правила и скрипт, например, шаблон для этапа конвертации текстов EDT-->1С:

# Преобразование в формат 1С

.job_template: &~!Stage_job

    tags: 

        - convertation

    variables:

        GIT_STRATEGY: none

    script:

        - chcp 65001

        - start "" /wait "%W_PLATFORM_1C%" DESIGNER /S %%  /N %USER_1C% /P %PASS_1C%  /UC UpdateDB /DisableStartupMessages /DisableStartupDialogs /DisableSplash /UpdateCfg %CI_PROJECT_DIR%\%UpdFile% /UpdateDBcfg -Dynamic- /Out %CI_PROJECT_DIR%\logs\%LOG_NAME%

Повторяемых частей, по умолчанию, есть всегда одна, маркированная * - эта часть будет подставляться для всех веток Git, для которых требуется сборка, для некоторых веток, параметры задания могут отличаться, например испольхзоваться другой скрипт или другой состав переменных, или другие условия. В этом случае можно на закладке "Добавить" выбрать требуемый объект сборки, например ветку версии и появится возможность для неё описать индивидуальное задание. 

Например, в секции этапа * можно разместить:

ConvertEDT_XML_~!JobSuffix: 

    <<: *~!stage_job

    stage: ~!Stage

    dependencies: []

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

А для основной ветки проекта ветки добавить в конец условие:

ConvertEDT_XML_~!Ref: 

    <<: *~!stage_job

    stage: ~!Stage

    dependencies: []

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

        variables:

        - $CI_PIPELINE_SOURCE == 'web'

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

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

В тексте постоянной части задания не рекомендуется использовать переменные ~! значения которых для каждой ИБ, собираемой в ветке будут разными. Например, для одного технического проекта может быть определено две информационные базы для сборки. В этом случае, если значение переменной применено будет только для одной из ИБ в порядке автоупорядочивания. Вместо этого, в постоянной части, например в тексте скрипта следует использовать переменные окружения командного процессора Windows CMD: %DATABASENAME%, Windows PowerShell &DATABASENAME, Linux bash $DATABASENAME,

А в переменной части определять их в секции скрипта variables:
      variables:
           - DATABASENAME: ~!DATABASENAME

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

Имена переменных StagesStageRef зарезервированы. Остальные переменные формируются по принципам, описанным в Справочник "Алгоритмы определения переменных", там же описан механизм сворачивания нескольких заданий в одно.

По нажатию на кнопку "Получить текст сборочной линии" можно получить текст на языке yml, например, чтобы подставить его в форму Gitlab CD/CI CI Lint для проверки корректности.

Справочник Типы СУБД

Справочник предназначен для хранения типов баз СУБД, поддерживаемых 1С:Предприятием. 

Наименование элементов должны повторять перечисление (см. ниже) т.к. имя элемента используется в процедурах администрирования кластера 1С 

  • MSSQLServer - Microsoft SQL Server;

  • PostgreSQL - PostgreSQL;

  • IBMDB2 - IBM DB2;

  • OracleDatabase - Oracle Database.

Внутри каждого элемента для пользователей с полными правами и администраторов сборок* доступны для редактирования элементы справочника "Пакетные задания", три из них предопределены**:

  • Копирование из родителя - используется для создания клона ИБ для другого объекта сборки

  • Параметры ИБ - для заполнения дополнительных параметров информационной базы, которые могут быть получены из СУБД по имени базы, например физическое месторасположение.

  • Список ИБ - для определения доступности на сервере СУБД ИБ, записанной в элементе справочника "Информационные базы"

Остальные могут дополняться по усмотрению, подробнее см. справочник "Пакетные задания"

Разделитель колонок запросов - используется в предопределенном алгоритме "Delimiters", может использоваться и в других алгоритмах справочников "Алгоритмы определения переменных", "Пакетные задания" и "Сборочные линии"

__________________

* Операции по созданию новых тестовых баз, и их обслуживанию. включая использование обработок считается административной обязанностью и не предназначено для обычных пользователей. разработчиков, методологов или кого-либо.

** Предопределенные элементы не являются на самом деле предопределенными элементами и предопределение эмулируется, так как индивидуальны для каждого элемента справочника "Типы СУБД"

Подчиненный справочник Пакетные задания

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

Все пакетные задания исполняются из формы элемента справочника "Информационные базы" и доступны пользователям с "Полными правами" либо "Администратор сборок"

Для длительных пакетных заданий можно включить признак "Запустить задание фоновым процессом", однако такой вариант запуска не предполагает постобработки вывода*. Алгоритм подготовки переменных для пакетных заданий, предполагающих фоновую работу, исполняется непосредственно перед стартом пакетного задания.

Справочник не является самостоятельным, и подчинён справочнику "Типы СУБД" и доступен для открытия из формы элемента этого справочника. Такая логика продиктована специфичностью алгоритмов для определенного сервера СУБД. Пакетные файлы для MS-SQL будут мало полезны для Postgre SQL. 

Алгоритму подготовки переменных, и постобработке доступен через структуру "Параметры.Объект" текущий открытый элемент справочника "Информационные базы" с типом СправочникОбъект.ИнформационныеБазы, точнее ДанныеФормыСтруктура, повторяющего реквизиты справочника "Информационные базы"

В структуре Параметры для алгоритма подготовки переменных содержится соответствие "Переменные" в которое необходимо заполнить все переменные объявленные в шаблоне пакетного задания, которые не описаны в справочнике "Алгоритмы определения переменных". 

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! Если определить значение переменной в алгоритме подготовке переменных, для которой существует алгоритм получения в справочнике "Алгоритмы определения переменных" то алгоритм в справочнике "Алгоритмы определения переменных" игнорируется.

Для алгоритма постобработки в структуре "Параметры" присутствует реквизит "Вывод", содержащий вывод текста пакетного задания, который может быть обработан алгоритмом, и в переданном объекте может быть установлена дополнительная переменная описывающая объект ИБ, используя экспортный метод Справочники.GLI_ИнформационныеБазы.УстановитьЗначениеПеременной**, например:

Справочники.GLI_ИнформационныеБазы.УстановитьЗначениеПеременной(Объект , "SourceLogicalDBLogName", Данное.Поле2);

где Объект - СправочникОбъект.ИнформационныеБазы, второй параметр имя дополнительной переменной, третий параметр - устанавливаемое значение

или реквизит текущего элемента справочника "Информационные базы"

Для конвертации вывода из таблицы в виде текста с разделителями существует экспортный метод в программном интерфейсе:

GLI_РаботаСПакетнымиФайлами.ПолучитьТаблицуИзТекстаСРазделителем(ТекстСТаблицей,РазделительКолонок), 

возвращаемое значение: ТаблицаЗначений с колонками Поле1,Поле2...ПолеN

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! Процедура не ожидает заголовков в таблице, если в выводе отключить заголовки невозможно, то они будут в первой строке полученной таблицы значений.

https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! И алгоритм подготовки переменных, и алгоритм обработки данных исполняются в безопасном режиме.

- Вывод пакетного задания, выполняющегося в фоне, не должен содержать спецсимволов, например BS (забой). 

- Инструкции перенаправления вывода тоже будут проигнорированы при любом режиме исполнения, так как обработчик пакетного файла для перехвата вывода сам вставляет перенаправление его в файл лога.

_____________________

* Текущее ограничение, в будущих версиях планируется это ограничение снять.
** Метод создан для упрощения работы с табличной частью "Дополнительные переменные", конечно же можно установить переменные непосредственно через параметры.Объект.ДополнительныеПеременные. Метод замещает существующее значение в табличной части безусловно, или создаёт если его нет.

Справочник Алгоритмы определения переменных

Справочник предназначен для хранения алгоритмов (правил) определения переменных. 

Переменные могут быть определены в пакетных файлах обслуживания сервера СУБД - справочник "Типы СУБД" и в YAML фрагментах справочника "Сборочные линии"

Переменная представляет собой литерал, начинающийся на ~! и заканчивающийся перед символом, отличным от символов латинского и русского алфавитов, цифр и знака подчеркивания. На языке регулярных выражений можно описать литералы как [A-Za-zА-Яа-я0-9_]+. литералы выделены жирным шрифтом:

copy ~!ИмяФайлаБазы_1.txt ~!ПутьКопированияФайла\

delete ~!DbName_2.mdf

В справочнике поле "Имя переменной" содержит литерал, например для приведенных выше примеров имена переменных будут:

ИмяФайлаБазы_1

ПутьКопированияФайла

DbName_2

Поле "Этап" содержит имя этапа для справочника "Сборочные линии" если заполнено, то правило получения будет иметь приоритет над одноименными переменными в других этапах. Для скриптов справочника "Типы СУБД" будет предпринята попытка использовать алгоритм только в случае, если отсутствуют алгоритмы получения без этапа. Например, если есть две одноименных переменных для разных этапов с разными алгоритмами получения значения переменных, то для каждого этапа (stage) будет применен свой алгоритм. В случае неоднозначности, например определены одноименные переменные для разных этапов, и текущий этап не совпадает ни с одним из них будет выбрана последняя добавленная в справочник переменная, ошибки выполнения сгенерировано не будет. 

Поле "Алгоритм получения" представляет собой выражение для присваивания на встроенном языке 1С:Предприятия, которое должно возвращать строковое значение, либо значение допускающее неявное преобразование в строку. При вычислении выражения доступна структура из трёх свойств:
ИБ - ссылка на элемент справочника "Информационные базы", "Этап" имя этапа, если допустимо, в противном случае значение поля будет пустая строка, "СборочнаяЛиния" - ссылка на элемент справочника "Сборочные линии", если применимо, Неопределено в противном случае.
https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! Выражение исполняется в безопасном режиме. 

Флаг "Для общего задания". При генерации скрипта на языке YAML сборочной линии производится оптимизация получаемых заданий. Значения переменных каждого этапа вычисляются для каждой информационной базы, требующей сборки и объединяются в пул переменных и их значений. Если значения переменных получаемых в задании для каждой собираемой или тестируемой информационной базы получатся одинаковыми, то вместо отдельного задания под каждую информационную базу будет сгенерировано одно общее задание, в котором будут перечислены все ссылки (refs Git) используемые в ограничении заданий only: refs:. Если одна переменная имеет несколько алгоритмов, и один из них маркирован как "Для общего задания" то такая переменная из пула переменных для принятия решения о способе генерации заданий будет исключена. Более того, для получения значения такой переменной в общем задании будет использован именно этот алгоритм. В противном случае для каждого задания на свою ветку будет предпринята попытка вычисления алгоритма без флага "Для общего задания". Цель данного механизма уменьшить количество заданий в результирующем скрипте на языке YAML для этапов конвейера, которые для всех информационных баз будут исполняться одинаковым образом. 

В демонстрационной базе есть переменная JobSuffix, используемая для формирования имени заданий. Для неё определены два алгоритма получения значения:

Для общего задания Алгоритм получения
[  ] СтрЗаменить(Параметры.ИБ.Наименование,"/",".")
[V] "United"

В этом случае если в шаблоне задания или самом задании не будет определено других переменных, получающих значение параметров информационных баз для сборки и связанных с ними веток, то будет получено значение "United":

Допустим, в повторяемой части шаблона задания определена переменная Stub, у которой алгоритм получения "JustOneLine":

ConvertEDT_XML_~!JobSuffix: 

    <<: *convertation_job

    stage: ~!Stage

    dependencies: []

    variables:

        STUB: '~!Stub'

    only:

        refs:

        - ~!Ref

        changes:

        - TEST-CONF/src/**/*

Результирующее задание:

ConvertEDT_XML_United
    <<: *convertation_job
    stage: Convertation
    dependencies: []

    variables:

        STUB: 'JustOneLine'

    only:
        refs:
        - master
        - TP/00-00000256
        - Tst/102

        changes:
        - TEST-CONF/src/**/*

Если заменить алгоритм получения переменной Stub на: Строка(Новый УникальныйИдентификатор()), то результирующие задания получатся такие:

ConvertEDT_XML_CI_YML_TEST: 

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: '0a09ca20-8f4a-48f7-8110-e6f2a8303a93'

    dependencies: []

    only:

        refs:

        - master

        changes:

        - cpm/src/**/*

ConvertEDT_XML_CYT.TP.00-00000256

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: 'c2000413-49d1-4b7f-a954-534421cad798'

    dependencies: []

    only:

        refs:

        - TP/00-00000256

        changes:

        - cpm/src/**/*

ConvertEDT_XML_CYT.Tst.102

    <<: *convertation_job

    stage: Convertation

    variables:

        STUB: '86418d3c-9e00-4229-bdb0-a7e2fe9bcb4c'

    dependencies: []

    only:

        refs:

        - Tst/102

        changes:

        - cpm/src/**/*

Однако, если для переменной Stub добавить 2й алгоритм получения с признаком "Для общего задания", например "Федот да не тот" то результат станет таким:

ConvertEDT_XML_United
    <<: *convertation_job
    stage: Convertation
    dependencies: []

    variables:

        STUB: 'Федот да не тот'

    only:
        refs:
        - master
        - TP/00-00000256
        - Tst/102

        changes:
        - TEST-CONF/src/**/*

Отчет Подготовка описания версии по техпроектам и ошибкам

Отчет предназначен для подготовки описания релиза. Уровень детализации рассчитан таким образом, чтобы описание обновления, выводимое средствами БСП не делать вручную, а просто скопировать из сформированного отчета:

Отчет опирается на номера сборок в исправлениях ошибок и технических проектах, которые в свою очередь заполняются номерами сборок в процессе оповещения о успешной сборке линии конвейера для той или иной ветки. Номер сборки последнего релиза указывается вручную в поле "Начальный номер сборки (больше):". Для технических проектов учитывается номер сборки:

 

на закладке "Основное", для ошибок исправляемых в разных ветках учитывается номер сборки, указываемый в табличной части "Исправления в ветках":

Для остальных ошибок поле внизу:

Кроме этого, учитывается:

  • Для идей, реализованных в рамках технических проектов, выводящихся в секции "Реализация функционала"

    • Идея должна быть в статусе "Реализована"

    • Ветка технического проекта должна быть помещена в ветку версии - статус "Помещена"

    • Все задачи процессов, связанные с техническим проектов, должны быть в статусе либо "Отменена", либо "Выполнена", и она хотя бы одна должна быть. Рекомендуется на каждую идею, заводить задачу процесса, для отслеживания процесса реализации идеи.

  • Для любых ошибок:

    • Статус ошибки должен быть "Проверена, исправлена", для ошибок, исправляемых в разных ветках состояние исправления в ветке нужной версии должно быть "Исправлена и проверена", в этом случае ошибка выводится в секции "Исправление ошибок

    • Статус ошибки должен быть "Отозвана", для ошибок, исправляемых в разных ветках состояние исправления в ветке нужной версии должно быть "Не планируется исправлять", в этом случае ошибка выводится в секции "Не является ошибкой (отозвано)"

    • Ошибка должна быть публикуемой (закладка "Признание", "Статус публикации")

Для ошибок, исправляемых в рамках технических проектов, дополнительно выводится номер технического проекта.

Для ошибок, у которых заполнена ссылка на первоначальный источник (предполагается гиперссылка) выводится отдельная секция источник.

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

Для ошибок, разделяясь пустой строкой, выводятся секции "Публикуемое описание", закладка "Признание" и "Описание" закладка "Исправление"

Для реализованных идей выводится описание реализации идеи в техническом проекте колонка "Описание реализации идеи, исправления ошибки" закладки "Идеи и ошибки"

Расширение объектов основной конфигурации

Справочник Ошибки

Изменены логика формы списка и формы элемента. Улучшена эргономика работы с исправлением ошибок в варианте "В разных ветках", т.к. разные состояния исправления в ветках приводили к неразберихе и не соответствию общему статусу ошибки. Для этого были расширены и дополнены состояния исправления ошибок в ветке и статусов ошибки, так чтобы они соответствовали друг другу:

Статус ошибки Состояние исправления ошибок
Признана Требуется исправление
Исправлена Исправлена
Проверена и исправлена Исправлена и проверена*
Не зарегистрирована -**
Зарегистрирована Не рассмотрена*
Не признана Исправление не планируется
Отозвана -***
Не планируется исправлять Исправление не планируется

 * Добавленные состояния исправления в ветках

** При первой же записи ошибка переходит в статус "Зарегистрирована" а для всех веток версий выставляется состояние "Не рассмотрена", в случае если ошибка возвращается в статус "Не зарегистрирована"  (кнопкой "Вернуть на регистрацию") в этом статусе состояние исправления ошибок игнорируется, и общий статус ошибки всегда "Не зарегистрирована"

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

В форме списка:

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

  • Пиктограмма около состояния умышлено отображает некий общий статус ошибки, который определяется по следующим критериям:

    • До тех пор, пока хоть в одной ветке есть состояние "Не рассмотрена" общий статус всегда "Зарегистрирована"

    • До тех пор, пока хоть в одной ветке указано "Требуется исправление" общий статус "Признана", при этом в некоторых ветках может быть ошибка уже исправлена и подтверждена, а в некоторых в состоянии "Исправление не планируется", что соответствует статусу "не признана"

    • Как только ни в одной строке исправлений в ветках не останется "Требуется исправление" и "Не рассмотрена" общий статус будет зависит о того, проводилось исправление хоть в одной ветке версии в этом случае общий статус будет "Исправлено". Если ни в одной ветке исправление не проводилось и отмечено как "Исправление не планируется" в этом случае и все ветки рассмотрены, то становится доступным вариант "Отозвать" ошибку в форме помощника регистрации ошибки, а общий статус будет "Не признана". Если в таком состоянии отозвать из любой строки ошибку, то общий статус станет "Отозвана"

    • Если все ветки проверены и исправлены, за исключением тех, в которых исправление не планировалось, то общий статус будет "Проверена и исправлена"

  • Общий статус можно отобразить в списке через "Изменить форму" добавив поле Ссылка.Статус.

В форме элемента:

  • Для варианта "Исправляется" = "В разных ветках" комбинация кнопок "Признать", "Не признавать", "Исправление не планируется", "Отметить исправление". "Подтвердить исправление" теперь зависит от того, в какой строке табличной части "Исправление в ветках" установлен курсор. Если ни одна строка не выбрана технически, считается что для первой. Соответственно можно выбирать состояние исправления как с помощью кнопок, так и с помощью установки состояния исправления. Так же табличная часть дополнена графами "Рассмотрена" с датой рассмотрения ошибки "Требуется исправление/ Исправление не планируется", и "Подтверждена", которая заполняется при подтверждении исправления в ветке.

  • При регистрации новой ошибки вариант исправления "Только в ветке обнаружения"

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

  • На закладке регистрации добавлен реквизит Сборка, этот реквизит заполняется автоматически, каждый раз, когда отмеченная, как "Исправлено" или "Исправлено и проверено" ошибка проходит успешную сборку в ветке тестирования/собственной ветке или ветке версии соответственно. Реквизит Сборка очищается всякий раз, когда ошибку возвращают на исправление. Аналогичный реквизит, для варианта исправления ошибок "Исправляется в разных ветках", присутствует в табличной части "Исправление в ветках", при этом реквизит Сборка на закладке не используется.

  • Если исправление ошибки ведётся в ветке исправления ошибки, с которой не связана информационная база, то при отметке исправления будет создан запрос на слияние в хранилище Git в ветку тестирования (см. подробнее про ветку тестирования в дополнении к описанию по справочнику "Ветки"), при отсутствии конфликтов запрос на слияние будет автоматически принят. При очередной сборке ветки тестирования (момент зависит от настройки для ветки сборочной линии, по умолчанию, сразу же после удовлетворения запроса на слияние) автор и исправивший получат уведомления об успешном завершении сборочной линии ветки тестирования в контекстном обсуждении ошибки, там же будет ссылка на открытие ИБ, которая была обновлена новым состоянием хранилища в ветке тестирования. Проверяющий (автор) проверяет исправление в базе и отмечает нажатием кнопки "Подтвердить исправление" (либо выставляет статус в строке таблицы "Исправление в ветках" соответствующего состояния исправления для варианта исправляется в разных ветках). В момент записи "Ошибки"  автоматически формируется запрос на слияние в основную ветку версии.

  • На закладке дополнительно флаг "не делать запрос на слияние в тестирование" при выборе этого флага не будет сформировано запроса на слияние в ветку тестирование.

  • Для варианта "Исправляется" = "В разных ветках" кнопка "Создать ветки для исправления" заменена на "Создать ветку для исправления" соответственно, в отличие от типового варианта создаётся ветка только для выбранной строки. 

  • Создавать ветку исправления ошибки, а так же заполнять в реквизите объекта "Ошибка" не обязательно, при создании ветки в удалённом репозитории Git, или при помещении изменений новой ветки исправления ошибок автоматически предпринимается попытка найти, при необходимости создать новую ветку и заполнить её в соответствующем реквизите. Автоматическое заполнение ветки исправления доступно для вариантов исправления "Только в ветке обнаружения" и "В разных ветках". Порядок определения родительской ветки (учитываются только ветки версии и основная ветка проекта) следующий:

    • Предпринимается попытка найти ветку версии в той же фиксации, где записан указатель новой ветки исправления ошибки (сопоставление имени ветки производится с кодом ошибки) при неудаче отрабатывает второй вариант поиска.

    • Если ветка уже ушла от родительской на несколько фиксаций. В этом случае определение родительской ветки производится по самой короткой цепочке фиксаций от merge-base с ветками версий. В случае неоднозначности, ветка не создаётся, пользователю в СППР, соответствующему пользователю Git выдается сообщение о невозможности автоматического создания ветки исправления. Сопоставление пользователя СППР и пользователя Git производится по адресу эл. почты, если у пользователя Git он публичный. Если электронная почта не публичная, то производится попытка сопоставить адрес почты в СППР и имя регистрации на сервере Git. Если пользователь не найден, то сообщение о создании ветки и заполнении её в исправлении ошибки выдаётся Исправившему или, при его отсутствии, Автору. Если какой-либо пользователь начал редактировать ошибку в СППР, то заполнение поля ветки исправления ошибки производится через оповещение СВ на клиенте. Таким образом данные, введенные пользователем, не будут потеряны.

Справочник Технические проекты

В форму технического проекта добавлены элементы "Сборка" - номер сборки , заполняется после успешной сборки технического проекта. Реквизит очищается автоматически, при передаче задач процесса, связанных с техническим проектом на проверку.

Важно! Необходимо до начала сборки или в процессе её передать задачу процесса, связанную с техническим проектом "На проверку", в противном случае, если сборка уже закончилась, реквизит не будет обновлён, более того, он будет очищен при передаче на проверку. В этом случае, в отчет "Подготовка описания версии по техпроектам и ошибкам" технический проект включен не будет.

На закладке "Дополнительно" добавлена кнопка создания запроса на слияние  в ветку версии. 

Так же, на закладке "Дополнительно" возращён реквизит "Имя базовой ветки". При указании фиксации в этом поле файл отличий (diff) будет производиться между веткой техпроекта и указанной фиксацией, такой способ указания помогает корректно загрузить изменения в случае, когда перед слиянием в ветку версии ветка техпроекта обновлялась до текущего состояния ветки версии (это делается очень часто, чтобы исключить конфликты слияния при помещении ветки техпроекта в ветку версии). 

В этом случае, в поле нужно вручную указать фиксацию слияния, с которого производилась актуализация ветки технического проекта:

Справочник Ветки

В форме элемента справочника добавлены поля и элементы управления:

  • Кнопка  "Создать ветку в git" - создаёт ветку в хранилище Git, ссылка на который указана в элементе справочника "Проекты", на закладке разработка. Создание ветки производится посредством доступа к API Gitlab настроенным в обработке "Настройка уведомлений о сборках и подключение к GitLab API"

  • Кнопка «Создать запрос на слияние» - создаёт запрос на слияние в ветку слева от кнопки

  • Поле "Ветка тестирования" и кнопка около него "Пересоздать в Git":


В активной фазе проекта может быть зарегистрировано много ошибок, требующих подтверждение исправления. Рекомендуется в таких фазах не исправлять ошибки в ветке версии проекта, либо в одной ветке исправления ошибок, а под каждую заводить отдельную от ветки исправления ошибок, при отметке "Исправлено" в элементе справочника "Ошибки" будет автоматически сформирован и принят (если нет конфликтов) запрос на слияние в ветку тестирования, которую рекомендуется пересоздавать после выпуска каждого релиза. При подтверждении тестировщиком или автором ошибки исправления будет сформирован автоматически запрос на слияние в ветку версии. Таким образом в ветке версии будут только подтвержденный функционал. По событию "detached pipe" могут быть запущены регрессивные тесты сливаемой в ветку версии ветки исправления ошибки. Автоматического принятия запросов на слияние в ветку версии не предусмотрено. Ответственный за сборку релиза сам должен проверить и принять все исправления в ветку версии. При нажатии на кнопку "Пересоздать в Git" ветка тестирования удаляется в хранилище и создаётся заново от указателя ветки версии, после чего определяются удовлетворённые запросы на слияние в ветку тестирования, которых не было в ветке версии (по учетным данным СППР), СППР заново формирует запросы из веток исправления ошибок в ветку тестирования. 

  • Секция "Информация о сборке" - версия, сборка заполняются автоматически. Версия, аналогично типовому функционалу, определяется из ссылки элемента справочника "Версия проекта", сборка прописывается автоматически каждый раз при начале и окончании сборки в GitLab и соответствует номеру сборочной линии.

  • Секция GLI уведомления, информация. Добавляются пользователи - кураторы ветки, эти пользователи будут получать уведомления о сборках ветки вне зависимости от объектов сборки (Ошибки, техпроекты). Если этот список пуст, и при сборке ветки (например, запущенной по расписанию или вручную) новых объектов сборки, по данным СППР, не добавится - уведомления не придёт никому.

Подчиненный справочник Сборки версии

Элементы справочника добавляются автоматически при каждой сборке, последний статус сборочной линии:

  • pending (ожидание)

  • running (запущена)

  • canceled(отменена)

  • failed(завершилось с ошибкой)

  • success(завершилось с успехом) 

записывается в добавленный реквизит объекта, который выведен в форму элемента. 

В процессе записи статуса производится попытка определить тип версии. Если в наименовании фиксации содержатся текстовые строки RDef, описание версии, описание релиза, то сборке присваивается статус "Финальная" и выставляется флаг публикации. 

Дата и время сборки определяются по данным сервера СППР.

Обработка Настройка уведомлений о сборках и подключение к GitLab API

Обработка предназначена для настроек бота уведомлений системы взаимодействия (СВ), указания связей id проекта в Gitlab, приватного ключа пользователя СППР в Gitlab  настроек уведомлений для администраторов сборок.

Настройки бота

Бот единый для всех проектов. После первоначального создания бота, вместо кнопки "Создать бота" будет присутствовать кнопка "Обновить бота"

Важно! Изображение бота хранится в СВ, так что замена изображения в копиях ИБ, не отвязанных от СБ приведёт к изменению изображения в основной базе.

В поле "Пользователь ОС" необходимо указать пользователя, которым будут олицетворены все запросы от веб сервера к СППР, этот пользователь будет ассоциирован с пользователем бота в части аутентификации операционной системой. Если используется веб сервер Apache, не поддерживающий анонимную аутентификацию тогда следует задать отдельно пользователю - боту пароль и использовать другой способ аутентификации.

См. ниже пример настройки пользователя в IIS

Важно! Если база СППР опубликована на веб сервере в виде тонкого клиента, то для HTTP сервисов потребуется отдельная публикация с использованием анонимной аутентификации, в которой должен быть указан тот же пользователь системы, что и в этом поле. Например, основная публикация СППР сделана как sppr и доступ к ней осуществляется по ссылке https://my_server.ru/sppr то для http сервисов компоненты нужно сделать вторую публикацию - только http сервисы, например sppr_api и указывать ссылку https://my_server.ru/sppr_api. Аутентификация должна быть настроена таким образом, чтобы любое обращение к API приводило к авторизации пользователя бота, права которого в СППР минимальны (права (Внешнее соединение, HTTP REST сервисы) настраиваются автоматически при создании пользователя). не рекомендуется давать этому пользователю прав более, чем устанавливается автоматически. 

Соответственно ссылка, которую нужно будет указать в разделе Gitlab WebHooks: https://my_server.ru/sppr_api/hs/BS/file.json

Откройте проект в Gitlab и в разделе Settings/Webhooks. Укажите полученный URL http-сервиса BS СППР. Отметьте события Push eventsMerge request events, Pipeline events. Установите или снимите флаг SSL верификации в зависимости от типа публикации. Нажмите кнопку Add webhook.

Проведите тестирование, нажав на кнопку Test/Push events. Gitlab отправит событие push с SHA на который указывает origin/master в качестве теста. Откройте регистр сведений JSON, если появилась запись, соответствующая по времени отправке и по комментарию соответствующая фиксации указателя origin/master в проекте - значит настройка API СППР проведена верно. Можно ещё открыть, нажав на кнопку Edit, отправленные веб хуки, и, открыв последний, просмотреть детали - сообщение JSON. Это же сообщение должно быть в регистре сведений JSON в поле "Запрос".https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! Процедур очистки регистра сведений JSON не предусмотрено, очищайте его самостоятельно во избежание разрастания ИБ СППР.

Ссылка для получения файла конвейера будет выглядеть как https://my_server.ru/sppr_api/hs/GetPipeline/PipelineOfMyProject/ci-module.yml, где PipelineOfMyProject - имя элемента справочника "Сборочные линии"

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

В секции Настройки gitlab API для каждого проекта указать следующие настройки:

  • Идентификатор проекта в Gitlab

  • Частный токен пользователя, от лица которого СППР будет авторизоваться, например "СППР". https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! У этого пользователя должно быть достаточно прав для того, чтобы принимать запросы на слияние в ветки тестирования и создавать запросы на слияние в ветки версии, а также удалять ветки.

  • Префиксы веток, если не указывать, то будут использоваться префиксы веток указанные в образце заполнения. В типовом релизе СППР наименования веток получаются очень длинными, в результате их не удобно просматривать в истории EDT, поэтому не рекомендуется делать префиксы веток длинными. https://yandexmusic.userecho.com/s/cache/8a/db/8adb74673013ebe1e1e0c6524762de31.png Важно! префиксы со слешем "/" формируют подкаталоги в учётной системе Git, Windows не различает верхний и нижний регистр при поиске, поэтому после выбора префиксов с "/", крайне не рекомендуется менять у них регистр.

Варианты и особенности сценариев учета исправления ошибок в СППР при использовании расширения «Управление сборкой GLI»

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

  1. С точки зрения Git сборка происходит ветки. Git не знает что он собирает, по этому вся информация кого уведомлять получается из СППР.

  2. Объектом сборки считается любой объект, ссылающийся на ветку сборки (элемент справочника «Ошибки» в поле «Ветка исправления» шапки или в поле «Ветка исправления» в ТЧ «Исправления в ветках» или в поле «Ветка разработки» справочника «Технические проекты»), у которого не заполнен реквизит «Сборка» и статус либо «Исправлена», либо «Исправлена и проверена». У справочника «Ошибки» реквизит «Сборка» в зависимости от способа исправления ошибки (в разных ветках или в одной) может быть либо внизу, над кнопками:

    либо, если исправление ветки ведётся в разных ветках, в табличной части «Исправления в ветках»:

    Технический проект:

    Значение поля очищается:

    1. При записи элемента справочника «Ошибки» со статусом «Исправлено» или «Исправлена и проверена», либо в шапке, либо в табличной части «Ветки»

    2. В шапке технического проекта, при направлении на проверку задачи процесса технического проекта.

    3. Для прочих внештатных ситуаций поле доступно пользователям с ролями «Администратор» и «Администратор сборок» для изменения.

  3. Если поле «Сборка» не заполнена, то объект включается в уведомления при сборке ветки связанной с объектом сборки, пользователи для уведомления извлекаются из объекта сборки, если нет ни одного объекта сборки ожидающего сборки, связанного с собираемой / тестируемой веткой то пользователи для уведомления выбираются из ветки, для веток версий, тестирования этот список доступен для заполнения.

В ветке с типом «Ветка для исправления ошибок»:

Без индивидуальной ИБ, для проверки исправления используется общая ветка тестирования ветки версии.

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

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

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

    • Обособлено:

      • Порядок учета исправления ошибки для такого варианта был приведен ранее. Такой вариант предпочтителен в «разгар» разработки, когда недоработок и ошибок много, не все подтверждаются сразу, и необходимо не допустить попадание лишних «недоделок» в ветку версии, и соответственно в основную ветку. Кроме этого, экономится место на диске, т.к. после этапа миграции эталонная ИБ. И соответственно все её оперативные клоны могут резко вырасти.

      • Под исправление каждой ошибки создаётся индивидуальная ветка.

    • Совместно:

      • Порядок учёта исправлений ошибок для такого варианта аналогичен предыдущему, и по-прежнему будет возможность тестировать исправления в ветке тестирования. Разница в том, что заводится одна ветка с наименованием, например, «BF/COMM-1» или «BF/ClsMnth-11». Далее, исправление ошибок по очереди фиксируются в ветке, после каждой отметки исправление происходит слив фиксации в ветку тестирования, а при отметке подтверждено делается запрос в ветку версии. Такой вариант удобен, когда исправляется много мелких ошибок, объединенных по какому-либо признаку, например ошибки при закрытии месяца. Или в том случае, когда обособленные исправления зарегистрированных ошибок не имеют смысла.
        Важно! При отметке исправления или подтверждение любой исправленной ошибки вся ветка будет влита либо в ветку тестирования, либо в ветку версии. В таком сценарии трудно будет исключить неподтвержденный код какой-либо ошибки из общей ветки, помочь в этом сможет операция интерактивного перебазирования, при которой фиксации с неподтверждёнными ошибками можно пропустить, однако нужно иметь в виду, что при возникновении конфликта слияния во время операции перебазирования, возможности EDT сильно ограничены типовым функционалом Git и разрешать конфликты придётся вручную.

С выделенной, привязанной к объекту сборки (ошибке или ветке) ИБ.

  • Запросов на слияния в ветку тестирования не производится. Однако запрос на слияние в ветку версии будет сформирован при подтверждении исправления. В этом варианте при сборке выдаётся заголовок и сообщение из хранилища Git к фиксации, для которой производится сборка:

    Пропущенные фиксации, по которым не проходила сборка не отслеживаются. См. пример исправление ошибки BF/00-00000004 на демонстрационном стенде.

    • Обособленно:

      • Привязка ИБ производится к объекту сборки: элементу справочника «Ошибки».

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

    • Совместно:

      • Тестовая ИБ в этом случае привязывается к ветке, т.е. в качестве объекта сборки выступает ветка исправления ошибок.

      • Так же, как и без выделенной ИБ критерии – исправить несколько ошибок, сгруппированных по какому – либо единому признаку и сразу все протестировать и принять, оптом.

В ветке версии:

ИБ привязана к ветке версии.

Порядок уведомлений о собранных исправлений ошибок такой же, как и для ИБ, привязанной к ветке исправления ошибок. Такой вариант удобен при начальном формировании ветки версии, например, сразу после того, как в новую ветку версии поместили обновленную от поставщика конфигурацию проекта, как правило ещё сырую и требующую рефакторинга. В этих случаях, релиза ещё не было и фиксации удобно делать прямо в ветку версии. Далее, после публикации первого релиза (или получения первой работоспособной базы, обычно это происходит одновременно) предполагается ввести запрет от непосредственных фиксаций в ветку версии (по крайней мере запретить делать фиксации для участников проекта с уровнем доступа «Разработчик», оставить только для администраторов проекта).

В ветке технического проекта

ИБ привязана к техническому проекту.

В ветках технических проектов регистрируют особый сорт ошибок, которые как правило ещё не дошли до релиза. Чисто технически уведомления ничем не отличаются от варианта исправления ошибки «С выделенной, привязанной к объекту сборки (ошибке или ветке) ИБ.» Ошибки подобного рода выявляются при внутреннем тестировании в ИБ, связанной с веткой технического проекта. Если технический проект ещё активен, как правило ошибку добавляют в этот же технический проект, где она прописывается на закладке «Идеи и ошибки» в остальном работа с ошибкой не отличается от обычной ошибки, исправляемой в ветке исправления ошибки. Так же, в рамках технических проектов исправляются ошибки, найденные в выпущенных релизах и исправление таких ошибок, может привести к изменению кода будущего функционала, который в настоящий момент дорабатывается. Подробнее о таких ошибках можно прочитать здесь: 9.6. Работа с ошибками, требующими проектирования :: 1С:Предприятие 8. Конфигурация «Система проектирования прикладных решений». Редакция 2.0. Руководство пользователя (1c.ru). При сборке ветки если в техническом проекте нового функционала не реализовали (задач процессов на проверку не было передано) – номер сборки в ТП остаётся прежним, а номер сборки прописывается только в ошибке. Важным плюсом является возможность не описывать подробно изменения в метаданных ошибки, так как все изменения ветки технического проекта будут загружены в таблицу ОМД вместе с данными технического проекта. Следует отметить, что графа «Описание реализации идеи, исправления ошибки» не используется в части ошибки при формировании отчёта: «Отчет Подготовка описания версии по техпроектам и ошибкам» для вывода исправлений используется текст с соответствующей закладки ошибки «Исправление».

Сценарии создания веток в Git и взаимосвязь веток Git с одноименным справочником «Ветки» в СППР.

Разработчик, при выполнении доработок должен связать объект доработки в СППР и указать СППР в какой ветке производилась доработка или исправление ошибки. Указание веток в объектах сборки позволяет автоматизировать операции – автоматическое формирование запросов на слияние при передаче в тестирование и получение метаданных доработок из Git, при разработке в техническом проекте. Делать это можно двумя способами, описанными ниже.

Создание веток из СППР

Утилита расширяет возможности типового функционала для работы с ветками Git. Основная ветка проекта - master вводится автоматически при создании нового проекта в СППР. В Git на создаётся по умолчанию при создании первой фиксации в хранилище. Все остальные ветки можно создавать в СППР через нажатие кнопки с пиктограммой: . При нажатии на кнопку в удалённом Git будет предпринята попытка создания ветки, если попытка успешна – будет выдано соответствующее сообщение, при неудачном создании будет выдано диагностическое сообщение. Для получения ветки в локальный клон хранилища разработчику необходимо выполнить операцию Получить из удаленного хранилища (Fetch).

Создание веток в СППР при первичном помещении ветки в удаленное хранилище

Внешне это может выглядеть по-разному, однако технически при появлении в удаленном хранилище фиксации с новой веткой производится попытка связать эту ветку с соответствующим элементом справочника «Ветки», найти соответствующий объект сборки, и подставить элемент справочника «Ветки» в него, тем самым указав ветку разработки или исправления ошибки в объекте сборки. Если такого элемент в справочнике ветки отсутствует, предпринимается попытка определить родительскую ветку версии, и при отсутствии неопределенностей элемент справочника «Ветки» будет создан в СППР, о чем пользователь получит уведомление в системе:


Технические моменты и способ поиска базовой (исходной) ветки описан здесь. Аналогичное поведение будет предпринято при создании ветки в веб интерфейсе Gitlab.

 
Инструкция по установке и настройке интеграции (вариант для Windows/MS-SQL) когда для тестового контура 1С:Предприятия используется СУБД MS-SQL, скрипты конвейера и обслуживания приведены на командном языке CMD.

 

 
Инструкция по установке и настройке интеграции (вариант для Linux/Postgres) когда для тестового контура 1С:Предприятия используется СУБД Postgres SQL, скрипты конвейера и обслуживания приведены на командном языке BASH.

Можно создавать гибридные варианты конвейеров, когда ИБ тестируются сразу на нескольких СУБД, сборочный конвейер может состоять из разных этапов, написанных на разных скриптах, которые будут исполняться на бегунах Gitlab в разных ОС, однако скрипты обслуживания баз и кластера должны быть на том командном процессоре, на котором установлен сервер 1С:Предприятия содержащий ИБ СППР.

Адрес демосервера для Windows/MSSQL
Адрес демосервера для Linux/Postgres

Пользователь "Только на просмотр" без пароля на демосерверах - Аудитор
Подсистема «Управление сборкой GLI» зарегистрирована в Роспатенте и реестре Российского ПО

Ссылка на страницу ПП на сайте автора: «Управление сборкой GLI»
Что нового? Описание обновлений системы.

Причины купить

Эта разработка уникальна в своём роде. Используется и развивается с августе 2020 года. 
Основной предпосылкой к её созданию послужило реализация требований, описанных ранее в статье: Технология разветвлённой разработки, использующая git, ci/cd. Т.е. требования были описаны раньше, но реализовать их только с помощью СППР не получалось, либо было неудобно. Не было какой то единой структуры.

В расширении есть много интересных решений и примеров по интеграции с Gitlab API, код присутствующий в ней поможет сэкономить не одну неделю разработчику, который задумал сделать свою собственную интеграцию с Gitlab. Расширение содержит некоторые исправления проблем типового функционала СППР, в частности работа с ошибками, загрузка изменений из Git в технические проекты. Для подсистему управления сборкой есть встроенная справка с примерами использования. Фактически это готовый продукт - бери и работай. 3 месяца бесплатной техподдержки помогут быстрее осуществить запуск подсистемы в эксплуатацию.

Благодарность автору статьи, которая сильно помогла 3 года назад с освоением gitlab'a: Сборка приложения, разработанного на EDT, с помощью gitlab-ci (infostart.ru)

Достоинства

Ключевые моменты реализованные в подсистеме.

Реализация требования ведения эталонных и тестовых информационных баз. 
Театр начинается с вешалки, а моделирование процессов предприятия в проекте начинается с создания эталонных тестовых баз. Из которых минимум одна, рано или поздно станет прототипом системы, переживёт миграцию и уйдёт в продуктивный контур проекта. Но от этого, она не перестанет быть эталонной. Количество эталонных баз в разных ситуациях может быть разное, но как правило две создаются всегда - это пустая, в которой проводится начальное заполнение и демонстрационная база, та же конфигурация, но заполненная какими то тестовыми данными типа ООО "Ромашка", на которых можно освоить работу функционала системы и продемонстрировать заказчику. Очень часто используют термин "база моделирования" процессов предприятия. Этот набор баз является исходной точкой для всех остальных тестовых ИБ, которые могут присутствовать в процессе разработки системы. Т.е. все остальные ИБ, по сути являются теми или иными клонами эталонных ИБ.
Меня как архитектора, всегда раздражала ситуация: "Кто в лес, кто по дрова" Когда каждый член проектной команды (методолог, консультант, архитектор, разработчик) присоединяясь в определённый момент времени использует непонятно какие базы для моделирования процессов, непонятно какие платформы. "Что стояло на том и развернул". Очень часто члены команды разворачивают разные релизы исходной системы, что приводит совсем к анекдотичным случаям. Но, в итоге, это ни к чему хорошему, кроме как пустая трата времени на выяснение разницы в релизах не приводит. Так быть не должно. 
Тестовый контур должен быть доступен всем членам проектной команды, либо это ВПН, либо непосредственно локальная сеть, и все ИБ должны открываться из одного места. В предлагаемом расширении это справочник "Информационные базы":
Информационные базы
Для режиме толстого клиента доступны ещё несколько информационных колонок, однако на практике получение данных для них требует авторизации и отнимает много времени, если базы большие. Удалять функционал не стал, вдруг в будущем что то изменится? На любителя.

 
 Видео различных вариантов создания ИБ из эталонных и прикрепление их к веткам разработки

Таким образом есть единое место, откуда производится открытие тестовых и эталонных баз для всей проектной команды. Есть возможность задать свой персональный пароль для ИБ, чтобы не проходить авторизацию каждый раз (на случай отсутствия аутентификации ОС), все остальные настройки доступны администратору сборок. Именно он создаёт или клонирует информационные базы в процессе выдачи в работу технических проектов и исправлений ошибок. Остальные могут их только запускать и работать с ними. При этом список ИБ 1С не используется, и ничто не мешает пользователю "по старинке" зарегистрировать ИБ у себя в списке обычным образом. Предполагается, что клиентская часть платформы должна стоять у члена проектной команды и работает он с тестовыми ИБ по протоколу тонкого клиента.

Реализация требования сборки эталонных и тестовых ИБ.
Если посмотреть на список ИБ то в колонке есть ссылка на "Основной объект сборки", это очень важный момент, так как в предлагаемом решении шаблон сборочной линии создаётся один раз (ну хорошо, буду честен :), добавлю: "и правится в течении проекта постоянно, так как требования могут меняться" у меня так и было, пока не родилось это расширение). Однако с учётом предложенного функционала в действительности так может и быть: один раз создали шаблон и он работает самостоятельно. 
Как это работает?
В колонке СУБД (см. картинку выше) есть маленькая зелёная пиктограмма, означающая что ИБ с указанным "Наименованием" присутствует физически на сервере СУБД из колонки. В процессе формирования запроса динамического списка происходит реальное опрашивание доступности баз на СУБД. Текст сборочной линии генерируется только для тех веток, которые связаны с "Основным объектом сборки" у информационных баз, которые реально присутствуют на сервере. Здесь нужно отметить, что GitLab пытается отработать сборочную линию, которая указана в ключевом файле .gitlab-ci.yml при наступлении вариантов событий для определённой ветки или тэга:

  • Push (Фиксирование) 
  • Принятие merge-request (запроса на слияние) (только ветки)
  • Запуск сборочного конвейера по расписанию.
  • Запуск сборочного конвейера вручную через веб интерфейс
  • Запуск сборочного конвейера посредством gitlab API, например: 
    curl --request POST --header "PRIVATE-TOKEN: " "https://gitlab.example.com/api/v4/projects/1/pipeline?ref=main"

Для каждого из указанных вариантов производится попытка получить версию текста сборочной линии из файла .gitlab-ci.yml для указанной ветки, и при случае, если в нём будут найдены задания для указанной ветки/тэга сборочный конвейер начнёт отработку заданий. Если же ни одного задания для указанной ветки не будет найдено то не произойдёт ничего. Запущенные сборочные линии по 5 представленным выше вариантам будут отличаться лишь в значении одной переменной окружения: "CI_PIPELINE_SOURCE" выставленной в одно из значений: push, merge_request_event, schedule, web, api. (на самом деле вариантов чуть больше, подробнее об этом здесь)

В ключевом файле .gitlab-ci.yml нашего проекта необходимо указать ссылку на публикацию http сервиса СППР GetPipeline (ссылка работает) следующим образом:

include: 
    - 'http://xn--e1agfaq7azal4a.xn--p1ai/sppr_copy/hs/GetPipeline/CI_YML_TEST/ci-module.yml'

Где "https://xn--e1agfaq7azal4a.xn--p1ai/sppr_copy/hs/GetPipeline/" ваш веб сервер с публикацией СППР, а вот CI_YML_TESTссылка на элемент другого важного справочника "Сборочные линии":

 
 Видео функционала сборочной линии

Другими словами, каждый раз когда происходит одно из 5 событий инициирующего запуск сборочного конвейера (pipeline) происходит следующее:

 

  1. Gitlab CI считывает файл .gitlab-ci.yml из корня проекта и в нём пытается загрузить вложение директивой include, которая содержит ссылку на внешний ресурс с файлом ci-module.yml
  2. Происходит попытка получить из веб сервиса СППР подключаемый файл ci-module.yml, по крайней мере gitlab именно так и думает, что он получает этот файл.
  3. СППР опрашивает доступные ИБ в тестовом контуре и на каждую из них генерирует один общий файл сборочного конвейера (очень жаль, что в подключаемый файл нельзя передать никакие параметры, например имя ветки для которой наступает событие pipeline start, тогда бы механизм мог быть ещё эффективнее)
  4. Gitlab CI выбирает из этого файла задания, подходящие для ветки, по которой наступило событие сборки, после чего gitlab-runners (бегуны гитлаба) начинают последовательно их исполнять, в том порядке, в котором указаны в списке stages (этапы) при этом для каждого задания проверяются условия указанные в нём, например наличие изменений в определённом каталоге ветки, по отношению к предыдущей фиксации (commit), либо соответствие значения переменных окружения ожидаемым в задании, если все условия выполнены, то задание будет передано бегуну.
  5. Бегун загружает (при необходимости) артефакты сборки от предыдущих этапов, отрабатывает пакетный файл, указанный в разделе script и результаты, при необходимости сохраняет так же в артефактах сборки. Артефактом сборки может являться, например файл CF или CFU для обновления тестовой или эталонной базы, или лог файл с ошибкой сборки.
  6. Если последнее задание сборочной линии отрабатывает успешно завершается (success) тогда Gitlab генерирует webhook который отрабатывает СППР, оповещая консультантов, методологов, разработчиков через СВ о том, что проведена успешная сборка:
    В противном случае, если произошла ошибка будут уведомлены только администраторы сборок. Для диагностики нужно будет открыть сборочную линию в веб интерфейсе Gitlab и проанализировать файлы логов заданий и разобраться в причинах.
    Как это происходит можно посмотреть на видео:
     
     
     Ещё аналогичное видео с техническим проектом 
    Вариант уведомления, для ветки версии, когда собирается ветка в которую было несколько запросов на слияние, СППР отслеживает запросы на слияние в ветку версии и при сборке сообщает, что тот или иной функционал теперь доступен в тестовой ИБ. Круг лиц для уведомлений выбирается по разному. Для справочника "Ошибки" это все кто присутствует на закладке протокол. Если протокол ещё пуст, то автору (кто зарегистрировал) ошибки. Для технических проектов это закладка "Участники". Для элемента справочника "Ветки" дополнительное поле "Получатели уведомлений"

У читающего этот текст может сложиться вопрос: если для каждой ветки можно сделать свою сборочную линию, включая вариант её полного отсутствия то зачем всё это (расширение, генерация текста сборочной линии на лету) понадобилось?
Вот на это несколько причин:

  • Разработчики 1С, даже перейдя на EDT с конфигуратора далеки от языка пакетных файлов (CMD/PowerShell/Bash), и уж тем более язык YML которым описывается сборочная линия GitLab для них и вовсе как китайская грамота.
  • При слиянии веток разработки возникали конфликты, которые EDT в процессе слияния веток не мог разрешить. В итоге это заканчивалось тем, что очень часто после слияния мне приходилось текст конвейера править. Не могу отметить что я был рад этой "балдовой" работе.
  • Написать универсальный текст сборочного конвейера тоже не получалось из-за различного количества тестовых баз под фичу. В 90% было достаточно одной эталонной копии для тестирования, но для 10% случаев нужны были дополнительные, либо они должны были при сборке копироваться с эталонной и это приводило к тому, что опять же приходилось тратить время на правку YML текста. Сейчас, конечно же я знаю как можно написать универсальный текст сборочного конвейера, но использовать механизм справочника "Сборочных линий" удобнее.
  • Хотя бы потому, что при исправлении ошибок в текстах скриптов не нужно ничего пушить в хранилище (знатоки сейчас подумали: "А кто мешал разместить подключаемый файл так же на сервере?"). Да лень, гораздо проще открыть справочник и поправить несколько строк, получить текст сборочной линии по кнопке "Получить текст сборочной линии" и проверить её с CI Lint:
  • Есть ещё одна причина, достаточно веская. Gitlab не умеет прерывать ранее запущенные сборочные линии, если линия отрабатывает в этот момент задание, у которого переменная GIT_STRATEGY = none. Из всех вариантов сборочных линий, которые мне удалось построить за несколько лет с учётом различных факторов я пришёл к тому, что этапы должны располагаться примерно так:
    • Lock - блокировка и выгонка пользователей информационных баз по таймауту, начиная с 3.1.5 в БСП уже всё включено. До 3.1.5 мы все БСП патчили. Зачем? Подробнее описано здесь.
    • GetCF - получение предыдущей конфигурации для получения CFU (зачем нужна CFU и почему без неё - "труба" расскажу чуть позже)
    • Fetch&Convert - получение из гит и конвертация в формат XML 1С
    • Build - получение CF/CFU новой версии
    • Update - обновление тестовых баз новой CF или CFU
    • UnLock - отработка обработчиков обновления и разблокировка

Это минимум, на самом деле в силу различных причин их придётся сделать ещё больше, и из всех этапов выше только третий: Fetch&Convert будет прерван автоматически CI/CD если будет запушена новая версия в Git. Во всех остальных случаях задания будут продолжаться исполняться и, естественно будут между собой конфликтовать за ИБ. Чем может закончиться этот конфликт в самом худшем случае: потерей тестовой базы. СППР отслеживает запуск новых линий через pipeline webhook, и, при необходимости, если уже есть для этой ветки запущенные аккуратно их прервёт, вне зависимости от значения GIT_STRATEGY в задании. которое сейчас исполняется. GIT_STRATEGY:none необходим, так как самый простой способ передачи данных от предыдущих этапов хранить их в подкаталогах каталога сборки, чтобы не тратить время на загрузку/выгрузку артефактов. Т.е. есть при регистрации бегун в gitlab CI создаст каталог, например: D:\CI_Runner\builds\5gjGWpxd\0\check300373\ci_ymp_test, где ci_ymp_test это рутовый каталог вашего EDT проекта: в нем же можно создать временные каталоги конвертированных файлов, которые при следующем Fetch будут автоматически удалены.

  • Есть конечно же соблазн все этапы положить в единый пакетный файл, однако имейте в виду, что если на этапе разблокировки, например, у вас не будет доступна лицензия 1С:Предприятия и эта часть пакетника не отработает (куда пропадают лицензии - это предмет отдельного разговора), при полном перезапуске или будет обидно за потерянное время: мой рекорд сборки и обновления 120 Гб базы по всем этапам выше с 1й минутой ожидания завершения работы пользователей для конфигурации УХ 3.1.16.2 - 32 минуты (при использовании новой утилиты сборки из XML ibcmd и с ней пока не все хорошо), обычным конфигуратором и того медленнее: 58 минут, или Вам придётся завершать сборку вручную, минусы здесь очевидны:
    • Пользователи не получат обычного уведомления о сборке, к которому они уже привыкли (см. выше пример), Вам придётся их уведомлять самостоятельно
    • Вы потратите своё драгоценнейшее время.
  • Есть ещё одно требование - ПАРАЛЛЕЛЬНОСТЬ, т.е. возможность собирать несколько веток практически одновременно на одних и тех же процессорных мощностях. Задача эта, как оказалось, далеко не из простых. Конфигуратор работает в один поток, а утилита ring использует все имеющиеся процессоры. Конфигуратор работает долго, утилиту ring, как оказалось, можно заставить конвертировать целиком проект УХ в формат XML за 4 минуты на 12 процессорах с частотой 4 ГГц. Возможно, для некоторых это не открытие, но надо лишь просто не удалять папку workspace от предыдущей конвертации. Это сократит минимум 20 минут на создание новой папки workspace утилитой ring. Сделать кэш параллельным для нескольких потоков конвертирования можно, но хранить его нужно для каждого процесса бегуна гитлаба отдельно. В демо базе в примере сборочной линии это именно так и делается в папке --workspace-location %CI_BUILDS_DIR%/%CI_RUNNER_SHORT_TOKEN%/workspace%CI_CONCURRENT_ID%, где CI_BUILDS_DIR - папка которая используется бегуном для сборок, CI_RUNNER_SHORT_TOKEN - токен привязки выбранного бегуна к хранилищу(Один бегун может быть привязан, и обслуживать параллельно несколько хранилищ Git), CI_CONCURRENT_ID - номер параллельного процесса бегуна, исполняющего то или иное задание. При этом нужно понимать, что если в одном пайпе на одном бегуне задание начало исполняться с одним значением CI_CONCURRENT_ID, не факт, что следующее из этого же пайпа будет исполняться с тем же значением. Передавать же 20 с лишним гигабайт конвертированных XML через артефакту - полное безумие. Поэтому пришлось помудрить с такими каталогами. На замену "тугодумному" конфигуратору с релиза 1С:Предприятия 8.3.20 подоспела утилита ibcmd, пример её использования есть так же в демо базе, он закоментирован, отмечал её возможность использования чуть ранее. Её фантастичность в том, что она умеет собирать из XML CF в несколько потоков за три минуты, в отличии от конфигуратора, который тратит на это 30 минут... Однако, не знаю, в чем реально проблема, но интерфейс (только интерфейс, остальное всё собирается на ура) она собирает некорректно. Толи дело в том, что версия XML у меня была для платформы 8.3.17, но в интерфейсе отображались все объекты, которые входили в подсистему, включая вложенные подсистемы, даже если флаг отображения у них был сброшен. Возможно, если собирать XML для платформы 8.3.20 такой проблемы не будет, но мне от её использования пришлось отказаться... 

 

Реализация требования консистентной ветки версии, согласно требованиям п 3.2.
Немного пояснений. Начиная с версии 2.0.3.9 в СППР появился функционал веток - справочник ветки. Для меня это было очень неожиданным шагом, что отложило публикацию этой статьи почти на 1,5 года, и возможно, к лучшему. Я долго ждал, когда же описание нового функционала появится на https://its.1c.ru но на момент начала подготовки публикации 26.04.2022 года оно там так и не появилось, в партнёрской конференции тоже все отмолчались на вопросы - когда же будет описание? Т.е. сейчас описание на ИТС соответствует версии 2.0.1.61. Пришлось разбираться с новым функционалом самостоятельно, методом проб и ошибок.

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

Каждый элемент справочника "Ветки" должен иметь определённый тип ветки:

  • Основная ветка проекта
  • Ветка версии
  • Ветка технического проекта
  • Ветка для исправления ошибок

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

Первые два типа предназначены: 

  • "Основная ветка проекта" - эта ветка системы, либо её прототипа. Конечный продукт, в Git для неё обычно существует ветка master. 
  • "Ветки версии". Их может быть несколько, стартуют от "Основная ветка проекта". Очень важные ветки, их аналог в Git - ветка develop или, правильнее отметить подмножество веток c префиксом dev/*. Например так: dev/1.0.1 - ветка разработки версии 1.0.1 может быть сделана в начале проекта на базе типового релиза поставщика, например на базе типового релиза 3.0.1.12. От этой ветки будет старт большинства веток технических проектов и исправлений ошибок, хотя с ошибками могут быть и другие варианты. Со временем, поставщик выпустит новый релиз 3.0.2.7 и вам потребуется обновить вашу систему в проекте до нового релиза. Вот тогда то вам и потребуется создать новую ветку версии, например dev/1.0.2 и в ней вы будете проводить обновление до нового релиза поставщика. При этом вы сможете не прерывать поддержку существующей версии dev/1.0.1 и вести работы параллельно, все зависит от количества ресурсов. Однако, на момент поддержки двух версий масштабные доработки лучше не проводить (заморозить), в особенности тех блоков. которые претерпели изменения у поставщика. В некоторых случаях зарегистрированные ошибки придётся исправлять и в новой и в старой версии дважды, если они критичные, а исходные механизмы поставщиком были изменены. Но чаще такие исправления откладываются и исправляются только в новой версии, в старой версии в лучшем случае "костыль".  В большинстве случаев, все критичные исправления старой версии можно будет перенести кумулятивно из ветки старой версии dev/1.0.1 простым слиянием в ветку dev/1.0.2. После чего ветка новой версии обычно сливается в ветку master и выходит уже новый релиз в прототип или продуктивную среду с новой версией поставщика. В обычном случае, ошибки, зарегистрированные в старой версии исправляются уже только в новой версии, механизм справочника ошибок на текущий момент имеет такую возможность, плюсом мы его немного "облагородили". Конечно же Вы можете стартовать новую версию и без перехода на новую версию поставщика. Например, если у вас разработка с нуля на базе БСП. Но ведь и новую БСП, и другие библиотеки тоже нужно периодически в систему встраивать. Создание новой ветки версии, как мне кажется, самое удачное применение для этих целей. Кроме этого, допускается исправлять ошибки и вести разработку технических проектов прямо в ветке версии. Мы так делали только при исправлении ошибок рефакторинга сразу после обновления на новый релиз поставщика, например:

О ветках ошибок и технических проектов:

  • "Ветка технического проекта" в большинстве случаев исходная ветка - это ветка текущей версии, возможно новой но только не старой. Изначальная техническая реализация ветки предполагает что в ней может быть несколько технических проектов, мы сочли это слишком запутанным, и ограничили возможность разработки разных технических проектов только для тех случаев, когда предыдущий технический проект завершён, либо полностью отменён. Однако отмечу сразу, в СППР есть загрузка изменений метаданных из Git в технический проект, она не рассчитана на случаи, когда технический проект сливался в ветку разработки более одного раза. Соответственно, если вы вели два техпроекта в одной ветке последовательно (один завершили загрузили изменения ОМД, затем так же со вторым) у Вас возможность извлечь изменения по метаданным будет (нужно будет лишь поменять базовый UID фиксации), а вот если два одновременно - то точно нет. Да, и ошибки, как ни странно. тоже можно исправлять в ветках технических проектов. В этом случае их желательно дополнительно включать в те технические проекты. в рамках которых они исправляются. Естественно "выдернуть" исправление из ветки технического проекта в ветку версии Вы сможете только при условии обособленности изменений и только через "cherry-pick", более того в изменениях ОМД будут изменения по исправлению ошибки тоже.
  • "Ветка исправления ошибок" техническая реализация в СППР этого типа веток предполагает исправление одной или нескольких ошибок в ветке одновременно, но ветка должна принадлежать одной ветке версии. Исправлять ошибки разных версий в одной ветки будет сложно. В теории это возможно. за счёт последующего слияния в ветку другой версии, но будет очень сложно отделить доработки. Каждую фиксацию в ветке правильно оформлять получая описание изменений как на картинке ниже, пример, когда для исправления ошибки выделена индивидуальная ветка, тестирование которой проводилось в общей ветке тестирования: 
    Порядок отражения в ветке версии предыдущего примера, отфильтрованы ветки develop109, master, BF/00-00001604
  • "Ветка тестирования" - важный элемент, добавленный в расширение для поддержки готовности ветки версии к сборке нового релиза в любой момент времени: 
  1. Может быть создана для каждой ветки версии, и только одна. По сути представляет собой тоже ветку версии, но с особым признаком:
  2. К ветке тестирования могут быть присоединены несколько баз тестирования, все они как правило при сборке замещаются из ИБ ветки версии, так как ИБ ветки версии постоянно обновляется из прототипа системы или продукционной ИБ, привязанных к ветке master. Таким образом постоянно пополняется список тестовых примеров для воспроизведения ошибок, зарегистрированных в СППР.
  3. Ветка тестирования должна пересоздаваться после каждого релиза, но можно и пропустить. Пересоздание доступно средствами СППР:
  4. В ветку тестирования сливаются автоматически все ветки исправления ошибок, отмеченные в СППР как "Исправленные", а запросы на слияние в ветку версии только те, которые были переведены в состояние "Проверена, исправлена". Таким образом, в релиз не подтверждённые ошибки не включаются.
  5. После релиза ветка тестирования пересоздаётся и туда "реквестятся" повторно все не подтверждённые, но числящиеся как исправленные ошибки. Если они будут подтверждены, то включатся уже в следующий релиз.
  6. Механизм работает только если каждая ошибка исправляется в отдельной ветке, стартованной от ветки версии, в которой ошибка была обнаружена и для которой была зарегистрирована. В случае, если в одной ветке исправляются несколько ошибок, да и ещё коммиты их будут перепутаны, вытащить в ветку версии реально подтверждённые ошибки очень сложно.
  7. Иногда, бывает, что регистрируются ошибки на один и тот же блок, и тогда при автоматической попытке слить изменения возникает конфликт, ну например разные ошибки исправили внутри одной процедуры. Git автоматом такое не сольёт. В этом случае, если первую ошибку подтвердят - всё просто, ветка исправления ошибки поднимается до ветки версии и слияние в ветку тестирование проходит без конфликтов. Если ни одна ошибка не подтверждена. тогда придётся со второй немного помучится - в EDT извлечь ветку тестирования и слить ветку исправления в неё вручную. Конфликтный MR будет закрыт автоматически. Однако поверьте за 2 года проекта такое было раз 10, не более. В этом случае, возможно и в ветку версии так же придётся сливать изменение через EDT.
  8. В целом механизм позволяет сверить перед сборкой количество запросов на слияние в ветку версии в Git с исправленными ошибками, слить завершённые технические проекты и сформировать описание версии прямо из СППР:

 

Сравнение версий

Статистика:
Просмотры 11603
Загрузки 8
Рейтинг 33
Создание 26.08.22 09:34
Обновление 03.03.24 14:10
№ Публикации 1650163
Характеристики:
Теги

EDT СППР Gitlab CI/CD

Рубрики DevOps и автоматизация разработки
Кому Системный администратор ,
Программист ,
Руководитель проекта
Тип файла Архив с данными
Платформа Платформа 1С v8.3
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль 1С:Франчайзи, автоматизация бизнеса
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Платные (руб)
Код открыт Да
1. roman72 26.08.22 11:42 Сейчас в теме
Грандиозно! Это расширение СППР превосходит саму СППР! :)
Раньше я отбивался изо всех сил, чтобы разработчика не тянуть в СППР, только чтобы читать ТЗ, а теперь придётся рассматривать вариант с разработкой (мёрджингом) на СППР как рабочий.
2. Техподдержка 26.08.22 11:46
(1)
превосходит саму СППР! :)

Спасибо, :) но в СППР сейчас много белых пятен: нового функционала, который не задокументирован. Это тестирование и запуск тестов по расписанию. планирование и многое другое, что добавилось в версии 2.0.2 и версии 2.0.3. Очень хочется верить, что коллеги в 1С всё же поднатужатся и выложат документацию на новые свои фичи на ИТС.
3. Ndochp 30.08.22 08:59 Сейчас в теме
А что закрыто? или все открыто, защита чисто по юридической линии?
Вопрос связан с тем, что это инструмент для разработчика, а не бизнеса. Подпилить может захотеться в любом месте, хочется сразу понять ограничения.
4. Техподдержка 30.08.22 09:01
(3) Добрый день. Код открыт. Это правила и Инфостарта, и 1С
5. Ndochp 30.08.22 09:16 Сейчас в теме
(4) Отлично.
Просто насколько я помню, по правилам ИС открыт код за СМ, так как это не готовые решения, а за деньги может быть по разному. Да и за СМ то без модуля обработка проскочит, то EXE без исходников.

Оставьте свое сообщение

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сцен...

2220 руб.

Автотесты 1С для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения д...

1728 руб.

Подсценарии для заполнения форм типовых справочников и документов конфигураций ERP 2.5 и КА 2.5 (для vanessa automation)

Набор универсальных подсценариев для заполнения форм типовых объектов справочников и документов конфигураций ERP 2.5 и КА 2.5. Сценарии представляют собой feature-файлы для vanessa-automation с тегом @exportscenarios. Используются для разра...

1500 руб.

Приемы быстрой работы в EDT/Git

Статья даёт ответы на некоторые вопросы, возникающие у разработчиков, которые погружаются в океан технологий EDT и Git, омывающий царство DevOps... Сколько и какие ветки нужны? Какой репозиторий выбрать? Кто должен сливать доработки в масте...

Технология разветвлённой разработки, использующая git, ci/cd

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С