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

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

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

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1321
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    914
  • 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
    663
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    810
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    709
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1043

Большинство Битрикс-проектов деплоятся по одной схеме: 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

Параметр Ручной деплой (FTP) CI/CD (предлагаемый)
Время деплоя 30-60 минут 5-10 минут
Риск ошибок высокий низкий
Миграции БД вручную через админку автоматические скрипты
Сброс кеша забывают обязательный шаг в пайплайне
Откат сложный быстрый через git revert
Средние затраты времени в месяц 20 часов 2 часа

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

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

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

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

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

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

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