Настройка автоматического деплоя 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Предлагаемые услуги
Показано 1 из 1 услугВсе 1626 услуг
Настройка автоматического деплоя 1С-Битрикс
Простая
~1 рабочий день
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1173
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Разработка веб-сайта для компании ФИКСПЕР
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    745
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    976

Настройка автоматического деплоя 1С-Битрикс

Деплой изменений на боевой сервер вручную через FTP — это 15–30 минут ручной работы, риск пропустить файл, риск не очистить кеш. При трёх разработчиках в команде конфликты версий становятся постоянной проблемой. Автоматический деплой через CI/CD решает все три проблемы: изменения попадают на сервер через git push, кеш сбрасывается автоматически, история деплоев сохраняется.

Ограничения Битрикс для автодеплоя

Битрикс усложняет стандартный деплой несколькими особенностями:

Нельзя деплоить /bitrix/ — ядро обновляется только через встроенный механизм обновлений. Деплой кода ядра через git сломает лицензионный механизм и обновления.

upload/ не должен быть в git — это пользовательские файлы, они меняются в runtime.

OPcache нужно сбрасывать — без этого PHP продолжает выполнять старый байткод.

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

Структура репозитория

/ (корень репозитория)
├── local/
│   ├── components/    — кастомные компоненты
│   ├── modules/       — кастомные модули
│   ├── php_interface/ — init.php, events
│   └── templates/     — шаблоны сайта
├── bitrix/
│   ├── templates/     — только шаблоны (если не в local/)
│   └── php_interface/ — dbconn.php (БЕЗ паролей, через .env)
├── .gitignore
└── deploy/
    ├── post-deploy.sh
    └── migrate.php

В .gitignore:

/bitrix/modules/
/bitrix/components/
/bitrix/wizards/
/upload/
/bitrix/.settings.php
/bitrix/php_interface/dbconn.php

GitHub Actions для деплоя

.github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Deploy via SSH
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            set -e
            cd /var/www/bitrix

            # Сохранить текущий коммит для отката
            git log -1 --format="%H" > /tmp/previous_commit

            # Получить изменения
            git fetch origin main
            git checkout main
            git pull origin main

            # Обновить зависимости если изменился composer.lock
            if git diff HEAD~1 --name-only | grep -q composer.lock; then
              composer install --no-dev --optimize-autoloader
            fi

            # Сбросить OPcache
            php /var/www/bitrix/deploy/opcache_reset.php

            # Очистить кеш Битрикс
            php /var/www/bitrix/deploy/clear_cache.php

            echo "Deploy completed: $(git log -1 --format='%h %s')"

Скрипты деплоя

/var/www/bitrix/deploy/opcache_reset.php:

<?php
// Запускать только с localhost или через CLI
if (PHP_SAPI !== 'cli' && $_SERVER['REMOTE_ADDR'] !== '127.0.0.1') {
    exit(1);
}
opcache_reset();
echo "OPcache reset OK\n";

/var/www/bitrix/deploy/clear_cache.php:

<?php
$_SERVER['DOCUMENT_ROOT'] = '/var/www/bitrix';
define('NO_KEEP_STATISTIC', true);
define('NO_AGENT_CHECK', true);
define('DisableEventsCheck', true);
define('BX_WITH_ON_AFTER_EPILOG', false);

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

// Очистить весь управляемый кеш
$cache = \Bitrix\Main\Data\ManagedCache::getInstance();
$cache->cleanAll();

// Сбросить кеш опций модулей
$GLOBALS['USER_FIELD_MANAGER'] = false;

echo "Cache cleared OK\n";

Откат при ошибке

В deploy-скрипте после деплоя добавить проверку доступности сайта:

# Проверить что сайт отвечает 200
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://example.ru/)
if [ "$HTTP_CODE" != "200" ]; then
    echo "Deploy failed, rolling back..."
    PREVIOUS=$(cat /tmp/previous_commit)
    git checkout $PREVIOUS
    php /var/www/bitrix/deploy/opcache_reset.php
    echo "Rolled back to $PREVIOUS"
    exit 1
fi

Миграции базы данных

Для изменений схемы БД — скрипт-мигратор, который запускается при деплое:

// deploy/migrate.php
<?php
require_once '/var/www/bitrix/bitrix/modules/main/include/prolog_before.php';

$applied = \Bitrix\Main\Config\Option::get('custom', 'migrations_applied', '');
$applied = $applied ? explode(',', $applied) : [];

$migrationsDir = '/var/www/bitrix/local/migrations/';
$migrations = glob($migrationsDir . '*.php');
sort($migrations);

foreach ($migrations as $file) {
    $name = basename($file, '.php');
    if (!in_array($name, $applied)) {
        echo "Applying migration: $name\n";
        require_once $file;
        $applied[] = $name;
    }
}

\Bitrix\Main\Config\Option::set('custom', 'migrations_applied', implode(',', $applied));
echo "Migrations done\n";

Миграции — файлы вида 2024_03_15_add_product_index.php с SQL и PHP-операциями в алфавитном порядке.