Тестовое окружение сборочной линии: файловая база или серверная?


#1

Возможно холиварный вопрос, но интересно мнение сообщества - кто и как думает:
Формирование тестового окружения через pipeline можно воспользоваться 2-мя вариантами:
Файловая база и серверная.

  1. файловая база
    Если использовать файловую базу, то нам необходимо предварительно загрузить в нее шаблонный dt файл, затем уже накатить исходники из хранилища. Без шаблонного dt, мы упираемся в проблему начальной инициализации БД и зачастую не возможности корректно отработать дымовым и функциональным тестам.
    Плюсы:
  • Окружение создается каждый раз новое - все везем из репо
  • В некоторых случаях экономия серверной лицензии
    Минусы
  • Загрузка шаблонного dt в файловую базу, для больших конфигураций может занимать очень много времени
  1. Серверный вариант
    База заранее создается для проведения тестов, и возможно ежедневное/по требованию восстановление из шаблонного бейкапа средствами sql.
    Плюсы:
  • Для больших баз этот вариант быстрее
  • ?
    Минусы:
  • наличие серверной лицензия на 1С
  • окружение не формируется сборочной линией

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


#2

Добрый день.

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


#3

Используем оба варианта. Для разворачивания файловых баз используем копирование/анстэш предварительно сохраненного файла 1cd.
На части проектов база создается с нуля, накатывается хранилище, потом сценарием первичной инициализации заполняются начальные данные. затем стэш 1cd и раскидывание файла по параллельным джобам. получается довольно шустро и универсально.


#4

Используем клиент-сервер. Потому что как на проде, как уже выше сказано.


#5

раскидывание файла по параллельным джобам

Интересно. А в чем отличие джоб? Дым отдельно, функциональные отдельно и.т.д. ? так что ли?


#6

Тоже используем серверные (как на проде), на файловых можно, например, пропустить передачу мутабельных…


#7

Можно же собирать поставку прям из тестовой серверной базы, (естественно после прогона всего что нужно), подключив ее к пакману. ИМХО, будет быстрее.

packman help set-database

Не пробовал?


#8

вот тут не совсем согласен.

@ZhdanovR ты говоришь про наполнение начальными тестовыми данными или необходимости выполнения операции штатного обновления на новую версию или про что-то еще ?


#9

формирование начальных данных.


#10

Контур разделен

  • билды собираются на тестовй файловой базе, сохраняются артефакты
  • если тест не релиза, то на той же тестовой базе выпоняются тесты
  • если тест релиза, то артефакты накатываются на стенд и тестируются

Схему упростил для понимания, ибо там еще есть шаги пре/пост процессинга исходников


#11

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


#12

начальная база хранится в GIT репозитории - так удобней локально/на агенте разворачивать

требуется подключение GIT LFS на агентах - то есть

choco install msgit
git lfs install

После чего базюка с данными живет в GIT


#13

Вот про это я и говорю всегда, но тут можно выкрутится по быстрому

  • мини-сервер 1С - 5 подключений хватает
  • база на сервере из dt файла - который также шаблонный в GIT LFS

#14

@ZhdanovR обрати внимание на специально уточнил “про наполнение начальными тестовыми данными”

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

#15

Валер - ты больше холивар класический откуда брать ее тестовую базу:

первая структура вопросов

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

вторая структура вопросов

  • развертывать в каталоге build/ib - то есть файловой и потом пристреливать
  • развертывать на сервере и потом очищать

#16

Я использую отдельное хранилище, в git не кладу.
Почему так: образа иногда обновляются и многие из них занимают очень много места, что тоже влияет на производительность получения изменений из репозиторий.

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

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


#17

Загрузку из макетов пробовал, но увы - долго + некоторые решения из пустой конфы не работают.
Так что я за первоначальный образ базы.


#18

И да, для тестов данные грузим из соответствующих макетов


#19

Угу. Плюс в последствии хотим функциональные тоже параллелить по группам сценариев.


#20

Начальное заполнение БД. Я помню, что тестовые данные должны приехать с самим тестом (Ибо так правильно.)