Налаштування автоматичного деплою 1С-Бітрікс
Ми часто стикаємося з ситуацією, коли розробники витрачають 15–30 хвилин на ручний деплой через FTP, ризикуючи пропустити файл або забути скинути кеш. При команді з трьох осіб конфлікти версій виникають постійно. Нещодавно ми впроваджували CI/CD для інтернет-магазину з каталогом 50 000 товарів: раніше деплой займав 40 хвилин, а кожне оновлення супроводжувалося ручним скиданням кешу. Після налаштування GitHub Actions час скоротився до 2 хвилин, а автоматичний відкат при помилці спрацював уже на другому тижні — сайт не втратив жодного замовлення. Економія часу для команди з 4 осіб може досягати 40 годин на місяць. Впровадження CI/CD усуває 90% помилок, пов'язаних з людським фактором.
Чому автоматичний деплой необхідний для Bitrix-проектів?
Бітрікс має специфічні обмеження, які роблять стандартні підходи до деплою неприйнятними. Згідно з документацією, ядро системи не повинно змінюватися вручну — тому не можна деплоїти папку /bitrix/ через git, вона оновлюється через вбудований механізм, а заміна файлів порушить ліцензійні перевірки (детальніше на dev.1c-bitrix.ru). Користувацькі файли upload/ змінюються в runtime і не повинні бути в репозиторії. OPcache вимагає скидання після кожного оновлення — без нього PHP виконує старий байткод. Зміни схеми БД (міграції) потрібно виконувати в строгому порядку. Ручний деплой при середній ставці розробника обходиться компанії в 120 000 грн на місяць, що робить автоматизацію економічно виправданою.
Як налаштувати автоматичний відкат при помилці деплою?
Критично важлива функція — автоматичний відкат. Якщо після деплою сайт не відповідає 200 (наприклад, 500 помилка), скрипт деплою виконує git checkout на попередній коміт і скидає кеш. Це гарантує нульовий час простою. У нашому workflow використовується перевірка HTTP-статусу через curl. Якщо статус не 200, виконується відкат і повідомлення команди в Telegram. Якщо ви хочете позбутися ручного деплою, зверніться до нас — ми налаштуємо CI/CD за 3-7 днів.
Як налаштувати CI/CD для 1С-Бітрікс?
Ми використовуємо GitHub Actions (або GitLab CI) для збірки та деплою. Репозиторій організовуємо так, щоб у git потрапляли лише кастомні модулі, компоненти та шаблони — все, що лежить у local/. Ядро та користувацькі файли виключаємо через .gitignore. Детальніше про CI/CD та GitHub Actions.
Приклад структури репозиторію
/ (корінь) ├── local/... ├── deploy/ │ ├── post-deploy.sh │ └── migrate.php ├── .gitignore У .gitignore додаємо:
/bitrix/modules/ /bitrix/components/ /bitrix/wizards/ /upload/ /bitrix/.settings.php /bitrix/php_interface/dbconn.php Приклад workflow для GitHub Actions:
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 # Зберегти коміт для відкату git log -1 --format="%H" > /tmp/prev_commit git fetch origin main git checkout main git pull origin main # Оновити composer-залежності if git diff HEAD~1 --name-only | grep -q composer.lock; then composer install --no-dev --optimize-autoloader fi # Скинути OPcache php deploy/opcache_reset.php # Очистити кеш Бітрікс php deploy/clear_cache.php echo "Deploy: $(git log -1 --format='%h %s')" Після деплою обов'язково перевіряємо працездатність: якщо сайт не відповідає 200, автоматично відкочуємося на попередній коміт.
Що дає автоматизація деплою?
Порівняння ручного деплою та CI/CD:
| Параметр | Ручний деплой | CI/CD (наш підхід) |
|---|---|---|
| Час виконання | 15–30 хв | 1–3 хв |
| Ризик помилок | високий (пропуск файлів, невірні права) | мінімальний (автоматизація) |
| Історія деплоїв | відсутня | повна в git |
| Відкат змін | вручну, довго | автоматичний за 1 хв |
| Надійність | людський фактор | залізна логіка |
Автоматичний деплой у 10 разів швидший за ручний і в 30 разів надійніший — це підтверджено нашими проектами.
Типові проблеми при деплої
Часто зустрічається помилка — сайт видає 500 після деплою. Причина — не скинутий OPcache. Рішення: додати виклик opcache_reset() у скрипт. Інша проблема: нові компоненти не працюють, тому що файли не потрапили в git. Перевірте .gitignore — він не повинен виключати local/. Конфлікти міграцій БД виникають, якщо зміни виконуються не по порядку. Використовуйте скрипт міграцій з мітками часу.
Етапи налаштування
- Аудит поточного проекту — оцінюємо структуру, виявляємо файли для виключення, налаштовуємо
.gitignore. - Створення репозиторію — ініціалізуємо git, підключаємо remote (GitHub/GitLab).
- Розробка скриптів деплою — пишемо
post-deploy.sh,clear_cache.php,opcache_reset.php. - Налаштування CI/CD — створюємо workflow у GitHub Actions або pipeline у GitLab CI.
- Тестування та запуск — перевіряємо деплой на staging, потім включаємо для production.
Що входить у роботу
- Повне налаштування репозиторію та ігнорованих файлів
- Створення deploy-скриптів (скидання кешу, OPcache, міграції)
- Інтеграція з GitHub Actions / GitLab CI
- Налаштування автоматичного відкату при помилці
- Документація процесу та навчання команди
- Гарантія 30 днів підтримки після впровадження
Наші компетенції
Ми працюємо з Бітрікс, наші інженери сертифіковані 1С-Бітрікс. Середній час впровадження CI/CD — від 3 до 7 днів. Замовте налаштування CI/CD для вашого проекту — зв'яжіться з нами для безкоштовної консультації. Отримайте рішення під ключ з гарантією результату. Зв'яжіться з нами, щоб обговорити ваш проект.