1С:CICD

Набор скриптов для организации контуров разработки, тестирования, обновления. Для запуска требуется 1С:Предприятие.Элемент Скрипт версии 9.0.0.3.

Типы организация работы

1. Разработка в конфигурации через расширения.

   [!NOTE] Данный метод разработки наиболее эффективен

   • Основная конфигурация полностью на поддержки, или на поддержке с возможностью изменения.
   • Основная часть объектов на полной поддержке без возможности вносить изменения.
   • В основной конфигурации добавляются/изменяются:
     • Метаданные, приводящие к реструктуризации, и задающие типы.
     • Добавляются общие команды (При этом в модуле фиксируется пустая процедура).
   • В расширениях фиксируются все остальные изменения:
     • Модули;
     • Формы;
     • Шаблоны;
     • Обработки;
     • Отчеты;
     • Роли;
     • и т.д.
   • Конфигурация и расширения хранятся в git-хранилище в файловой выгрузке.
   • Все изменения в рабочие базы попадают в конфигурацию через git-хранилище.

2. Разработка в конфигурации через хранилище 1С.

   [!NOTE] Данный метод разработки также эффективен, однако, в нем отсутствуют преимущества git-хранилища

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

3. Разработка в конфигурации на поддержке.

   [!WARNING] Данный метод разработки менее эффективен

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

4. Разработка в конфигурации не на поддержке.

   [!CAUTION] Данный метод наименее эффективен

   • Основная конфигурация на поддержке с возможностью изменения или не на поддержке.
   • Основная часть объектов на поддержке возможностью изменения или не на поддержке.
   • Все изменения вносятся как в основную конфигурацию, так и в расширения.

   [!TIP] По вопросам организации более эффективной работы в данном режиме обращайтесь к автору.

Исполнение скриптов

Скрипты исполняются с помощью следующего шаблона:

executor <ПутьКСкриптам>main.sbsl -Режимы <РежимыИсполнения> -ПутьДоРепозитория "<ОтносительныйПутьККорнюПроекта>" -Пауза <ОстановитьсяВКонце> -ПутьКНастройкам "<ПутьКФайламНастройки>" -ИменаИБ <ИменаИнформационныхБаз>

• executor - команда запуска скрипта, едина для скрипта U и X.

[!WARNING] Скрипт X инициализируется практически мгновенно, скрипт U инициализируется около 3-5 секунд.

---

[!NOTE] Для исполнителя X в переменных среды необходимо прописать путь к исполняемому файлу executor, а не bin\executor-x.

• ПутьКСкриптам - путь к файлу main.sbsl относительно корня репозитория проекта.

• РежимыИсполнения - задает команды для выполнения скриптов. Можно перечислить несколько команд через запятую.

• ОтносительныйПутьККорнюПроекта - указывается относительный путь от рабочего каталога, в котором запускается скрипт (текущий каталог оболочки исполнения), до корня репозитория проекта. Например, если скрипт запускается из каталога bin, то параметр будет иметь следующий вид ..//.

[!WARNING] Не следует путать рабочий каталог запуска скрипта с местом расположения файлов скрипта.

• ОстановитьсяВКонце - 1 - перед завершением исполнения скрипта, будет ожидаться ввод от пользователя (необходим для анализа вывода лога исполнения), 0 - скрипт завершится, не дожидаясь пользователя.

• ПутьКФайламНастройки - если предполагается хранить файлы настройка не в репозитории проекта, а по альтернативному пути, необходимо в этом параметре указать путь к файлу настройки project_config.json. Файл пользовательской настройки project_user_prop.json автоматически создастся по этому же пути согласно общим правилам инициализации скриптов.

• ИменаИнформационныхБаз - ИмяИБ1,ИмяИБ2,ИмяИБ3 - имена информационных баз, указанных в файле project_user_prop.json, с которыми необходимо выполнить действия. Указываются для команд, содержащих суффикс ib. Указание нескольких имен имеет смысл для следующих команд: update_ib*, check_ib*.

