Налаштування CI/CD для проекту на 1С-Бітрікс

Більшість Бітрікс-проектів деплояться за однією схемою: FTP/SCP вручну або через файловий менеджер хостингу. Коли в команді три особи і більше, це перетворюється на джерело регулярних інцидентів — перезатерті правки, невідлагоджені міграції, конфлікти в bitrix/php_interface/init.php. Одного разу наш клієнт втратив три дні, коли після ручного деплою перезаписали конфіг dbconn.php, і сайт упав на добу. За нашими оцінками, ручний деплой обходиться в середньому в 20 людино-годин на місяць проти 2 годин після автоматизації. Налаштувавши CI/CD, ви скоротите час деплою в 5 разів і знизите кількість помилок на 70% — це підтверджено досвідом 30+ проектів. Інвестиції в налаштування CI/CD окупаються за 3-4 місяці. Економія до $500 на місяць на ручних деплоях. Вартість налаштування від $1000. Оцінимо ваш проект за один день. Зв'яжіться з нами, щоб отримати консультацію без зобов'язань. Надаємо гарантію на налаштування CI/CD терміном 1 рік. Маємо сертифікацію 1С-Бітрікс та 5-річний досвід у DevOps для Бітрікс.

Як влаштована структура репозиторію?

Правильна стратегія: в 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

Як організувати міграції бази даних?

Бітрікс не має вбудованого механізму міграцій, але це вирішується. Робочий підхід — власний простий мігратор:

<?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

CI/CD краще ручного деплою в 5 разів за часом і в 3 рази за надійністю. Завдяки автоматизації зникають простої через людський фактор.

Процес роботи

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

Що входить в роботу

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

Поширені помилки при налаштуванні CI/CD

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

Ми — команда з 5-річним досвідом розробки на Бітрікс, реалізували понад 30 проектів з CI/CD. Замовте налаштування CI/CD та отримайте стабільний процес деплою. Отримайте консультацію без зобов'язань. Автоматизація бітрікс проектів — наша спеціалізація. Безперервна інтеграція бітрікс-проектів дозволяє мінімізувати простої. DevOps для Bitrix — ми знаємо всі тонкощі.

rsync -avz на продакшен у п’ятницю ввечері, рестарт php-fpm — і сайт відповідає 502, бо в .settings.php залишилися локальні налаштування БД. Деплой «по-старому» — лотерея. Оновлення модуля через адмінку ламає кастомний шаблон компонента, правки не зафіксовані в Git — відновлення займає години.

Ми проєктуємо передбачуваний DevOps-цикл для проєктів на Бітрікс: від Docker-середовища до алертів у Telegram. Кожен деплой стає рутиною, а не стресом.

Проблеми, які ми вирішуємо

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». Результат: двоє розробників одночасно правлять init.php, затираючи зміни один одного. Оновлення модуля через адмінку ламає шаблон компонента — файли не зафіксовані в /local/templates/. Про падіння сайту дізнаються від клієнта, staging-середовища немає, перевірки йдуть на проді. Вартість такого підходу — години відновлення та втрата бізнес-логіки.

Чому DevOps критичний для Бітрікс-проєктів?

Проєкти на Бітрікс мають специфіку: важкий торговий каталог, обмін з 1С через CommerceML, безліч агентів та подій. Без CI/CD та моніторингу кожна зміна — ризик. Ручний деплой може спричинити тижневий простій. Після впровадження DevOps середня економія трудовитрат — до 12 годин ручної роботи на місяць, а бюджету підтримки — 15 000–25 000 грн на місяць. Наш 5-річний досвід (понад 50 проєктів на Бітрікс) і ліцензійна чистота рішень — гарантія стабільності.

Інструменти та конфігурація

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main, staging, develop, feature-гілки. .gitignore під Бітрікс — нетривіальне завдання:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код: PHPStan level 5+ ловить звернення до неіснуючих методів CIBlockElement, PHP_CodeSniffer з Bitrix-стандартом, PHPUnit для бізнес-логіки, composer audit, збірка фронту. CD-пайплайн розгортає без участі людини. Мерж у staging — деплой на staging. Мерж у main — деплой на production (з ручним підтвердженням або без). Zero-downtime через symlink-стратегію: нова версія в окремій папці, current → symlink перемикається за мілісекунди. upload/ живе поза релізними директоріями. При помилці healthcheck після деплою symlink відкочується. Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer зручний для Бітрікс — є готові рецепти для symlink-деплою та shared-директорій.

Як Docker вирішує проблему «у мене працює»?

Docker-середовище фіксує версії всіх компонентів: nginx, PHP, MySQL, Redis. Docker скорочує час розгортання нового розробника в 10 разів порівняно з ручним налаштуванням. Локальна розробка — docker-compose.yml включає nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached. Новий розробник: git clone + docker-compose up -d — за 5 хвилин пише код. Паралельна робота над різними версіями PHP — через окремі compose-файли.

