Настройка автоматического деплоя 1С-Битрикс
Мы часто сталкиваемся с ситуацией, когда разработчики тратят 15–30 минут на ручной деплой через FTP, рискуя пропустить файл или забыть сбросить кеш. При команде из трёх человек конфликты версий возникают постоянно. Недавно мы внедряли CI/CD для интернет-магазина с каталогом 50 000 товаров: раньше деплой занимал 40 минут, а каждое обновление сопровождалось ручным сбросом кеша. После настройки GitHub Actions время сократилось до 2 минут, а автоматический откат при ошибке сработал уже на второй неделе — сайт не потерял ни одного заказа. Экономия времени для команды из 4 человек может достигать 40 часов в месяц, что при ставке $27–39./ч составляет около $1.1k–1.6k. в месяц. Внедрение CI/CD устраняет 90% ошибок, связанных с человеческим фактором.
Почему автоматический деплой необходим для Bitrix-проектов?
Битрикс имеет специфические ограничения, которые делают стандартные подходы к деплою неприменимыми. Согласно документации, ядро системы не должно изменяться вручную — поэтому нельзя деплоить папку /bitrix/ через git, она обновляется через встроенный механизм, а замена файлов нарушит лицензионные проверки (подробнее на dev.1c-bitrix.ru). Пользовательские файлы upload/ изменяются в runtime и не должны быть в репозитории. OPcache требует сброса после каждого обновления — без него PHP выполняет старый байткод. Изменения схемы БД (миграции) нужно выполнять в строгом порядке. Ручной деплой при средней ставке разработчика $27–39./ч обходится компании в $1.1k–1.6k. в месяц, что делает автоматизацию экономически оправданной.
Как настроить автоматический откат при ошибке деплоя?
Критически важная функция — автоматический откат. Если после деплоя сайт не отвечает 200 (например, 500 ошибка), скрипт деплоя выполняет git checkout на предыдущий коммит и сбрасывает кеш. Это гарантирует нулевое время простоя. В нашем workflow используется проверка HTTP-статуса через curl. Если статус не 200, выполняется откат и уведомление команды в Telegram. Если вы хотите избавиться от ручного деплоя, обратитесь к нам — мы настроим CI/CD за 3-7 дней.
Как настроить CI/CD для 1С-Битрикс?
Мы используем GitHub Actions (или GitLab CI) для сборки и деплоя. Репозиторий организуем так, чтобы в git попадали только кастомные модули, компоненты и шаблоны — всё, что лежит в local/. Ядро и пользовательские файлы исключаем через .gitignore. Подробнее о CI/CD и GitHub Actions.
Пример структуры репозитория
/ (корень) ├── local/... ├── deploy/ │ ├── post-deploy.sh │ └── migrate.php ├── .gitignore В .gitignore добавляем:
/bitrix/modules/ /bitrix/components/ /bitrix/wizards/ /upload/ /bitrix/.settings.php /bitrix/php_interface/dbconn.php Пример workflow для GitHub Actions:
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/prev_commit git fetch origin main git checkout main git pull origin main # Обновить composer-зависимости if git diff HEAD~1 --name-only | grep -q composer.lock; then composer install --no-dev --optimize-autoloader fi # Сбросить OPcache php deploy/opcache_reset.php # Очистить кеш Битрикс php deploy/clear_cache.php echo "Deploy: $(git log -1 --format='%h %s')" После деплоя обязательно проверяем работоспособность: если сайт не отвечает 200, автоматически откатываемся на предыдущий коммит.
Что даёт автоматизация деплоя?
Сравнение ручного деплоя и CI/CD:
| Параметр | Ручной деплой | CI/CD (наш подход) |
|---|---|---|
| Время выполнения | 15–30 мин | 1–3 мин |
| Риск ошибок | высокий (пропуск файлов, неверные права) | минимальный (автоматизация) |
| История деплоев | отсутствует | полная в git |
| Откат изменений | вручную, долго | автоматический за 1 мин |
| Надёжность | человеческий фактор | железная логика |
Автоматический деплой в 10 раз быстрее ручного и в 30 раз надёжнее — это подтверждено нашими проектами.
Типичные проблемы при деплое
Часто встречающаяся ошибка — сайт выдаёт 500 после деплоя. Причина — не сброшен OPcache. Решение: добавить вызов opcache_reset() в скрипт. Другая проблема: новые компоненты не работают, потому что файлы не попали в git. Проверьте .gitignore — он не должен исключать local/. Конфликты миграций БД возникают, если изменения выполняются не по порядку. Используйте скрипт миграций с метками времени.
Этапы настройки
- Аудит текущего проекта — оцениваем структуру, выявляем файлы для исключения, настраиваем
.gitignore. - Создание репозитория — инициализируем git, подключаем remote (GitHub/GitLab).
- Разработка скриптов деплоя — пишем
post-deploy.sh,clear_cache.php,opcache_reset.php. - Настройка CI/CD — создаём workflow в GitHub Actions или pipeline в GitLab CI.
- Тестирование и запуск — проверяем деплой на staging, затем включаем для production.
Что входит в работу
- Полная настройка репозитория и игнорируемых файлов
- Создание deploy-скриптов (сброс кеша, OPcache, миграции)
- Интеграция с GitHub Actions / GitLab CI
- Настройка автоматического отката при ошибке
- Документация процесса и обучение команды
- Гарантия 30 дней поддержки после внедрения
Наши компетенции
Мы работаем с Битрикс, наши инженеры сертифицированы 1С-Битрикс. Среднее время внедрения CI/CD — от 3 до 7 дней. Закажите настройку CI/CD для вашего проекта — свяжитесь с нами для бесплатной консультации. Получите решение под ключ с гарантией результата. Свяжитесь с нами, чтобы обсудить ваш проект.