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

Проблема ручного тестування в Бітрікс-проектах

Уявіть: ви викотили оновлення на прод, а через годину помітили, що в каталозі не відображаються ціни. Коміт зламав запит до інфоблоків, але тест на це був — його просто не запустили. Наші інженери стикаються з таким регулярно. Рішення — автоматичне тестування в CI/CD. Ми впроваджуємо пайплайн, який не пропускає код у main без проходження всіх етапів. Для Бітрікс це потребує врахування особливостей ядра та БД, але ми знайшли робочі підходи.

Отримайте консультацію інженера — ми проаналізуємо ваш проект та підготуємо індивідуальну пропозицію.

Чому автоматичне тестування в CI/CD критичне для Бітрікс?

CI/CD-пайплайн виконує тести автоматично при кожному push. Розробник не може забути запустити перевірку — код блокується до зеленого пайплайну. Це економить до 80% часу на регресійному тестуванні та виключає людський фактор. Автоматичний пайплайн проходить у 20 разів швидше, ніж ручна перевірка коду перед деплоєм. Порівняння: PHPStan level 5 знаходить в 3 рази більше помилок, ніж простий lint. Для Бітрікс, де типові помилки — невірні виклики методів API або неправильні запити до інфоблоків, статичний аналіз особливо цінний. Підхід описано в Continuous Integration.

Архітектура пайплайну

Мінімальний CI-пайплайн для Бітрікс-проекту:

1. Checkout — отримання коду з репозиторію.
2. Composer install — встановлення залежностей (PHPUnit, phpstan, php-cs-fixer).
3. Lint — php -l для всіх PHP-файлів.
4. Static analysis — PHPStan / Psalm.
5. Unit tests — швидкі тести без ядра.
6. Integration tests — тести з підключенням ядра та БД.
7. Deploy (тільки для main).

Docker-образ для CI

Головна складність — ядро Бітрікс не встановлюється через Composer. Два варіанти:

Варіант A: ядро в Docker-образі.

FROM php:8.1-cli RUN apt-get update && apt-get install -y libpq-dev libzip-dev \ && docker-php-ext-install pdo pdo_mysql opcache zip COPY bitrix/ /var/www/bitrix/ COPY composer.json composer.lock /var/www/ WORKDIR /var/www RUN composer install --no-dev 

Варіант B: ядро через артефакт. CI завантажує ядро з приватного сховища (S3, GitLab Package Registry). Більш гнучко, але повільніше.

Налаштування GitLab CI

stages: - lint - test - deploy variables: MYSQL_DATABASE: bitrix_test MYSQL_ROOT_PASSWORD: test lint: stage: lint image: php:8.1-cli script: - find local/ -name "*.php" -exec php -l {} \; - vendor/bin/phpstan analyse local/php_interface/classes/ --level 5 integration-tests: stage: test image: registry.example.com/bitrix-ci:latest services: - mysql:8.0 script: - cp .env.ci .env - php local/tests/setup_db.php - vendor/bin/phpunit --configuration local/tests/phpunit.xml artifacts: when: always reports: junit: local/tests/report.xml 

Ключові моменти:

• services: mysql — піднімає контейнер MySQL, доступний по хосту mysql.
• setup_db.php — створює мінімальну схему БД.
• artifacts: junit — результати тестів в інтерфейсі merge request.

Для GitHub Actions

name: Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest services: mysql: image: mysql:8.0 env: MYSQL_DATABASE: bitrix_test MYSQL_ROOT_PASSWORD: test ports: - 3306:3306 steps: - uses: actions/checkout@v4 - uses: shivammathur/setup-php@v2 with: php-version: '8.1' extensions: pdo_mysql, mbstring, zip, gd - run: composer install - run: vendor/bin/phpunit --configuration local/tests/phpunit.xml 

Повна БД Бітрікс містить 500+ таблиць. Для інтеграційних тестів потрібен мінімальний набір: b_option, b_module, b_module_to_module (конфігурація модулів); b_iblock, b_iblock_type, b_iblock_element, b_iblock_section, b_iblock_property, b_iblock_element_property (інфоблоки); b_catalog_price, b_catalog_currency (каталог); b_sale_order, b_sale_basket, b_sale_order_props_value (замовлення). Створіть дамп схеми з продакшену: mysqldump --no-data bitrix > schema.sql. Зберігайте в репозиторії та оновлюйте при змінах. Такий дамп займає кілобайти і легко версіонується.

Інтеграційні тести з реальною БД ловлять в 5 разів більше багів, ніж юніт-тести без ядра.

Як підготувати тестове середовище?

Критично використовувати окрему БД для тестів, не зачіпаючи розробницьку або продакшен-базу. В CI для цього використовуються сервісні контейнери MySQL, які автоматично створюються та знищуються після прогону. На локальній машині розробника можна піднімати таку ж БД через Docker Compose — це гарантує ідентичне середовище.

Час виконання етапів

Якщо інтеграційні тести займають більше 15 хвилин — розділяйте їх на паралельні job'и по модулях. GitLab CI та GitHub Actions підтримують matrix-стратегії.

Які результати дає автоматизація?

Після впровадження CI/CD з автотестами час регресу скорочується на 80%, а кількість багів на проді — на 90%. Розробники економлять до 10 годин на тиждень, які раніше йшли на ручні перевірки. Неперервна інтеграція Бітрікс-проекту дозволяє автоматично перевіряти код при кожному коміті та випускати оновлення в 2 рази частіше.

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

При замовленні налаштування CI/CD для Бітрікс ми надаємо:

• Підготовлену інфраструктуру (Docker-образ з ядром, конфігурацію CI-провайдера).
• Набір базових тестів (lint, static analysis, unit, інтеграційні).
• Документацію щодо запуску тестів локально та в CI.
• Навчання команди (1-2 години воркшопу).
• Підтримку перших двох місяців (консультації, правки пайплайну).

Вартість розраховується індивідуально виходячи зі складності проекту. Оцінимо проект за один день — зв'яжіться з нами, щоб обговорити деталі. Досвід наших інженерів гарантує, що CI/CD працюватиме стабільно та не потребуватиме постійної підтримки. Отримайте консультацію, щоб отримати індивідуальну пропозицію.