Особливості Бітрікс у Docker: /upload/ монтується як named volume (не bind mount — інакше на Windows/Mac проблеми з правами та швидкістю). Cron-завдання (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим же образом або supervisord. Модуль «Проактивний захист» (security) блокує запити через reverse proxy — потрібен правильний REMOTE_ADDR через set_real_ip_from та realip_module. bitrix/php_interface/dbconn.php та .settings.php задаються через змінні оточення.

Production: мультистейдж-збірка (build-стадія для асетів, production-стадія з легким образом), Docker Registry для тегованих образів, оркестрація через Docker Swarm або Kubernetes для великих проєктів.

Як правильно налаштувати nginx та php-fpm для Бітрікс?

Різниця між «сайт гальмує» та 200 ms TTFB — у конфігурації. nginx: location-блоки під Бітрікс обробляють urlrewrite.php для ЧПУ. /bitrix/admin/ закриває доступ по IP через allow/deny. expires 30d для статики — CSS, JS, зображення кешуються браузером. Brotli (стиснення на 15-20% ефективніше gzip) вмикається brotli on; brotli_comp_level 6;. Rate limiting на /bitrix/tools/ захищає від брутфорсу. HTTP/2 push для критичних ресурсів.

php-fpm: pm = dynamic, розрахунок pm.max_children за формулою (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 MB. OPcache: opcache.memory_consumption=256 (стандартних 128 MB недостатньо — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 у продакшені (скидання через cachetool opcache:reset при деплої). php.ini: memory_limit=256M (для важких операцій імпорту до 512M), max_execution_time=60, upload_max_filesize=100M. Slowlog з request_slowlog_timeout=5s знаходить вузькі місця до скарг користувачів.

Інфраструктура та автоматизація

Моніторинг, логування та резервне копіювання

Як відбувається моніторинг та реагування на інциденти? Prometheus + Grafana: метрики CPU, RAM, диска, мережі, стану сервісів. Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 MB, диск > 85%, php-fpm queue > 0. Node Exporter, MySQL Exporter, PHP-FPM Exporter збирають дані з кожного компонента. Uptime check кожні 60 секунд — алерт у Telegram за хвилину при падінні сайту. Sentry для PHP-помилок — структуровані помилки з контекстом. Моніторинг агентів Бітрікс (b_agent): завислий агент може тихо ламати обмін з 1С годинами — перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR. Логування: ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, помилки Бітрікс. Ротація через logrotate — без неї через півроку access.log займе 50 ГБ.

Staging-середовище ідентичне production: ті ж версії nginx, PHP, MySQL, модулі, налаштування php.ini. Автоматичне оновлення при мержі у staging-гілку. Періодичний клон БД з production з знеособленням персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = ''. HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /. Sandbox-режим платіжних шлюзів для тестування оплати.

Ansible як інфраструктура як код: ansible-playbook site.yml -l production — через 15 хвилин сервер налаштований ідентично. Ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Ansible забезпечує налаштування сервера за 15 хвилин замість 3 годин вручну.

Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД. Тестове відновлення щомісяця — бекап без перевірки лише ілюзія безпеки. Cron з повідомленнями: якщо беказ не пройшов — алерт одразу.

Що входить в роботу

• Документація DevOps-процесу (схема деплою, політика гілок, опис інфраструктури)
• Налаштовані CI/CD пайплайни (GitLab CI / GitHub Actions) з робочими тригерами
• Docker-середовище (docker-compose.yml, Dockerfile, конфіги)
• Ansible-плейбуки для відтворення серверів
• Моніторинг (Grafana дашборди, алерти в Telegram/Slack)
• Захищені доступи з ролевою моделлю
• Навчання команди: два заняття з роботи з CI/CD, Docker та деплоєм
• Підтримка на етапі впровадження (два тижні після запуску)

Приклад GitLab CI для Бітрікс (фрагмент):

stages:
  - test
  - build
  - deploy

cache:
  paths:
    - vendor/

unit_tests:
  stage: test
  script:
    - composer install --no-progress
    - php vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -l staging
  only:
    - staging

Як проходить впровадження?

1. Аудит поточного стану — оцінка інфраструктури, софту, процесів. Займає 2-3 дні.
2. Проектування архітектури — вибір стеку (Docker/K8s/Ansible), узгодження політик CI/CD, налаштування репозиторію.
3. Налаштування середовищ — Docker-середовище для локальної розробки, staging-середовище, production-сервери.
4. Реалізація CI/CD — написання пайплайнів, тестування деплою, інтеграція з моніторингом.
5. Моніторинг та алертинг — встановлення Prometheus + Grafana, налаштування дашбордів та оповіщень.
6. Навчання команди — два заняття з роботи з інструментами.

Типові терміни впровадження

DevOps — не проєкт з фінальною датою, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування середовища. Отримайте консультацію — зв'яжіться з нами, і за 2-3 дні підготуємо план впровадження. Замовте DevOps-впровадження під ключ — отримайте стабільність і контроль над інфраструктурою.