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

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

Тести написані, але розробники запускають їх вручну — і забувають. Код потрапляє в продакшн без перевірки, тести застарівають, покриття деградує. Автоматичне тестування в CI/CD вирішує організаційну проблему: код не може потрапити в основну гілку без проходження тестів. Для Бітрікса це реалізується складніше, ніж для Symfony чи Laravel, через залежність від ядра та БД, але цілком розв'язне.

Архітектура pipeline'у

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

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-образі. Створіть базовий образ з встановленим Бітриксом, PHP та розширеннями. Оновлюйте образ при оновленні ядра на проекті. Це найнадійніший підхід.

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 всередині CI
• setup_db.php — скрипт, що створює схему тестової БД (мінімальний набір таблиць Бітрікса)
• artifacts: junit — GitLab/GitHub відображає результати тестів в інтерфейсі 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 — замовлення (якщо тестуєте e-commerce)

Створіть дамп схеми з продакшену: mysqldump --no-data bitrix > schema.sql. Додайте в репозиторій та оновлюйте при змінах структури.

Що перевіряти в CI обов'язково

PHP Lint. Тривіально, але ловить синтаксичні помилки у файлах, які не вивикликаються при ручному тестуванні. Бітрікс-проекти часто містять файли, підключувані умовно (по агенту, по cron) — помилку в них виявляють вже на продакшені.

PHPStan level 5+. На рівні 5 PHPStan знаходить звернення до неіснуючих методів, некоректні типи аргументів, невизначені змінні. Для Бітрікс-коду потребуватиме файл phpstan-baseline.neon з ігноруванням помилок ядра — ядро не типізовано та генерує сотні попереджень.

Smoke-тести HTTP. Якщо CI піднімає повне оточення (PHP-FPM + Nginx + MySQL), додайте curl-перевірки критичних URL:

curl -f http://localhost/
curl -f http://localhost/catalog/
curl -f http://localhost/personal/cart/

Статус 200 — тест пройдений. Будь-який інший — fail pipeline'у.

Час виконання

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

Налаштування CI/CD для Бітрікс-проекту — це інвестиція в один робочий день, що окупиться при першому ж попередженому баги на продакшені.