Доставка изменений на сервера заказчика

Миграции

Миграция — это процесс управления и обновления структуры базы данных (БД) в приложении. Они позволяют разработчикам создавать, изменять и удалять таблицы, столбцы и другие элементы БД без необходимости выполнять SQL-запросы вручную.

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

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

При работе с миграциями рекомендуется придерживаться следующих правил:

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

Рекомендуемые директории для миграций:

1. Миграции (cfg) — эта директория покрывает первое правило, упомянутое выше. Миграции в этом разделе должны запускаться автоматически из CI/CD.
2. Миграции (dev) — эта директория покрывает второе правило, упомянутое выше. Миграции в этом разделе предназначены только для девелоперских стендов или стендов разработчиков и должны запускаться вручную.
3. Миграции (dataloader) — эта директория покрывает третье правило, упомянутое выше. Миграции из этого раздела можно запускать как из CI/CD, так и вручную, но не должны перезапускаться.

GitLab, CI/CD

Чаще всего при разработке для закрытого контура разработчиками используется собственный сервер GitLab для хранения репозиториев, и Gitlab CI для доставки изменений на серверы приложений. Runner в основном использует Docker executor. При работе pipeline подключение к серверу приложений осуществляется по ssh под пользователем bitrix, затем вытягиваются изменения из репозитория используя токен задания (CI_JOB_TOKEN). При этом также возможен запуск дополнительных действий, например, запуск миграций.

Хорошей практикой, является размещение кода пайплайна не в самом проекте (в файле .gitlab-ci.yml) а в другом проекте, а в исходном проекте указывается только include проекта с pipeline:

include:
- project: 'devops/gitlab-ci'
    ref: main
    file: '/projects/projectname/gitlab-ci.yml'

Тем самым мы добиваемся одинаковых настроек в различных ветках. Есть только одно ограничение, которое накладывает GitLab при такой настройке: если после запуска pipeline он завершился, например, с ошибкой и необходимо внести изменения в код пайплайна, повторный запуск (используя кнопку ») не будет задействовать измененное содержимое т.к. GitLab кеширует содержимое, при подключении удаленного репозитория. При такой ситуации необходимо запустить пайплайн вручную, задав, при необходимости, нужные переменные окружения т.е. сымитировав либо merge request или push при необходимости (переменная CI_PIPELINE_SOURCE со значениями merge_request_event или push).

Так как чаще всего ограничения, которые накладывает на нас клиент, не позволяют нам использовать runner, расположенный за пределами корпоративной сети передачи данных (КСПД), то при наличии технической возможности (есть либо прямой доступ по https к нашему серверу GitLab либо доступ через http/https прокси) runner устанавливается на отдельный сервер (виртуальную машину) в контуре клиента.

Также есть ситуации, когда есть требование клиента либо нет технической возможности организовать подключение раннера к нашему серверу GitLab, в таком случае сервер GitLab и раннер разворачивается в контуре клиента. В эту же группу можно отнести ситуации, когда клиент имеет собственную инфраструктуру для работы с кодом (свой сервер GitLab, Azure DevOps, BitBucket, Stash)

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

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

К таким инструментам, например, относятся:

• git archive позволяет создавать любые комбинации файлов репозитория для его упаковки в архив и последующей отправки этого архива по электронной почте или переносом через физический носитель данных. При этом формат получившего архива также гибко настраивается.
• git patch. Менее распространен. Хранит в себе не только код, который необходимо доставить, но и историю коммитов репозитория. В отличии от git archive предполагает установку git на сервере, на который необходимо доставить изменения.

Вариант 2

Если настройки безопасности не позволяют переносить файлы, но позволяют переносить текст, можно использовать следующий метод: c помощью админки Битрикса архивируем раздел/файлы.

Далее с помощью командной PHP строки кодируем содержимое файла архива и выводим строку:

print_r(base64_encode(file_get_contents($file)));

Копируем кодированную строку и сохраняем ее в файл на портале, на который переносим архив. /upload/perenos.txt

С помощью командной PHP строку выполняем обратную операцию:

file_put_contents($_SERVER['DOCUMENT_ROOT'].$file_decode, base64_decode(file_get_contents($file)));

Получаем архив раздела на портале.

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