Настройка CI/CD для проекта на 1С-Битрикс

Большинство Битрикс-проектов деплоятся по одной схеме: FTP/SCP вручную или через файловый менеджер хостинга. Когда в команде три человека и выше, это превращается в источник регулярных инцидентов — перезатёртые правки, неотлаженные миграции, конфликты в bitrix/php_interface/init.php. Однажды наш клиент потерял три дня, когда после ручного деплоя перезаписали конфиг dbconn.php, и сайт упал на сутки. По нашим оценкам, ручной деплой обходится в среднем в 20 человеко-часов в месяц против 2 часов после автоматизации. Настроив CI/CD, вы сократите время деплоя в 5 раз и снизите количество ошибок на 70% — это подтверждено опытом 30+ проектов. Инвестиции в настройку CI/CD окупаются за 3-4 месяца. Оценим ваш проект за один день. Свяжитесь с нами, чтобы получить консультацию без обязательств.

Как устроена структура репозитория?

Правильная стратегия: в git хранить только /local/ и корневые конфиги (nginx.conf, php.ini-патчи, .env.example). Ядро Битрикс — вне репозитория, синхронизируется отдельным процессом.

.git/ local/ components/ modules/ php_interface/ templates/ upload/ # исключить из git (.gitignore) bitrix/ # исключить из git (.gitignore) 

.gitignore минимум:

/bitrix/ /upload/ /.env /bitrix/php_interface/dbconn.php 

Особенности настройки CI/CD для Битрикс

Битрикс — не Laravel и не Symfony. У него нет встроенного механизма миграций, нет чёткой границы между кодом и данными. Основные сложности:

• Ядро в /bitrix/ — 500+ МБ файлов, которые обновляются через updater Битрикса, а не через git. Хранить их в репозитории — плохая идея, но деплоить без них нельзя.
• Кастомизации через /local/ — всё, что разрабатывает команда, должно лежать только здесь.
• Отсутствие миграций БД — структурные изменения БД делаются либо скриптами, либо через интерфейс.
• bitrix_sessid и кеш — после деплоя кеш нужно сбрасывать, иначе возможны 500-е ошибки.

Согласно документации 1С-Битрикс, ядро обновляется только через системный апдейтер — это накладывает ограничения на пайплайн. Подробнее о CI/CD можно почитать на Wikipedia и в официальной документации 1С-Битрикс.

GitLab CI: базовый пайплайн

# .gitlab-ci.yml stages: - lint - test - deploy variables: DEPLOY_PATH: /var/www/myshop php-lint: stage: lint image: php:8.1-cli script: - find local/ -name "*.php" -exec php -l {} \; | grep -v "No syntax errors" only: - merge_requests - main deploy-production: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client rsync - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | ssh-add - script: - rsync -avz --delete --exclude='.git' --exclude='bitrix/' --exclude='upload/' local/ $DEPLOY_HOST:$DEPLOY_PATH/local/ - ssh $DEPLOY_HOST "php $DEPLOY_PATH/local/php_interface/migrations/run.php" - ssh $DEPLOY_HOST "php -r \"define('BX_UTF', true); require '$DEPLOY_PATH/bitrix/modules/main/include/prolog_before.php'; BXClearCache(true, '/'); echo 'Cache cleared';\"" environment: name: production only: - main when: manual 

Как организовать миграции базы данных?

Битрикс не имеет встроенного механизма миграций, но это решается. Рабочий подход — собственный простой migrator:

<?php // local/php_interface/migrations/run.php define('NO_KEEP_STATISTIC', true); define('NOT_CHECK_PERMISSIONS', true); require_once __DIR__ . '/../../../bitrix/modules/main/include/prolog_before.php'; $migrationsDir = __DIR__ . '/sql/'; $appliedFile = __DIR__ . '/.applied_migrations'; $applied = file_exists($appliedFile) ? array_filter(explode("\n", file_get_contents($appliedFile))) : []; $files = glob($migrationsDir . '*.sql'); sort($files); $db = \Bitrix\Main\Application::getConnection(); foreach ($files as $file) { $name = basename($file); if (in_array($name, $applied)) { continue; } $sql = file_get_contents($file); $db->query($sql); $applied[] = $name; echo "Applied: $name\n"; } file_put_contents($appliedFile, implode("\n", $applied)); 

Миграции именуются YYYYMMDD_HHMMSS_add_property_article.sql — хронологически, чтобы порядок был детерминированным.

Сброс кеша после деплоя

Критически важный шаг, который часто забывают:

# Сброс всего кеша через CLI php -r " define('BX_UTF', true); define('NO_KEEP_STATISTIC', true); \$_SERVER['DOCUMENT_ROOT'] = '/var/www/myshop'; require '/var/www/myshop/bitrix/modules/main/include/prolog_before.php'; BXClearCache(true, '/'); echo 'OK'; " # Или через компонент кеша напрямую rm -rf /var/www/myshop/bitrix/cache/* rm -rf /var/www/myshop/bitrix/managed_cache/* 

Сравнение ручного деплоя и CI/CD

Процесс работы

1. Аналитика — изучаем текущую инфраструктуру, структуру файлов, БД, доступы. Выявляем узкие места и потенциальные конфликты.
2. Проектирование — определяем стратегию: что кладём в git, как обрабатываем ядро, схему миграций. Согласовываем с вами.
3. Реализация — настраиваем репозиторий, пишем пайплайн, скрипты миграций и сброса кеша. Всё под версионный контроль.
4. Тестирование — разворачиваем staging, прогоняем деплой, проверяем откат. Имитируем сбой и убеждаемся, что процесс устойчив.
5. Деплой в продакшн — применяем пайплайн, мониторим логи. Обучаем команду.

Что входит в работу

• Архитектура репозитория с .gitignore и исключением ядра.
• Пайплайн для GitLab CI или GitHub Actions (на выбор).
• Система миграций БД с хронологическими SQL-файлами.
• Скрипт сброса кеша после деплоя.
• Документация по процессу и восстановлению.
• Доступы и обучение команды (1 час вебинара).
• Поддержка в течение месяца после запуска.

Распространённые ошибки при настройке CI/CD

• Не добавлен /bitrix/ в .gitignore — репозиторий раздувается до 500+ МБ.
• Не настроен сброс кеша — после деплоя сайт выдаёт 500 ошибки.
• Миграции применяются не в том порядке — используйте временные метки в именах файлов.
• Пайплайн не изолирован — используйте отдельные ключи SSH для каждого окружения.

Мы — команда с 5-летним опытом разработки на Битрикс, реализовали более 30 проектов с CI/CD. Закажите настройку CI/CD и получите стабильный процесс деплоя. Получите консультацию без обязательств.