Режимы исполнения скриптов

Инициализация

• init - инициализация репозитория проекта для работы со скриптами.

Сборка бинарных файлов конфигурации

• build_cf - сборка файла конфигурации из файловой выгрузки xml.
• build_cfe - сборка файлов расширений из файловой выгрузки xml.
• build_patch - сборка архива для обновления из файловой выгрузки xml только по полностью или частично снятых с поддержки объектов.
• build_prod - сборка файла конфигурации из файловой выгрузки xml с дополнительным конвертацией конфигурацией поставщика с целью устранения шума ложных различий между основной конфигурацией и конфигурацией поставщика.

Обновление информационной базы

• update_ib - применение изменений к информационной базе.
• update_ib_cf - обновление информационной базы собранным файлом cf.
• update_ib_cf_xml - обновление информационной базы из файловой выгрузки xml конфигурации.
• update_ib_cfe - обновление информационной базы собранными файлами cfe.
• update_ib_cfe_xml - обновление информационной базы из файловой выгрузки xml расширений.
• update_ib_patch - частичное обновление информационной базы файлами из каталога с файлами полностью или частично снятых с поддержки объектов.

Проверка информационной базы

• check_ib_cf - тестирование конфигурации информационной базы.
• check_ib_cfe - тестирование расширений информационной базы.
• check_ib - тестирование и исправление (ТИС) информационной базы

Получение статусов конфигурации из информационной базы

• get_ib_configdumpinfo - получение файла bin/.1ccicd/ConfigDumpInfo.xml из информационной базы, где идет разработка, для ускоренной выгрузки в файлы xml измененной конфигурации.
• get_ib_status - получение состояния конфигурации относительно раннее полученного файла bin/.1ccicd/ConfigDumpInfo.xml из информационной базы.

Получение файлов конфигурации из информационной базы

• get_ib_xml - получение файловой выгрузки из конфигурации информационной базы, где идет разработка.
• get_ib_xml_cfe - получение файловой выгрузки из расширений информационной базы, где идет разработка.

Работа с хранилищем 1С и с Git-хранилищем

• git_sync_ib_xml - синхронизация хранилища 1С и git-хранилища.
• git_commit_ib_xml - выгрузка и фиксация изменений из конфигурации информационной базы в git-хранилище.

Конвертация/исправление служебных файлов

• new_bin - конвертация файла ParentConfigurations.bin в формат, пригодный для хранения и работы с ним в git-хранилище.
• repair_bin - удаление из файла ParentConfigurations.bin битых идентификаторов метаданных.
• new_configdumpinfo - конвертация файла ConfigDumpInfo.xml в формат, пригодный для хранения и работы с ним в git-хранилище.

Требуемая структура репозитория проекта

Для корректной работы скриптов проект должен иметь следующую структуру каталогов:

project
  |- bin
    |- project_user_prop.json
    |- Конфигурация.cf
    |- Расширения.cfe
    |- .1ccicd
  |- scripts
    |- 1c_cicd
  |- src
    |- cf
    |- cfe
      |- ИмяРасширения1
      |- ИмяРасширения2
  |- project_config.json
  |- .gitignore

• scripts - каталог, где хранятся скрипты.

• src/cf - каталог с файловой выгрузкой основной конфигурации.

