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

#1

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

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

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

#2

Добрый день.

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

2 Симпатий
#3

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

#4

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

#5

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

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

#6

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

#7

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

packman help set-database

Не пробовал?

#8

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

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

#9

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

#10

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

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

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

#11

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

#12

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png1029×479 21.8 KB

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

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

choco install msgit
git lfs install

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

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png706×190 2.47 KB

1 Симпатия
#13

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

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

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

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

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

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

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

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

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

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

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

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

#17

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

#18

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

#19

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

#20

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