Databricks يوضح تفرّع Lakebase للوكيلات البرمجية المتوازية

Databricks في 8 أكتوبر 2026، نشر مقالًا في مدونة يوضح سير عمل تطوير يتم فيه تشغيل كل وكيل برمجي متوازي وكل طلب سحب ضد قاعدة بيانات Postgres خاصة ومعزولة ومؤقتة، تم إنشاؤها عبر تفرّع النسخ عند الكتابة المدمج في خدمة قاعدة البيانات Lakebase الخاصة به.

في المقال، تصف Databricks قاعدة البيانات كجزء غالبًا ما يُهمل في سير عمل التطوير في وقت يتولى فيه وكلاء البرمجة حصة متزايدة من العمل التطويري ويصبح تشغيل عدة وكلاء بشكل متوازي هو القاعدة. مع البيئات المشتركة التقليدية، مثل قاعدة بيانات تطوير أو اختبار واحدة، يمكن للوكلاء المتزامنين أن يتصادموا على تغييرات المخطط، أو يتداخلوا مع بعضهم البعض، أو يلجأوا إلى نماذج تجريبية لا تعكس البيانات الواقعية. كانت هذه بالفعل نقاط ألم للمطورين، حسب ما يذكر المقال، لكن الوكلاء يزيدون من حدتها لأنهم يتحركون أسرع، يعملون بشكل متوازي، ويحتاجون إلى بيئة آمنة تُجنب تعريض بيانات الإنتاج للخطر أو كشف البيانات الحساسة.

آليات التفرّع

تقول Databricks إن تفرّع Lakebase يتيح للمستخدم إنشاء فرع لقاعدة بيانات كاملة في أقل من ثانية، بغض النظر عن حجمها. تعتمد الفروع على تخزين النسخ عند الكتابة: يرث الفرع الجديد مخطط وبيانات الفرع الأصلي مع مشاركة التخزين الأساسي، ويستهلك مساحة إضافية فقط عندما يختلف. وفقًا وثائق تفرّع Lakebase الخاصة بـ Databricks، يتم إنشاء كل مشروع بفرع افتراضي يُسمّى الإنتاج، وكل فرع باستثناء الفرع الجذري له أب. لا تؤثر التغييرات في فرع فرعي على أبويه، وتمتد العزلة إلى حالة دور Postgres: الأدوار وقواعد البيانات التي تم إنشاؤها، ومنح الصلاحيات GRANTs وإلغاء الصلاحيات REVOKEs المطبقة، وتعديل سمات الدور في فرع واحد لا يؤثر على الفروع الأخرى.

كل فرع يمتلك حوسبة خاصة به، ويتقلص إلى صفر عند الخمول، وتُفوَّض فقط لساعات الحوسبة النشطة، وفقًا للوثائق. تعتمد فاتورة التخزين على ما إذا كان الفرع منتهي الصلاحية: يُفوَّض للفرع المنتهي فقط مقابل البيانات التي تم تعديلها فيه، بينما يُفوَّض للفرع الدائم بدون انتهاء صلاحيته مقابل حجمه الكامل من البيانات، كقاعدة بيانات مستقلة. إعادة ضبط الفرع، التي تُعيد تحديث فرع فرعي من أبويه، تعمل في اتجاه واحد فقط، من الأب إلى الطفل. استعادة النقطة الزمنية تُنشئ فرعًا جذريًا جديدًا من البيانات التاريخية ضمن نافذة الاستعادة مع ترك الفرع الأصلي دون تغيير وقابل للتشغيل.

على صفحة المنتج الخاصة به، تصف Databricks Lakebase كخدمة Postgres مُدارة بالكامل وخالية من الخوادم، تشغّل محرك Postgres المفتوح المصدر بدلاً من نسخة مفرّعة.

فرع لكل وكيل

يربط سير العمل في المقال بين مسارات عمل Git وفروع Lakebase. تُوفر مسار العمل لكل وكيل دليلًا خاصًا به مع فرع مُستخرج، مما يزيل تعارضات مستوى الملفات بين الوكلاء، ثم يُنشئ خطاف ما بعد الاستخرج فرع قاعدة بيانات لكل مسار عمل جديد تلقائيًا. في المثال، المبني باستخدام Claude Code، يُشغّل وكيل claude -worktree feature-123، يُنشئ Git مسار العمل، يُفعّل الخطاف، وينتهي الأمر بالوكيل بدليل شفرة خاص به وقاعدة بيانات معزولة تمامًا. تُرشد ملفات تعليمات المستودع مثل AGENTS.md أو CLAUDE.md سلوك الوكيل، وعند انتهاء الوكيل يفتح طلب سحب، وبعد ذلك يمكن إيقاف كل من مسار العمل وفرع قاعدة البيانات.

