Получить из Git последнюю версию проекта из ветки develop и обновить им тестовую базу TEST-SERV\Proto. При этом предполагаем, что в базе могут быть пользователи, работу которых нужно завершить. Таким образом все действия в простейшем варианте можно разделить на:

Установка блокировки работы пользователей в базе TEST-SERV\Proto и ожидание завершения работы.

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

export DISPLAY=:99; /opt/1cv8/x86_64/8.3.21.1644/1cv8c ENTERPRISE /S TEST-SERV\\Proto /N UserName / P Password /UC UpdateDB /С "ЗавершитьРаботуПользователей, , , Сообщение=Блокировка установлена по причине обновления информационной базы, КодРазрешения=UpdateDB, ОжиданиеМин=2"

где UpdateDB - код разблокировки, 8.3.21.1644 каталог версии 1С предприятия. Предполагается, что прикладное решение использует БСП версии не ниже 3.1.5. И ранее интерактивно была хоть раз запущена вручную блокировка работы пользователей с указанием варианта COM или RAS. Для исполнения команды нужен виртуальный или реальный GUI команда export DISPLAY=:99; перенаправляет вывод на виртуальный дисплей Xvfb.

Получение из Git в папке проекта EDT последней версии требуемой ветки

/home/user/git/GreatProject$git checkout develop
/home/user/git/GreatProject$git pull

Это лишь один из вариантов, предполагающий, что текущий каталог: /home/user/git/GreatProject$ - это корневой каталог проекта git, характерный признак корневого каталога проекта Git - наличие подкаталога .git

Преобразование файлов проекта EDT в формат файлов конфигурации 1С XML

/home/user/git/GreatProject$ring edt workspace export --project MainPrj --workspace-location /tmp/ws --configuration-files /tmp/conf

Где MainPrj - папка, содержащая проект EDT (ключевые признаки каталога проекта вложенные каталоги .project, src, DT-INF) внутри проекта Git, /tmp/conf - каталог в который утилита разместит результирующие XML файлы конфигурации 1С.

Загрузка новой конфигурации в тестовую базу

/opt/1cv8/x86_64/8.3.21.1644/ibcmd.exe infobase config import /tmp/conf --dbms=PostgreSQL --db-server=TEST-SRV --db-name=Proto --db-user=postgres --db-pwd=PG_PWD --user=UserName --password=Password
/opt/1cv8/x86_64/8.3.21.1644/ibcmd.exe infobase config apply --force --dbms=PostgreSQL --db-server=TEST-SRV --db-name=Proto --db-user=postgres --db-pwd=PG_PWD --user=UserName --password=Password

Где PG_PWD - пароль пользователя postgres, UserName и Password пароли пользователя с административными привилегиями в ИБ.

Снятие блокировки пользователей

export DISPLAY=:99; /opt/1cv8/x86_64/8.3.21.1644/1cv8c ENTERPRISE /S TEST-SERV\\Proto /N UserName / P Password /UC UpdateDB /С "РазрешитьРаботуПользователей"

Некоторые задачи из этого списка можно исполнять параллельно, тем самым сэкономить время сборки, например пока устанавливается блокировка в п.1 Можно смело исполнять п. 2,3 но к моменту загрузки новых файлов в конфигурацию в п 4. п.1 должен уже закончится.

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

для обновления тестовых и эталонных ИБ использовать CFU. Поэтому в отличии от примера в предыдущего раздела полученные на 3м шаге XML 1C должны загрузиться в новую пустую файловую базу (уже практически доказано, что файловая база собирается быстрее всего). Из которой нужно будет сделать файл поставки относительно первоначальной конфигурации. Для этого конфигурации всех тестовых баз всегда держим "на замке", в таком случае, конфигурацию можно выгрузить и сохранить как основу, для создания CFU, т.е. вам не нужно хранить предыдущую версию CF, которой создавалась ИБ. Таким образом, сначала из XML собирается абсолютно пустая файловая база, из которой потом создаются файлы поставки: CFU, а в качестве базового релиза подставляется та самая предыдущая конфигурация, которую нужно отдельно собрать.