Налаштування автоматичного деплою 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Налаштування автоматичного деплою 1С-Бітрікс
Проста
~1 робочий день
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • 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
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Налаштування автоматичного розгортання 1С-Bitrix

Розгортання змін на боевий сервер вручну через FTP займає 15–30 хвилин роботи, існує ризик пропустити файл, ризик не очистити кеш. При трьох розробниках у команді конфлікти версій стають постійною проблемою. Автоматичне розгортання через CI/CD вирішує всі три проблеми: зміни потрапляють на сервер через git push, кеш очищується автоматично, історія розгортань зберігається.

Обмеження Bitrix для автоматичного розгортання

Bitrix ускладнює стандартне розгортання кількома особливостями:

Не можна розгортати /bitrix/ — ядро оновлюється тільки через вбудований механізм оновлень. Розгортання коду ядра через git зламає ліцензійний механізм та оновлення.

upload/ не повинен бути в git — це користувацькі файли, вони змінюються під час виконання.

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

            # Очистити кеш Bitrix
            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";

Відкат при помилці

У скрипті розгортання після розгортання додати перевірку доступності сайту:

# Перевірити що сайт відповідає 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-операціями в алфавітному порядку.