يُشير المقال إلى أن أحد الاختلافات عن Git هو أن فروع Lakebase لا تُدمج مرة أخرى إلى الفرع الرئيسي، لأن الأب والطفل يمكن أن يتغيّرا بشكل مستقل وتصبح مطابقة بياناتهما عملية غير عملية بسرعة. بدلاً من ذلك، تُتبع تغييرات المخطط في الشيفرة إلى جانب منطق التطبيق وتُرقّى إلى الفرع الأب عبر عمليات الترحيل، باستخدام أدوات مثل Drizzle أو Flyway أو Liquibase أو Alembic. يستخدم المثال Drizzle: عندما تكون هناك حاجة لتغيير مخطط، يضيف الوكيل الترحيل المقابل إلى قاعدة الشيفرة، وتطبق أتمتة النشر ذلك عند نشر التطبيق التجريبي ومرة أخرى عندما يندمج التغيير في الرئيسي.

فرع لكل طلب سحب

للتكامل المستمر، يوضح المقال سير عمل GitHub Actions حيث يؤدي فتح طلب سحب ضد الرئيسي إلى تشغيل أداة سطر أوامر Lakebase لإنشاء فرع مؤقت، يُسمّى باسم طلب السحب، كفرع فرعي للفرع الإنتاجي، ويصبح ذلك الفرع بيئة قاعدة البيانات الخاصة بطلب السحب. تُشغّل أداة الترحيل ضد الفرع الجديد، يُنشر تطبيق تجريبي ويوجه إلى سلسلة اتصال الفرع، وتُولّد مقارنة مخطط تُنشر كتعليق على طلب السحب تُظهر بالضبط الجداول أو الأعمدة أو الفهارس التي تغيرت. عند إغلاق أو دمج طلب السحب، تحذف الأتمتة الفرع. وبما أن الفرع يبدأ من الإنتاج، يمكن تطبيق واختبار ترحيل المخطط قبل وصول التغيير إلى الإنتاج. ينشر المثال معاينات على تطبيقات Databricks، رغم أن المقال يذكر أن المفهوم ينطبق على منصات استضافة أخرى مثل Vercel و Netlify و Cloudflare.

فيما يتعلق بالبيئات، يذكر المقال أن إعداد Lakebase الشائع يستخدم مساحة عمل Databricks واحدة لكل بيئة، مثل التطوير والاختبار والإنتاج، وأن الفرق عادةً ما تُنشئ فروعًا من قاعدة بيانات مُهيّأة مسبقًا بدلاً من قاعدة الإنتاج لتجنب كشف البيانات الحساسة مثل المعلومات الشخصية (PII). يستخدم الشرح مساحة عمل واحدة للتبسيط مع الإشارة إلى أن نفس المفاهيم تنطبق على إعدادات متعددة المساحات.

إعادة إنتاج الأخطاء واختبار الترحيل

بعيدًا عن حلقات كل وكيل وكل طلب سحب، يصف المنشور سير عمل الفروع التي لم تُنفَّذ في مستودع المثال. يمكن للمطور إنشاء فرع معزول من الإنتاج في نقطة زمنية محددة، عادةً قبل ظهور خطأ، وإعادة إنتاجه والتحقق من المشكلة باستخدام بيانات حقيقية، ثم إيقاف الفرع بمجرد التحقق من صحة الإصلاح. يمكن للفرق أيضًا إنشاء فرع قبل النشر إلى الإنتاج، وتطبيق ترحيل مخطط، وتشغيل الاختبارات، والتحقق من أن التطبيق لا يزال يعمل كما هو متوقع قبل ترقية التغيير. تسمح هذه سيرات العمل للمطورين بالعمل ببيانات شبيهة بالإنتاج أو مشتقة من الإنتاج، باستخدام إخفاء Unity Catalog على سبيل المثال، دون تعريض قاعدة البيانات الحية للخطر، وفقًا للمنشور.

يرتبط المنشور بمستودع مثال على GitHub، في دليل Lakebase-Agentic-CI من مستودع databricks/tmm، الذي يحتوي على أمثلة سير عمل GitHub Actions تُطبق النمط. ويستنتج أن هذه الأنماط معًا تشكل ما يسميه حلقة تطوير Lakebase: فرع لكل وكيل، وفرع لكل طلب سحب، وفروع معزولة للتحقق من صحة الإنتاج.