• src/cfe/* - каталоги с файловой выгрузкой расширений.

• bin - каталог с собранными файлами конфигураций cf, cfe, patch.

• bin/.1ccicd - каталог с кэшем для быстрой сборки cfe, также здесь содержится актуальный для ИБ разработки ConfigDumpInfo.xml.

• project_config.json - файл с общими настройками проекта.

  {
    "PLATFORM" : { 
      "VERSION" : "8.3.27",
      "CHECK": [
        "ThinClient",
        "WebClient",
        "Server",
        "ExternalConnection"
      ]
    },
    "PROJECT" : {
      "CONTEXT" : {
        "BIN" : "bin"
      },
      "CONFIGS" : {
        "1Cv8" : {
          "PATH" : "src\\cf",
          "REPO" : {
            "USE" : false,
            "LAST_VERSION" : ""
          }
        },
        "ИмяРасширения1" : {
          "PATH" : "src\\cfe\\ИмяРасширения1",
          "REPO" : {
            "USE" : false,
            "LAST_VERSION" : ""
          }
        },
        "ИмяРасширения2" : {
          "PATH" : "src\\cfe\\ИмяРасширения2",
          "REPO" : {
            "USE" : false,
            "LAST_VERSION" : ""
          }
        }
      }
    },
    "GIT" : {
      "USE" : false,
      "MAIN_BRANCH" : ""
    }
  }

  • PLATFORM - блок настроек платформы
    • VERSION - текущая версия платформы, на которой ведется разработка.
    • CHECK - обязательные режимы проверки конфигурации и расширений, принятые на проекте (полное перечисление режимов в файле oc_batch_mode.sbsl).
  • PROJECT - блок настроек проекта
    • CONTEXT - контекст выполнения проекта
      • BIN - путь к каталогу bin относительно корня репозитория проекта.
    • CONFIGS - блок настроек конфигураций, разрабатываемых в рамках проекта
      • Ключ - имя разрабатываемой конфигурации
        • для основной конфигурации всегда 1Cv8
        • для расширения - ИмяРасширения.
      • PATH - путь к каталогу с файловой выгрузкой xml конфигурации
        • "src\cf" - для основной конфигурации
        • "src\cfe\ИмяРасширения" - для расширения
      • REPO - блок настроек хранилища конфигурации 1С
        • USE - признак использования хранилища 1С на проекте
        • LAST_VERSION - последняя версия в истории хранилища конфигурации 1С
  • GIT - блок настройки работы с git-хранилищем
    • USE - признак использования операций git-хранилища при работе с проектом
    • MAIN_BRANCH - основная ветка git-хранилища

• project_user_prop.json - файл с пользовательскими настройками проекта.

  {
    "PLATFORM" : {
      "CHECK" : [ ],
      "UPD_OPT" : [
        "Dynamic-",
        "WarningsAsErrors",
        "Server",
        "v1",
        "SessionTerminate force",
        "dynamic=disable",
        "session-terminate=force"
      ],
      "CHECK_REP" : [
        "Rebuild"
      ],
      "PATH_1C" : "D:\\Program Files\\1cv8\\"
    },
    "PROJECT" : {
      "CONTEXT" : {
        "EXEC_MODE" : 2,
        "CFE_EXEC_MODE" : 2,
        "CFE_BUILD_MODE" : 2,
        "TEMP" : "bin\\.1ccicd"
      },
      "CONFIGS" : {
        "1Cv8" : {
          "HASH" : "af55faeb510447b4ad77b042404173b0",
          "REPO" : {
            "PATH" : "",
            "LOGIN" : "",
            "PASSWD" : ""
          }
        },
        "ИмяРасширения1" : {
          "HASH" : "ce4d60180441af22682ead36faf17f67",
          "REPO" : {
            "PATH" : "",
            "LOGIN" : "",
            "PASSWD" : ""
          }
        },
        "ИмяРасширения2" : {
          "HASH" : "76f7442b318c53a0fbbd293f5ef2c9bb",
          "REPO" : {
            "PATH" : "",
            "LOGIN" : "",
            "PASSWD" : ""
          }
        }
      }
    },
    "GIT" : {
      "PATH" : "",
      "LOCAL_PATH" : "",
      "LOGIN" : "",
      "PASSWD" : "",
      "KEY" : ""
    },
    "IBS" : {
      "DEVELOP" : {
        "CONNECTION_STRING" : "Srvr=\"develop\";Ref=\"DO\";",
        "LOGIN" : "Администратор",
        "PASSWD" : "Пароль",
        "INPUT_PASS" : false,
        "PLATFORM_VERSION" : "",
        "REPOS" : { }
      },
      "TEST" : {
        "CONNECTION_STRING" : "Srvr=\"test\";Ref=\"DO\";",
        "LOGIN" : "Администратор",
        "PASSWD" : "Пароль",
        "INPUT_PASS" : false,
        "PLATFORM_VERSION" : "",
        "REPOS" : {
          "1Cv8" : {
            "PATH" : "",
            "LOGIN" : "Администратор<admin@admin.ru>",
            "PASSWD" : ""
          },
          "ИмяРасширения1" : {
            "PATH" : "",
            "LOGIN" : "Администратор<admin@admin.ru>",
            "PASSWD" : ""
          },
          "ИмяРасширения2" : {
            "PATH" : "",
            "LOGIN" : "Администратор<admin@admin.ru>"
            "PASSWD" : ""
          }
        }
      }
    }
  }

  • PLATFORM - блок настроек платформы

    • CHECK - пользовательские режимы проверки конфигурации и расширений (полное перечисление режимов в файле oc_batch_mode.sbsl).
    • UPD_OPT - пользовательские режимы обновления ИБ, ключи обновления берутся из документации Приложение 7. Параметры командной строки запуска «1С:Предприятия» :: Руководство администратора :: 1С:Предприятие 8.3.27. Документация.
    • CHECK_REP - режимы ТИС проверки ИБ. Значения ключей берутся из документации Приложение 7. Параметры командной строки запуска «1С:Предприятия» :: Руководство администратора :: 1С:Предприятие 8.3.27. Документация (На данный момент не реализовано указания списка обрабатываемых таблиц для LogIntegrity, LogAndRefsIntegrity и BinaryDataStorageIntegrity).
    • PATH_1C - альтернативный путь установки платформы, например, D:\Program Files\1cv8

  • PROJECT - блок настроек проекта

    • CONTEXT - контекст выполнения проекта
      • EXEC_MODE - режим исполнения для сборки файла конфигурации cf: 1 - пакетный режим, 2 - автономный сервер ibcmd. Рекомендуется использовать 2. (Автономный сервер в 10 раз быстрее собирает конфигурацию)
      • CFE_EXEC_MODE - режим исполнения для сборки файлов расширения cfe: 1 - пакетный режим, 2 - автономный сервер ibcmd. Рекомендуется использовать 1. (Из-за текущих ошибок работы автономного сервера с расширениями)
      • CFE_BUILD_MODE - режим сборки расширений: 1 - сборка с помощью пустой конфигурации, 2 - сборка с помощью не пустой конфигурации. Рекомендуется использовать 2. (Из-за последних ограничений платформы 1С, сборка cfe через пустую конфигурацию очищает ряд событий. Конфигурация для сборки находится в каталоге bin/.1ccicd)
      • TEMP - bin/.1ccicd- каталог с кэшем для быстрой сборки cfe, также здесь содержится актуальный для ИБ разработки ConfigDumpInfo.xml.
    • CONFIGS - блок настроек конфигураций, разрабатываемых в рамках проекта
      • Ключ - имя разрабатываемой конфигурации
        • для основной конфигурации всегда 1Cv8
        • для расширения - ИмяРасширения.
      • HASH - Рассчитывается автоматически - хеши каталогов файловых выгрузок, нужны для того, чтобы сборка файлов проекта выполнялась только в случае изменении в файловой выгрузки относительно предыдущей сборки
      • REPO - блок настроек хранилища конфигурации 1С для временной информационной базы
        • PATH - путь к хранилищу 1С на проекте для временной информационной базы (можно указать файловый путь, tcp, http/https)
        • LOGIN - логин для обращения к хранилищу 1С для временной информационной базы (например, ci_bot, во избежание конфликтов, рекомендуется для каждого пользователя в хранилище добавлять бота, который будет синхронизировать git и хранилище 1C)
        • PASSWD - пароль для обращения к хранилищу 1С для временной информационной базы

  • GIT - (экспериментальный блок) - блок настройки работы с git-хранилищем.

    [!IMPORTANT] Рекомендуется располагать скрипты в репозитории проекта, и для доступа к внешнему хранилищу использовать ssh протокол, тогда настройки можно не заполнять.

    • PATH - (по умолчанию используется автоопределение средствами git) - путь к внешнему git-хранилищу.
    • LOCAL_PATH - путь к локальному хранилищу гит, если скрипты находятся вне репозитория проекта.
    • LOGIN - (по умолчанию используется автоопределение средствами git) - логин доступа к внешнему git-хранилищу.
    • PASSWD - (по умолчанию используется автоопределение средствами git) - пароль доступа к внешнему git-хранилищу.
    • KEY - (по умолчанию используется автоопределение средствами git) - путь к закрытому ключу доступа к внешнему git-хранилищу.

  • IBS - блок настроек к информационным базам.

    [!IMPORTANT] В блоке можно указывать несколько информационных баз. В случае нескольких настроек, в начале работы скрипта будет выходит диалоговое окно выбора ИБ. Можно ввести через запятую ключ как одной, так и нескольких ИБ.

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

    • IB_CONNECTION_STRING - строка соединения до конфигурации, в которой ведется разработка. (Соединение с конфигурацией выполняется в режимах get_ib*, update_ib*, check_ib*, git*ib_xml)

    • IB_LOGIN - логин конфигурации, в которой ведется разработка

    • IB_PASSWD - пароль конфигурации, в которой ведется разработка

    • INPUT_PASS - в значении true, запрашивает пароль доступа к первой ИБ, если пароль не указан явно в настройках.

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

    • REPOS - блок настроек доступа к хранилищам конфигураций 1С

      [!IMPORTANT] По умолчанию блок не заполнен. Если разработка с использованием хранилища 1С не ведется, то его можно оставить пустым.

      • Ключ - имя разрабатываемой конфигурации, которая подключена к хранилищу 1С.

        • для основной конфигурации всегда 1Cv8
        • для расширения - ИмяРасширения.

      • PATH - (если не заполнен, берется из настроек конфигурации для временной информационной базы) - путь к хранилищу 1С на проекте для информационной базы (можно указать файловый путь, tcp, http/https)

        • LOGIN - (формат, ИмяПользователя<ПочтаПользователя>) - логин доступа к хранилищу, привязанного к указанной информационной базы. Здесь указывается логин, под которым идет захват и помещение объектов в хранилище 1С.

          [!IMPORTANT] Логин должен отличаться от логина из настроек конфигурации для подключения хранилища 1С к временной информационной базы.

          ---

          [!IMPORTANT] Для корректной интеграции хранилища 1С и git, необходимо создавать пользователя в хранилище 1С по следующему формату: ИмяПользователяОблачногоGit<ПочтаПользователяОблачногоGi>.

        • PASSWD - пароль доступа к хранилищу, привязанного к указанной информационной базы.

• .gitignore - файл с описанием каталогов, которые не должны учитываться в истории git. В данном случае в нем должен содержаться каталог bin.

  /bin

Инициализация репозитория проекта

Для инициализации репозитории проекта для работы со скриптами необходимо выполнить несколько шагов:

1. Выбрать место расположение скриптов, например, в каталоге scripts/1c_cicd. Скрипты можно как просто скопировать с родительского репозитория, так и расположить в качестве подмодуля репозитория git.

2. Создать файл инициализации и расположить его в каталоге bin.

   • Для Windows файл init.bat со следующим кодом

   chcp 65001
   executor "..\scripts\1c_cicd\main.sbsl" -Режимы init -ПутьДоРепозитория "..\\" -Пауза 1

   • Для Linux файл init.sh со следующим кодом

   #!/usr/bin/bash
   executor "..\scripts\1c_cicd\main.sbsl" -Режимы init -ПутьДоРепозитория "..\\" -Пауза 1

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

   1. Файл настроек проекта ./project_config.json

   2. Файл пользовательских настроек bin/project_user_prop.json

   3. Пакетные файлы для запуски скриптов в разных режимах bin/*

      1. Для Windows файлы создадутся в кодировке 866. Просматривать и редактировать данные файлы удобно в редакторе Notepad++.

      2. Для Linux файлы создаются в кодировке UTF-8.

   4. На основе описанной структуры проекта создается файл .git/hooks/precommit с режимами обслуживания репозитория перед фиксацией изменений

      #!/bin/sh
      executor "scripts/1c_cicd/main.sbsl" new_bin "." 0
      executor "scripts/1c_cicd/main.sbsl" new_configdumpinfo "." 0
      git add "src/cf/Ext/ParentConfigurations.bin" "src/cf/ConfigDumpInfo.xml" "src/cfe/*/ConfigDumpInfo.xml"
      executor "scripts/1c_cicd/main.sbsl" build_cfe "." 0

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

      [!NOTE] Данные настройки можно убрать из .git/hooks/precommit

