Введение

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

На infostart’е существует множество публикаций,  о различных инструментах и методиках (gitlab-ci, xUnitFor1C, deployka и другие),  которые позволяют построить полный цикл от разработки до развертывания программных решений на платформе 1С:Предприятие. Однако в реальной жизни, достаточно часто встречаются и менее масштабные задачи, такие как создание, обновление и учет различных тестовых информационных баз (Перезаливатор), автоматизации которых c использованием конфигурации АИТП (проект на GitHub) и посвящен настоящий демонстрационный пример.

Системные требования

Версия конфигурации АИТП не ниже 0.4.13.67

Версия платформы 1С:Предприятие не ниже 8.3.10.2252

Операционная система – Linux.

Начальные и граничные условия

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

Также предполагается, что в качестве сервера 1С:Предприятие используется x32 версия сервера, исполняемые файлы которого расположены в папке /opt/1C/v8.3/i386/.

Предполагается, что на каждом главном сервере кластеров 1С:Предприятие развернута служба ras, которая настроена для запуска в качестве демона.

Предполагается, что в качестве пользователя, для доступа к СУБД используется стандартный пользователь postgres, для которого настроена проверка по паролю для внешних подключений и разрешены подключения без пароля для локальных подключений.

Цели автоматизации

Учет информационных баз

При интенсивной работе, разработчики могут генерировать достаточно большое количество различных тестовых баз, которые могут использоваться для проверки различных гипотез, оценки каких-то сторонних конфигураций etc. Иногда разработчики забывают их удалять, что приводит (особенно после увольнения сотрудника) к возникновению большого количества “зависших” информационных баз, о назначении которых никому ничего не известно.

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

Контракторы и консультанты

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

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

Программисты

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

Процессы и роли

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

Соответственно матрица ролей/процессов будет иметь нижеследующий вид:

Вспомогательные объекты конфигурации

Роли

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

Рисунок 1. Список ролей.