Большинство Битрикс-проектов деплоятся по одной схеме: 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 часа |
Процесс работы
- Аналитика — изучаем текущую инфраструктуру, структуру файлов, БД, доступы. Выявляем узкие места и потенциальные конфликты.
- Проектирование — определяем стратегию: что кладём в git, как обрабатываем ядро, схему миграций. Согласовываем с вами.
- Реализация — настраиваем репозиторий, пишем пайплайн, скрипты миграций и сброса кеша. Всё под версионный контроль.
- Тестирование — разворачиваем staging, прогоняем деплой, проверяем откат. Имитируем сбой и убеждаемся, что процесс устойчив.
- Деплой в продакшн — применяем пайплайн, мониторим логи. Обучаем команду.
| Этап | Срок |
|---|---|
| Аналитика и проектирование | 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 и получите стабильный процесс деплоя. Получите консультацию без обязательств.







