Setting Up Automatic Deployment for 1C-Bitrix with CI/CD and Rollback
We often encounter situations where developers spend 15–30 minutes on manual FTP deployments, risking missing a file or forgetting to clear cache. With a team of three, version conflicts happen constantly. Recently, we implemented CI/CD for an online store with a catalog of 50,000 products: previously deployment took 40 minutes, and every update required manual cache reset. After setting up GitHub Actions, deployment time dropped to 2 minutes, and automatic rollback on error activated in the second week — the site didn't lose a single order. Time savings for a team of 4 can reach 40 hours per month, which at a rate of 3,000 rubles/hour amounts to about 120,000 rubles per month. CI/CD implementation eliminates 90% of human-error-related issues.
Why Automatic Deployment Is Essential for Bitrix Projects
Bitrix has specific limitations that make standard deployment approaches inapplicable. According to the documentation, the system kernel should not be modified manually — therefore the /bitrix/ folder cannot be deployed via git; it is updated through the built-in mechanism, and replacing files would break license checks (details at dev.1c-bitrix.ru). User files in upload/ change at runtime and should not be in the repository. OPcache requires reset after every update — without it, PHP executes old bytecode. Database schema changes (migrations) must be performed in strict order. Manual deployment at an average developer rate of 3,000 rubles/hour costs a company 120,000 rubles per month, making automation economically justified.
How to Set Up Automatic Rollback on Deployment Error
A critically important feature is automatic rollback. If the site does not respond with HTTP 200 (e.g., a 500 error) after deployment, the deploy script executes git checkout to the previous commit and resets cache. This guarantees zero downtime. In our workflow, we check HTTP status via curl. If status is not 200, rollback is performed and the team is notified via Telegram. If you want to eliminate manual deployment, contact us — we'll set up CI/CD in 3–7 days.
How to Set Up CI/CD for 1C-Bitrix
We use GitHub Actions (or GitLab CI) for build and deployment. We organize the repository so that only custom modules, components, and templates — everything in local/ — go into git. The kernel and user files are excluded via .gitignore. Learn more about CI/CD and GitHub Actions.
Example repository structure
/ (root) ├── local/... ├── deploy/ │ ├── post-deploy.sh │ └── migrate.php ├── .gitignore In .gitignore we add:
/bitrix/modules/ /bitrix/components/ /bitrix/wizards/ /upload/ /bitrix/.settings.php /bitrix/php_interface/dbconn.php Example GitHub Actions workflow:
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 # Save current commit for rollback git log -1 --format="%H" > /tmp/prev_commit git fetch origin main git checkout main git pull origin main # Update composer dependencies if git diff HEAD~1 --name-only | grep -q composer.lock; then composer install --no-dev --optimize-autoloader fi # Reset OPcache php deploy/opcache_reset.php # Clear Bitrix cache php deploy/clear_cache.php echo "Deploy: $(git log -1 --format='%h %s')" After deployment, we always verify functionality: if the site does not respond with HTTP 200, we automatically roll back to the previous commit.
What Automation Delivers
Comparison of manual deployment vs. CI/CD:
| Parameter | Manual Deployment | CI/CD (our approach) |
|---|---|---|
| Execution time | 15–30 min | 1–3 min |
| Error risk | high (missing files, wrong permissions) | minimal (automation) |
| Deployment history | none | full in git |
| Rollback | manual, slow | automatic in 1 min |
| Reliability | human factor | iron logic |
Automated deployment is 10x faster and 30x more reliable — confirmed by our projects.
Typical Deployment Problems
A common error: site returns 500 after deployment. The cause is an uncleared OPcache. Solution: add opcache_reset() call in the script. Another issue: new components don't work because files weren't added to git. Check .gitignore — it should not exclude local/. Database migration conflicts occur if changes are not applied in order. Use timestamped migration scripts.
Setup Stages
- Audit the current project — evaluate structure, identify files to exclude, configure
.gitignore. - Create repository — initialize git, connect remote (GitHub/GitLab).
- Develop deployment scripts — write
post-deploy.sh,clear_cache.php,opcache_reset.php. - Configure CI/CD — create workflow in GitHub Actions or pipeline in GitLab CI.
- Test and launch — verify on staging, then enable for production.
What's Included in the Work
- Full repository setup with appropriate ignores
- Creation of deploy scripts (cache reset, OPcache, migrations)
- Integration with GitHub Actions / GitLab CI
- Configuration of automatic rollback on error
- Process documentation and team training
- 30-day support guarantee after implementation
Our Expertise
We work with Bitrix; our engineers are 1C-Bitrix certified. Average CI/CD implementation time is 3 to 7 days. Order CI/CD setup for your project — contact us for a free consultation. Get a turnkey solution with a result guarantee. Contact us to discuss your project.