Рекомендации по поддержке базы Qlik под контролем версий

Создание хранилища на основе контейнера

Контейнер представляет собой отдельную сущность. Вы можете скопировать его, продублировать или переместить, и он продолжит работать, не требуя модификаций. Создание хранилища на основе контейнера – хорошая идея.
Используя GIT (технологии графических изображений), вы ограничиваете себя в проверке на входе/выходе целых хранилищ, не можете выбрать в нем определенные части. Если вам необходимо единое хранилище для всей программной среды, то вы будете вынуждены проверять всю программную среду Qlik при каждой проверке проекта. Я всегда рекомендую разделять программную среду на несколько хранилищ – по одному на каждый контейнер.
Если вы используете систему управления версиями, вам не понадобится полное хранилище, ведь довольно легко установить, какие части хранилища нужно проверять. Также вы можете использовать единое хранилище для каждого контейнера с использованием системы управления версиями. Примером является ситуация, когда различные разработчики ответственны за отдельные части и должны иметь доступ к разным приложениям. В соответствии с правами разработчика при настройке доступа к хранилищу, вы можете предотвратить несанкционированные или непредумышленные действия, выполненные посторонними разработчиками.
QDF открывает доступ разработчику или администратору для внесения изменений в порядок структуры контейнеров, не нарушая функциональность сценария. Может быть несколько причин для перемещения контейнера, но часто это связано с бизнес-изменениями. Расположение или выравнивание контейнеров не изменяет функциональности Qlik и не должно влиять на единое хранилище на основе контейнера. Разделение установки сохраняется, но в единой программной среде хранилища изменение структур контейнеров будет генерировать множество изменений в системе управления версиями.

Исключение файлов в формате qvw и файлов данных

Необходимо всегда исключать бинарные файлы и файлы данных. Я рассматриваю управление версиями как систему отслеживания изменений в исходном коде – это не является резервной системой.
Файл QlikView (qvw) содержит и макет, и сценарий, и сами данные. Он хранится в двоичном коде, что является неприемлемым для системы контроля версий – для определения изменений, которые были сделаны, в основном будет выполняться подтверждение всего приложения в хранилище базы данных при каждой фиксации. Приложение большого размера быстро увеличит размер вашей базы данных отслеживания версий, поэтому при каждом запуске файл qvw будет отличаться от предыдущего.

Всегда необходимо ставить файлы qvw и qvd в список игнорируемых файлов системы управления версиями.

Достаточно отследить папку PRJ вместо qvw. Папка PRJ содержит все макеты и информацию моделирования данных файла QlikView. В PRJ-папке файлы хранятся в виде считываемых XML-файлов. По мере исключения PRJ можно создать новую копию файла qvw, представляющего собой пустой файл для передачи данных.
Данные, загруженные в приложение, скорее всего, будут меняться с течением времени, в следствии этого, файлы данных никогда не должны включаться в системе управления версиями. Этот принцип справедлив как для файлов данных, которые импортированы (Excel, CSV и т.д.), так и для файлов данных, создаваемых приложением (QVD).

Держите основу структуры данных вне системы версий контроля.

Я считаю, что файлы структуры данных не должны быть частью разработанного исходного кода. Я рассматриваю их как файлы блока данных, куда я помещаю разработанный исходный код. Блок данных не находится под ответственностью разработчиков, и они не должен вносить никаких изменений в него. Если необходимо внести изменения, они должны быть глобальными для всех контейнеров, поэтому я считаю, что ответственность за это несет разработчик Qlik или администратор. Если каждый разработчик в организации, где это разрешено, внесет небольшие корректировки и изменения в файлы структуры данных, а затем руководство примет решение модернизировать структуру данных, для более позднего релиза потребуется перевыпустить файлы структуры данных.
Исключение из системы управления версиями qdf-файлы контейнера по умолчанию позволит разработчику точно понять, что является файлами конкретного исходного кода проекта, а что нет.

Отслеживайте развитие, но закрепите остальное

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

Сохраняйте разработки в среде разработки, сокращая все связи с системой управления версиями в тестовом режиме, среде приемки и производства

Есть конкретная причина того, почему с сервером QlikView вы должны избегать подключения тестового режима, среды приемки и производства при выборе системы управления версиями. Ранее я объяснял, почему qvw-файлы должны быть исключены из контроля версий. Настольный клиент QlikView сначала будет рассматривать информацию о PRJ-папке при открытии qvw-файла QlikView. С другой стороны, сервер не будет рассматривать PRJ-папку в целом – только то, что было предварительно сохранено в qvw-файле. Если все изменения занесены в XML-файлы в PRJ-папке в потоке DTAP, сервер не распознает любых изменений, пока вы вручную не откроете и не сохраните qvw-файл настольного клиента. Чтобы избежать повторения этой задачи во всей программной среде, необходимо всегда подготавливать свои разработанные qvw-файлы и поддерживать их в потоке DTAP.
Также существует принцип, по которому все изменения должны находиться в среде разработки, никакие изменения не должны вноситься после того, как они будут введены в любую из других программных сред. Разделение связей с контролем версий в тестовом режиме, приемка и производство, помогут предотвратить случайные разработки, выполненные в данной среде.

Ограничения

Существуют ограничения в версии обработки лишь файлов PRJ-папки приложения в QlikView. Одно выбранное значение всегда является одним из примеров – это свойство теряется, когда файл QlikView разделяют на данные. Триггеры определенных действий являются еще одной особенностью, которая плохо обрабатывается Qlik вручную, когда дело доходит до контроля версий. В случае, если присутствуют важные характеристики, не забудьте размещать qvw-файл в одном и том же месте – я убедился, что размещенный qvw-файл не опустошается.


Найти решение у бизнес-партнера QlikTech (QlikView) в России.

Форум разработчиков QlikView и Qlik Sense. Получите ответы на все вопросы по QlikView и Qlik Sense!

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

64 queries in 0,418 seconds