CI/CD с использованием QP8.CMS

Для руководителей отделов разработки, ведущих разработчиков и DevOps-инженеров

Данная статья предназначена для руководителей отделов разработки, ведущих разработчиков и DevOps-инженеров. В статье рассматривается подход к организации процесса разработки, обновления и актуализации стендов при использовании QP8.CMS в организациях уровня enterprise.

Требования

После запуска сайта в продуктивной среде разработка, как правило, не прекращается: обновления кода и контента требуются на постоянной основе. Обычно для разработки создается три и более рабочих среды:

Development – для разработки;
Test – для тестирования и воспроизведения ошибок из продуктивной среды;
Production – продуктивная среда, доступ к которой часто отсутствует для разработчиков и тестировщиков.

В разных предприятиях могут быть организованы дополнительные промежуточные среды (Pred-production и др.). Изменения от разработчиков имеют направление Development -> Test -> Production. Эти изменения могут касаться как кода, так и структуры и метаданных в QP8.CMS.

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

Инструменты

QP8.CMS разработана по принципу «headless», что позволяет коду сайта или API быть независимым от самой CMS и обновляться стандартными средствами разработки и DevOps. Однако помимо кода важно также обновлять структуру данных и метаданные (например, справочники) в CMS.

В традиционной разработке для этого используются скрипты миграции. В QP8.CMS для таких задач создан механизм записи и воспроизведения действий пользователей. При изменении структуры разработчик включает режим записи своих действий в CMS, производит необходимые действия со структурой и метаданными через административный интерфейс, а затем выгружает файл с записанными действиями. Этот файл можно «проиграть» на другой среде как с помощью интерфейса, так и через утилиту, что значительно упрощает автоматизацию процесса. Более подробную информацию о записи и воспроизведении действий можно найти в соответствующей документации.

Процессы

Процесс обновления кода для стендов Test и Production проходит в стандартном порядке с одним исключением. Вместо скриптов миграции нужно будет выгружать файлы с записанными действиями из репозитория и «проигрывать» их для нужного стенда. Система обеспечивает защиту от повторного «проигрывания» файла. Утилиту можно запускать для списка файлов по заданному пути, что упрощает настройку CI/CD.

Что касается актуализации данных на стендах Test и Development, – здесь процесс обычно запускается каждую ночь и включает следующие шаги:

1. Создание бэкапа базы данных с Production.
2. Восстановление бэкапа на нужной среде (обычно Test и Development).
3. Выполнение SQL-скриптов для удаления «секретной» информации или обезличивания персональных данных.
4. Изменение настроек CMS для нужной среды с помощью SQL-скриптов.
5. Создание или разблокировка пользователей CMS для разработчиков и тестировщиков с соответствующим уровнем доступа с помощью SQL-скриптов.
6. «Проигрывание» файлов с записанными действиям (чтобы база данных была актуальной для тестирования и разработки).

Стоит отдельно рассмотреть ситуацию, когда необходимо совместно с новой версией кода опубликовать большое количество статей. В этом случае новая структура данных «проигрывается» на среде Production заранее, что не влияет на текущий код и предоставляет контент-редакторам достаточно времени для внесения необходимых изменений. При развертывании новой версии кода данные уже будут готовы к публикации.

Важно помнить

Поля можно удалять только через версию. Сначала поле удаляется из кода, затем версия кода публикуется в продуктивной среде, и только после этого со следующей версией можно записать действие по удалению этого поля.
Изменение типа поля и его .NET-маппинга невозможно. Такие изменения производятся через создание нового поля и удаление старого.
При «проигрывании» действий важно помнить, что ID созданных статей будут другими. При этом ID контентов и полей останутся такими же, как при записи.