Особенности использования файла ConfigDumpInfo.xml

В файловой выгрузке конфигурации содержится очень важный файл ConfigDumpInfo.xml.

<?xml version="1.0" encoding="UTF-8"?>
<ConfigDumpInfo xmlns="http://v8.1c.ru/8.3/xcf/dumpinfo" xmlns:xen="http://v8.1c.ru/8.3/xcf/enums" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" format="Hierarchical" version="2.15">
  <ConfigVersions>
    <Metadata name="AccumulationRegister.КоличествоДействийЗадач" id="fb076a86-f98a-4262-aae6-9620b66ffe56" configVersion="7968057765e97c4b85bbe9cdba2d6add00000000">
      <Metadata name="AccumulationRegister.КоличествоДействийЗадач.Resource.ОжидающихПроверки" id="12ee901e-40ef-403d-97ac-6d417f7f89bc"/>
      <Metadata name="AccumulationRegister.КоличествоДействийЗадач.Resource.Просроченных" id="19149630-16cb-4810-bb20-274f0f690254"/>
****
    </Metadata>
    <Metadata name="AccumulationRegister.КоличествоДействийЗадач.ManagerModule" id="fb076a86-f98a-4262-aae6-9620b66ffe56.2" configVersion="35499d4fcdad694c989da066e77b447600000000"/>
    <Metadata name="AccumulationRegister.КоличествоДействийЗадач.RecordSetModule" id="fb076a86-f98a-4262-aae6-9620b66ffe56.1" configVersion="4ad30263ad581f4daaae5dd125fa9c2c00000000"/>
