Налаштування CI/CD для проекту на 1С-Бітрікс

Більшість Бітрікс-проектів деплояться за однією схемою: FTP/SCP вручну або через файловий менеджер хостингу. Коли в команді три особи і більше, це перетворюється на джерело регулярних інцидентів — перезатерті правки, невідлагоджені міграції, конфлікти в bitrix/php_interface/init.php. Одного разу наш клієнт втратив три дні, коли після ручного деплою перезаписали конфіг dbconn.php, і сайт упав на добу. За нашими оцінками, ручний деплой обходиться в середньому в 20 людино-годин на місяць проти 2 годин після автоматизації. Налаштувавши CI/CD, ви скоротите час деплою в 5 разів і знизите кількість помилок на 70% — це підтверджено досвідом 30+ проектів. Інвестиції в налаштування CI/CD окупаються за 3-4 місяці. Економія до $500 на місяць на ручних деплоях. Вартість налаштування від $1000. Оцінимо ваш проект за один день. Зв'яжіться з нами, щоб отримати консультацію без зобов'язань. Надаємо гарантію на налаштування CI/CD терміном 1 рік. Маємо сертифікацію 1С-Бітрікс та 5-річний досвід у DevOps для Бітрікс.

Як влаштована структура репозиторію?

Правильна стратегія: в 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 

Як організувати міграції бази даних?

Бітрікс не має вбудованого механізму міграцій, але це вирішується. Робочий підхід — власний простий мігратор:

<?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)); 

# Скидання всього кешу через 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/*