المشكلة: عمليات ترحيل SQL تظل الحلقة الأضعف في DevOps
شيفرة التطبيق تمر عبر طلب سحب: فروق واضحة، ومراجعة إلزامية، وCI خضراء قبل الدمج. أما ترحيل SQL فيصل في الغالب عبر رسالة أو ملف مشترك، ويُشغَّل يدوياً على خادم الإنتاج، وإذا حدث خطأ — تراجع يدوي في أحسن الأحوال.
Bytebase يسد هذه الفجوة. يفرض سير عمل صريح: يرسل المطور الترحيل، يرى المراجع الفروق، وتعمل قواعد lint التلقائية (فهرس مفقود، شرط WHERE مفقود، مخالفات اصطلاحات التسمية)، ثم يُطبَّق الترحيل بالترتيب: بيئة التطوير ← الاختبار ← الإنتاج. كل خطوة مؤرخة وقابلة للبحث في سجل تدقيق غير قابل للتعديل.
ما يضيفه Bytebase لمجموعة أدواتك
- مراجعة SQL منظمة: أكثر من 200 قاعدة مدمجة تكتشف الأنماط المضادة الشائعة قبل وصول الترحيل للإنتاج
- خط أنابيب متعدد البيئات: تطوير ← اختبار ← إنتاج مع بوابات موافقة وتراجع في كل خطوة
- وصول الويب بدون بيانات اعتماد مباشرة: يستعلم المطورون عن الإنتاج عبر محرر SQL في Bytebase — لا تغادر بيانات الاعتماد الخادم أبداً
- سجل تدقيق كامل: كل استعلام وترحيل وموافقة ورفض مسجّل باسم المؤلف والطابع الزمني
- تكامل GitOps: ربط GitHub أو GitLab، يكتشف Bytebase ملفات الترحيل الجديدة ويفتح مهمة مراجعة من طلب السحب
- 20+ محرك مدعوم: PostgreSQL وMySQL وMariaDB وMongoDB وRedis وClickHouse وSQL Server وOracle وTiDB وغيرها
المعمارية: حاوية واحدة، صفر تبعيات خارجية
يعمل Bytebase كحاوية Docker واحدة مع قاعدة بيانات PostgreSQL مدمجة. لا قاعدة بيانات خارجية للتوفير، لا Redis، لا عمال منفصلين — مجرد أمر docker run ومنفذ 8080. الإصدار 3.21.1 (أغسطس 2026) يزن حوالي 120 ميغابايت مضغوطة ويبدأ في أقل من 20 ثانية على خادم بـ 1 غيغابايت RAM.
نشر Bytebase على ServOrbit في 15 دقيقة
اطلب خادم VPS وانشره من السوق
في لوحة تحكم ServOrbit، اختر خطة بـ 1 غيغابايت RAM أو أكثر (2 غيغابايت للفرق)، افتح السوق تحت فئة التطوير وانقر نشر على بطاقة Bytebase. يُثبَّت Docker وتبدأ الحاوية تلقائياً.
إنشاء حساب المسؤول
انتقل إلى https://نطاقك (إن كان نطاق مربوط) أو افتح نفقاً SSH — ssh -L 8080:127.0.0.1:8080 root@<ip> — ثم افتح http://localhost:8080. يدعوك معالج التشغيل الأول لإنشاء حساب المسؤول: البريد الإلكتروني وكلمة المرور.
إضافة أول قاعدة بيانات
في الواجهة، انقر Instances → إضافة حالة. أدخل نوع المحرك (PostgreSQL وMySQL...) والمضيف والمنفذ وبيانات الاعتماد. يختبر Bytebase الاتصال ويكتشف قواعد البيانات والمخططات ويعرضها في الشجرة.
تهيئة البيئات
في Environments، حدد بيئاتك (تطوير، اختبار، إنتاج) وربط كل حالة ببيئتها. يمكنك فرض موافقة بشرية إلزامية لعمليات ترحيل الإنتاج.
إرسال ومراجعة ترحيل
انقر New Issue → تغيير قاعدة البيانات. اكتب SQL الخاص بك، اختر قواعد البيانات المستهدفة، أضف مراجعاً وأرسل. يتلقى المراجع إشعاراً ويرى الفروق ونتائج lint، ثم يوافق أو يطلب تصحيحاً. يطبّق Bytebase بترتيب البيئات ويسجّل كل إجراء.
GitOps: تشغيل المراجعات من طلبات السحب
يتصل Bytebase بمستودع GitHub أو GitLab الخاص بك. هيّئ مسار الترحيل وبطاقة الملف. كل طلب سحب يضيف ملفاً في ذلك المسار يفتح تلقائياً مهمة مراجعة مرتبطة بطلب السحب: حالة الترحيل (معلّق، موافق عليه، مُطبَّق) تظهر مباشرةً في طلب السحب في GitHub.
Bytebase مقابل البدائل
| bytebase | liquibase | flyway | |
|---|---|---|---|
| واجهة مراجعة ويب | ✅ مدمجة | ❌ CLI فقط | ❌ CLI / إضافة |
| Lint SQL تلقائي | ✅ 200+ قاعدة | ⚠️ محدود | ❌ لا |
| وصول SQL ويب آمن | ✅ نعم | ❌ لا | ❌ لا |
| سجل تدقيق | ✅ كامل | ⚠️ أساسي | ⚠️ أساسي |
| استضافة ذاتية، حاوية واحدة | ✅ نعم | ✅ نعم (CLI) | ✅ نعم (CLI) |
الاستخدام الجماعي: وصول بدون بيانات اعتماد مباشرة
للفرق، يحلّ محرر SQL في Bytebase محل الوصول المباشر للإنتاج. تمنح المطورين وصولاً إلى Bytebase — دون إعطائهم بيانات اعتماد قاعدة البيانات. يُوكّل Bytebase جميع الاستعلامات ويفرض سياسات الإخفاء على الأعمدة الحساسة ويحتفظ بسجل كل عملية.
إصدار المجتمع: مجاني وبدون حد للمستخدمين
يغطي إصدار المجتمع سير عمل إدارة التغييرات الكامل ومحرر SQL وسجل التدقيق وتكاملات GitOps. الميزات المؤسسية (SSO، RBAC دقيق، إخفاء البيانات المتقدم، سير عمل الموافقة المخصصة) متاحة في الخطة المدفوعة. لمعظم الفرق ذاتية الاستضافة، يكفي إصدار المجتمع.