***

• В нем содержится иерархия объектов метаданных. Данной информации нет в файле Configuration.xml.

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

• Также в нем содержится атрибут configVersion, которые помогает конфигурации выгрузить только измененные объекты относительно предыдущей выгрузки.

• Также, после удалении объектов в конфигурации, при файловой выгрузке платформа по файлу ConfigDumpInfo.xml понимает, какие файлы нужно удалить в каталоге.

  [!WARNING] Без файла ConfigDumpInfo.xml файлы удаленных метаданных при выгрузки конфигурации в xml не удаляются.

• Для эффективной работы используются несколько файлов ConfigDumpInfo.xml:

  • В репозитории проекта адаптированный файл
  • В каталоге bin\\.1ccicd файлы с версиями объектов различных конфигураций и расширений подключенных информационных баз.

Для того, чтобы файл ConfigDumpInfo.xml в репозитории проекта не конфликтовал в ветками других разработчиков из-за configVersion, данный атрибут обнуляется с помощью команды скриптов new_configdumpinfo.

configVersion="0000000000000000000000000000000000000000

[!IMPORTANT] Необходимо убедиться, что в git precommit прописан режим new_configdumpinfo (см. Инициализация репозитория проекта)

Ускоренная выгрузка конфигурации в файлы

Для ускоренной выгрузки конфигурации в файлы необходимо перед началом разработки актуализировать bin/.1ccicd/ConfigDumpInfo_*.xml. Канонический процесс разработки с использованием режима актуализации ConfigDumpInfo.xml выглядит следующим образом:

