הגדרת פריסה אוטומטית עבור 1C-Bitrix עם CI/CD וגלגול לאחור
לעתים קרובות אנו נתקלים במצבים שבהם מפתחים מבזבזים 15–30 דקות על פריסות FTP ידניות, תוך סיכון להחמיץ קובץ או לשכוח לנקות מטמון. עם צוות של שלושה, קונפליקטים בין גרסאות קורים כל הזמן. לאחרונה יישמנו CI/CD עבור חנות מקוונת עם קטלוג של 50,000 מוצרים: בעבר הפריסה ארכה 40 דקות, וכל עדכון דרש איפוס מטמון ידני. לאחר הגדרת GitHub Actions, זמן הפריסה ירד ל-2 דקות, וגלגול אוטומטי לאחור במקרה שגיאה הופעל בשבוע השני — האתר לא איבד אף הזמנה. חיסכון בזמן עבור צוות של 4 יכול להגיע ל-40 שעות בחודש, שבתעריף של $27–39 לשעה מסתכם בכ-$1.1k–1.6k לחודש. יישום CI/CD מבטל 90% מהבעיות הקשורות לטעויות אנוש.
מדוע פריסה אוטומטית חיונית לפרויקטים של Bitrix
ל-Bitrix יש מגבלות ספציפיות שהופכות גישות פריסה סטנדרטיות לבלתי רלוונטיות. לפי התיעוד, אין לשנות את ליבת המערכת ידנית — לכן לא ניתן לפרוס את התיקייה /bitrix/ דרך git; היא מתעדכנת באמצעות המנגנון המובנה, והחלפת קבצים תשבור את בדיקות הרישיון (פרטים ב-dev.1c-bitrix.ru). קבצי משתמש ב-upload/ משתנים בזמן ריצה ואינם צריכים להיות במאגר. OPcache דורש איפוס לאחר כל עדכון — בלעדיו, PHP מריץ bytecode ישן. שינויים בסכמת מסד הנתונים (מיגרציות) חייבים להתבצע בסדר קפדני. פריסה ידנית בתעריף ממוצע של $27–39 לשעה עולה לחברה $1.1k–1.6k בחודש, מה שהופך את האוטומציה למוצדקת כלכלית.
כיצד להגדיר גלגול אוטומטי לאחור במקרה שגיאת פריסה
תכונה קריטית ביותר היא גלגול אוטומטי לאחור. אם האתר אינו מגיב עם HTTP 200 (לדוגמה, שגיאת 500) לאחר הפריסה, סקריפט הפריסה מבצע git checkout ל-commit הקודם ומאפס את המטמון. זה מבטיח אפס זמן השבתה. בזרימת העבודה שלנו, אנו בודקים את סטטוס ה-HTTP באמצעות curl. אם הסטטוס אינו 200, מתבצע גלגול לאחור והצוות מקבל הודעה דרך Telegram. אם ברצונך לבטל פריסה ידנית, צור קשר — נגדיר CI/CD תוך 3–7 ימים.
כיצד להגדיר CI/CD עבור 1C-Bitrix
אנו משתמשים ב-GitHub Actions (או GitLab CI) לבנייה ופריסה. אנו מארגנים את המאגר כך שרק מודולים מותאמים אישית, רכיבים ותבניות — כל מה שב-local/ — נכנסים ל-git. הליבה וקבצי המשתמש מוחרגים באמצעות .gitignore. למידע נוסף על CI/CD ו-GitHub Actions.
דוגמה למבנה מאגר
/ (корень) ├── local/... ├── deploy/ │ ├── post-deploy.sh │ └── migrate.php ├── .gitignore ב-/ (корень) ├── local/... ├── deploy/ │ ├── post-deploy.sh │ └── migrate.php ├── .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')" לאחר הפריסה, אנו תמיד בודקים את התפקוד: אם האתר אינו מגיב עם HTTP 200, אנו מתגלגלים אוטומטית לאחור ל-commit הקודם.
מה האוטומציה מספקת
השוואה בין פריסה ידנית ל-CI/CD:
| פרמטר | פריסה ידנית | CI/CD (הגישה שלנו) |
|---|---|---|
| זמן ביצוע | 15–30 דקות | 1–3 דקות |
| סיכון לשגיאות | גבוה (קבצים חסרים, הרשאות שגויות) | מינימלי (אוטומציה) |
| היסטוריית פריסות | אין | מלאה ב-git |
| גלגול לאחור | ידני, איטי | אוטומטי תוך דקה |
| אמינות | גורם אנושי | לוגיקה ברזל |
פריסה אוטומטית מהירה פי 10 ואמינה פי 30 — מאומת על ידי הפרויקטים שלנו.
בעיות פריסה טיפוסיות
שגיאה נפוצה: האתר מחזיר 500 לאחר הפריסה. הסיבה היא OPcache שלא נוקה. פתרון: הוסף קריאה ל-.gitignore בסקריפט. בעיה נוספת: רכיבים חדשים לא עובדים כי קבצים לא נוספו ל-git. בדוק את /bitrix/modules/ /bitrix/components/ /bitrix/wizards/ /upload/ /bitrix/.settings.php /bitrix/php_interface/dbconn.php — הוא לא אמור להחריג את 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')" . קונפליקטים במיגרציות של מסד הנתונים מתרחשים אם השינויים לא מיושמים בסדר. השתמש בסקריפטים של מיגרציה עם חותמות זמן.
שלבי ההתקנה
- בדיקת הפרויקט הנוכחי — הערכת המבנה, זיהוי קבצים להחרגה, הגדרת
opcache_reset(). - יצירת מאגר — אתחול git, חיבור ל-remote (GitHub/GitLab).
- פיתוח סקריפטים לפריסה — כתיבת
.gitignore,local/,.gitignore. - הגדרת CI/CD — יצירת workflow ב-GitHub Actions או pipeline ב-GitLab CI.
- בדיקה והשקה — אימות על staging, ולאחר מכן הפעלה לייצור.
מה כלול בעבודה
- הגדרת מאגר מלאה עם ignores מתאימים
- יצירת סקריפטים לפריסה (איפוס מטמון, OPcache, מיגרציות)
- אינטגרציה עם GitHub Actions / GitLab CI
- הגדרת גלגול אוטומטי לאחור במקרה שגיאה
- תיעוד תהליך והדרכת צוות
- אחריות ל-30 יום לאחר היישום
המומחיות שלנו
אנו עובדים עם Bitrix; המהנדסים שלנו מוסמכים 1C-Bitrix. זמן יישום CI/CD ממוצע הוא 3 עד 7 ימים. הזמינו הגדרת CI/CD לפרויקט שלכם — צרו קשר לייעוץ חינם. קבלו פתרון סוהר עם אחריות לתוצאה. צרו קשר כדי לדון בפרויקט שלכם.