Automate 1C-Bitrix Deployments with CI/CD: Faster, Fewer Errors

Most Bitrix projects are deployed manually via FTP or SCP. With three or more developers, this leads to regular incidents: overwritten edits, untested migrations, conflicts in bitrix/php_interface/init.php. We've seen cases where a manual deployment overwrote dbconn.php, bringing the site down for a day. According to our estimates, manual deployment costs an average of 20 person-hours per month versus 2 hours after automation. By setting up CI/CD, you can reduce deployment time by 5x and cut errors by 70%—proven across 30+ projects. The investment typically pays off in 3-4 months. Our service costs $1,500. Assuming a developer rate of $50/hour, the monthly saving of 18 hours equals $900, so the service pays for itself in about 2 months. We can evaluate your project in one day. Contact us for a no-obligation consultation.

How is the repository structured?

The correct strategy: store only /local/ and root configs (nginx.conf, php.ini patches, .env.example) in git. The Bitrix kernel is outside the repository and synchronized as a separate process.

.git/ local/ components/ modules/ php_interface/ templates/ upload/ # exclude from git (.gitignore) bitrix/ # exclude from git (.gitignore) 

Minimal .gitignore:

/bitrix/ /upload/ /.env /bitrix/php_interface/dbconn.php 

CI/CD specifics for Bitrix

Bitrix is not Laravel or Symfony. It has no built-in migration mechanism, no clear boundary between code and data. The main difficulties:

• The kernel in /bitrix/ is 500+ MB of files that are updated via the Bitrix updater, not through git. Storing it in the repository is a bad idea, but deploying without it is impossible.
• Customizations via /local/—everything the team develops should go here.
• No database migrations—structural DB changes are made either via scripts or through the interface.
• bitrix_sessid and cache—after deployment, cache must be cleared, otherwise 500 errors may occur.

According to the 1C-Bitrix documentation, the kernel is only updated via the system updater, which imposes constraints on the pipeline. Source: 1C-Bitrix official documentation You can read more about CI/CD on Wikipedia.

GitLab CI: basic pipeline

# .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 

How to organize database migrations?

Bitrix has no built-in migration mechanism, but this can be solved. A working approach is a simple custom 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)); 

Migrations are named YYYYMMDD_HHMMSS_add_property_article.sql—chronologically to ensure deterministic order.

Cache clearing after deployment

This is a critical step often forgotten:

# Clear all cache via 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'; " # Or directly via cache component rm -rf /var/www/myshop/bitrix/cache/* rm -rf /var/www/myshop/bitrix/managed_cache/* 

Comparison of manual deployment vs CI/CD

Process of work

1. Analysis — we study the current infrastructure, file structure, DB, access. Identify bottlenecks and potential conflicts.
2. Design — define the strategy: what goes into git, kernel handling, migration scheme. Coordinate with you.
3. Implementation — set up the repository, write the pipeline, migration and cache clearing scripts. All under version control.
4. Testing — deploy a staging environment, run deployment, verify rollback. Simulate a failure and ensure the process is robust.
5. Production deployment — apply the pipeline, monitor logs. Train your team.

What's Included in the Service

• Repository architecture with .gitignore and kernel exclusion.
• Pipeline for GitLab CI or GitHub Actions (your choice).
• Database migration system with chronological SQL files.
• Cache clearing script after deployment.
• Documentation on the process and recovery.
• Access and team training (1-hour webinar).
• Support for one month after launch.

Common mistakes when setting up CI/CD

• Not adding /bitrix/ to .gitignore—repository bloats to 500+ MB.
• Not configuring cache clearing—the site returns 500 errors after deployment.
• Migrations applied in wrong order—use timestamps in file names.
• Pipeline not isolated—use separate SSH keys for each environment.

We are a team with 5 years of Bitrix development experience, having delivered 30+ projects with CI/CD. Our service is guaranteed to reduce deployment errors by at least 70%. Order CI/CD setup and get a stable deployment process. Get a no-obligation consultation.