1. Перейти на ветку мастер.
2. Создать новую ветку разработки по задаче разработки.
3. Обновить ИБ разработки с помощью update_ib_patch в том случае, если у вас конфигурация находится на частичной поддержке, или с помощью update_ib_cf, если у вас конфигурация вообще снята с поддержки.
4. Во время обновления ИБ будет получен файл bin/.1ccicd/ConfigDumpInfo_*.xml с последними версиями конфигурации.
5. Также, можно актуализировать файл ConfigDumpInfo.xml с помощью командыget_ib_configdumpinfo.
6. Зайти в конфигуратор, провести разработку.
7. Получить файлы конфигурации с помощью команды get_ib_xml. bin/.1ccicd/ConfigDumpInfo_*.xml обновится новыми версиями
8. Зафиксировать изменения.
9. Те же самые шаги можно выполнить и для расширений с помощью команд update_ib_cfe, get_ib_xml_cfe.

[!WARNING] Ускоренная выгрузка отключается платформой в случае удаления или переименования объектов метаданных, вместо нее включается режим полной выгрузки.

Процесс разработки с использованием хранилища 1С

1. В хранилище необходимо 1С создать 2х пользователей:

   • Пользователь, под которым разработчик будет работать в конфигурации.
   • Пользователь, под которым будет подсоединяться скрипт.
   • Оба пользователя должны в своем имени содержать адрес электронной почты "ИмяПользователя<адрес@почты.ru>", для корректной синхронизации с git хранилищем.

