אוטומציה של פריסות 1C-Bitrix עם CI/CD: מהיר יותר, פחות שגיאות

רוב פרויקטי ה-Bitrix נפרסים ידנית באמצעות FTP או SCP. עם שלושה מפתחים או יותר, זה מוביל לתקלות קבועות: עריכות שנמחקו, מיגרציות שלא נבדקו, קונפליקטים ב-bitrix/php_interface/init.php. ראינו מקרים שבהם פריסה ידנית דרסה את dbconn.php, והפילה את האתר ליום שלם. לפי ההערכות שלנו, פריסה ידנית עולה בממוצע 20 שעות אדם בחודש, לעומת שעתיים לאחר אוטומציה. על ידי הגדרת CI/CD, ניתן להפחית את זמן הפריסה פי 5 ולצמצם שגיאות ב-70%—כפי שהוכח ביותר מ-30 פרויקטים. ההשקעה בדרך כלל מחזירה את עצמה תוך 3-4 חודשים. השירות שלנו עולה $1,500. בהנחה שתעריף מפתח הוא $50 לשעה, החיסכון החודשי של 18 שעות שווה $900, כך שהשירות מחזיר את עצמו תוך כחודשיים. אנו יכולים להעריך את הפרויקט שלך ביום אחד. צור קשר לקבלת ייעוץ ללא התחייבות.

כיצד בנוי המאגר?

האסטרטגיה הנכונה: לאחסן רק את /local/ ותצורות שורש (nginx.conf, תיקוני php.ini, .env.example) ב-git. ליבת ה-Bitrix נמצאת מחוץ למאגר ומסונכרנת כתהליך נפרד.

.git/ local/ components/ modules/ php_interface/ templates/ upload/ # исключить из git (.gitignore)
bitrix/ # исключить из git (.gitignore)

.git/ local/ components/ modules/ php_interface/ templates/ upload/ # исключить из git (.gitignore) bitrix/ # исключить из git (.gitignore) מינימלי:

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

המאפיינים הספציפיים של CI/CD עבור Bitrix

Bitrix היא לא Laravel או Symfony. אין לה מנגנון מיגרציה מובנה, אין גבול ברור בין קוד לנתונים. הקשיים העיקריים:

• הליבה ב-.gitignore היא 500+ MB של קבצים שמתעדכנים דרך מערכת העדכונים של Bitrix, לא דרך git. אחסון במאגר הוא רעיון רע, אבל פריסה בלעדיה בלתי אפשרית.
• התאמות אישיות דרך /bitrix/ /upload/ /.env /bitrix/php_interface/dbconn.php —כל מה שהצוות מפתח צריך להיות כאן.
• אין מיגרציות מסד נתונים—שינויים מבניים במסד הנתונים נעשים או דרך סקריפטים או דרך הממשק.
• /bitrix/ וקאש—לאחר פריסה, יש לנקות את הקאש, אחרת עלולות להתרחש שגיאות 500.

לפי התיעוד הרשמי של 1C-Bitrix, הליבה מתעדכנת רק דרך מערכת העדכונים, מה שמטיל אילוצים על הצינור. מקור: התיעוד הרשמי של 1C-Bitrix ניתן לקרוא עוד על CI/CD ב-ויקיפדיה.

GitLab CI: צינור בסיסי

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

כיצד לארגן מיגרציות מסד נתונים?

ל-Bitrix אין מנגנון מיגרציה מובנה, אבל אפשר לפתור זאת. גישה שעובדת היא מיגרטור מותאם אישית פשוט:

<?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));

המיגרציות נקראות /local/—בסדר כרונולוגי כדי להבטיח סדר דטרמיניסטי.

ניקוי קאש לאחר פריסה

זהו שלב קריטי שלעתים קרובות נשכח:

# Сброс всего кеша через 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';
"

# Или через компонент кеша напрямую
rm -rf /var/www/myshop/bitrix/cache/*
rm -rf /var/www/myshop/bitrix/managed_cache/*

השוואה בין פריסה ידנית ל-CI/CD

תהליך העבודה

1. ניתוח — אנו לומדים את התשתית הקיימת, מבנה הקבצים, מסד הנתונים, הגישה. מזהים צווארי בקבוק וקונפליקטים פוטנציאליים.
2. תכנון — מגדירים את האסטרטגיה: מה נכנס ל-git, טיפול בליבה, תוכנית מיגרציות. מתאמים איתך.
3. יישום — מגדירים את המאגר, כותבים את הצינור, סקריפטים למיגרציה וניקוי קאש. הכל תחת בקרת גרסאות.
4. בדיקות — פורסים סביבת staging, מריצים פריסה, בודקים חזרה לגרסה קודמת. מדמים תקלה ומוודאים שהתהליך יציב.
5. פריסה לייצור — מיישמים את הצינור, מנטרים לוגים. מאמנים את הצוות שלך.

מה כולל השירות

• ארכיטקטורת מאגר עם .gitignore והחרגת ליבה.
• צינור עבור GitLab CI או GitHub Actions (לבחירתך).
• מערכת מיגרציות מסד נתונים עם קבצי SQL כרונולוגיים.
• סקריפט ניקוי קאש לאחר פריסה.
• תיעוד על התהליך והשחזור.
• גישה והדרכת צוות (וובינר של שעה).
• תמיכה לחודש אחד לאחר ההשקה.

טעויות נפוצות בהגדרת CI/CD

• לא מוסיפים את bitrix_sessid ל-.gitignore—המאגר מתנפח ל-500+ MB.
• לא מגדירים ניקוי קאש—האתר מחזיר שגיאות 500 לאחר פריסה.
• מיגרציות מיושמות בסדר לא נכון—השתמש בחותמות זמן בשמות הקבצים.
• הצינור לא מבודד—השתמש במפתחות SSH נפרדים לכל סביבה.

אנחנו צוות עם 5 שנות ניסיון בפיתוח Bitrix, שסיפקנו 30+ פרויקטים עם CI/CD. השירות שלנו מובטח להפחית שגיאות פריסה ב-70% לפחות. הזמינו הגדרת CI/CD וקבלו תהליך פריסה יציב. קבלו ייעוץ ללא התחייבות.