2. В файле project_config.json задать настройки работы с хранилищем:

   • Для конфигурации и каждого расширения задать признак использования хранилища.

   "REPO" : {
      "LAST_VERSION" : "",
      "USE" : true
    }

   • Задать признак использования git хранилища.

   "GIT" : {
      "MAIN_BRANCH" : "master",
      "USE" : true
   }

3. Выполнить в файле project_user_prop.json задать настройки работы с хранилищем:

   • Задать логин пароль для доступа к хранилищу 1С для скрипта.

   "REPO" : {
      "PATH" : "",
      "PASSWD" : "",
      "LOGIN" : ""
    }

   • Если нужно, задать логин пароль для доступа к хранилищу git.

   "GIT" : {
      "PATH" : "",
      "PASSWD" : "",
      "LOCAL_PATH" : "",
      "LOGIN" : "",
      "KEY" : ""
    }

4. Проверит, что git хранилище синхронизировано с внешним хранилищем.

5. Выполнить синхронизацию git_sync_ib_xml в рамках которой все версии хранилища 1С будут переданы в хранилище git в ветку, которая указана в настройке в файле project_config.json.

6. Открыть конфигуратор, провести разработку, не помещая изменения в хранилище 1С.

7. Для проверки в sonarqube до помещения изменений в хранилище в 1С необходимо выйти из конфигурации и выполнить команду git_commit_ib_xml:

   • В данном режиме необходимо ввести имя существующей ветки, или ветка будет создана с автоматическим именем.
   • После чего будет выполнена синхронизация по алгоритму git_commit_ib_xml.
   • Потом для созданной ветки выгрузится информация, которая требует проверки sonarqube.
   • Ветка будет отправлена во внешнее git хранилище.
   • Необходимо зайти в сервис внешнего git хранилища, например, gitlab и создать запрос на слияние относительно главной ветки, и созданной ветки.
     • Для автоматического создания запроса на слияние в Gitlab можно использовать docker контейнер gitlab-auto-mr
     • Для автоматического создания MR для веток с именем CodeReview* можно использовать файл .gitlab-ci
   • По созданному запросу на слияние запустится статистическая проверка sonarqube.