Cursor تطلق بيئات للوكلاء السحابيين: دعم المستودعات المتعددة وإدارة الإصدارات

قدّمت Cursor أدوات جديدة لإعداد بيئات التطوير (development environments) الخاصة بالوكلاء السحابيين للمطورين. وتتلخص المشكلة الأساسية في أن الوكيل الذي يستطيع كتابة الشيفرة لكنه لا يستطيع تشغيل الاختبارات أو الاتصال بواجهات API أو تنفيذ عملية البناء، لا فائدة منه. فالوكلاء السحابيون بحاجة إلى بيئات تشبه حاسوبك المحمول، أي مستودعات مستنسخة وتبعيات مثبّتة ووصول إلى واجهات API وأنظمة البناء.

بيئات متعددة المستودعات

في الشركات الكبرى تتوزع الشيفرة البرمجية على عشرات المستودعات. وتتطلب بنية الخدمات المصغّرة (microservices) تعديل الشيفرة في عدة أماكن في الوقت نفسه؛ فواجهة API جديدة يجب دمجها في ثلاث خدمات مصغّرة، وإضافتها إلى قاعدة البيانات، وتحديث الواجهة الأمامية. أضافت Cursor دعم البيئات متعددة المستودعات (multi-repo environments)، وبذلك بات بإمكان وكيل واحد رؤية جميع المستودعات التي يحتاج إليها في آنٍ واحد، وفهم كيف يؤثر التغيير في جزء من المشروع على الأجزاء الأخرى.

وهذا مفيد بوجه خاص للمؤسسات الكبيرة. تستخدم شركة Amplitude أداة Cursor Automations في قنوات Slack الخاصة بها. وبحسب ستيفن تشين، كبير مديري الهندسة (Senior Engineering Manager) في Amplitude، يستطيع الوكيل تحليل المشكلة، وتحديد المستودعات المعنية بها بنفسه، وفتح طلب سحب (PR) يتضمن الإصلاح في الأماكن اللازمة بسياق كامل.

ما الذي يتيحه دعم المستودعات المتعددة:

• يرى الوكيل الروابط بين المستودعات والخدمات المصغّرة المختلفة
• يستطيع فتح طلبات سحب (PR) بتغييرات في عدة أماكن في وقت واحد
• يعيد استخدام البيئة نفسها عبر الجلسات، ولا يعيد إنشاءها من الصفر
• يحصل على السياق الكامل للمشروع اللازم للمهام المعقّدة
• يعمل مع أدوات تتطلب الوصول إلى عدة مستودعات في آنٍ واحد

إعداد Docker والبناء التلقائي

حسّنت Cursor دعم الإعداد القائم على ملفات Dockerfile للبيئات السحابية. والجديد هو أسرار البناء (build secrets)، وهي طريقة آمنة لتمرير المفاتيح الخاصة بسجلات الحزم (package registries) مباشرة داخل Dockerfile. وتُستخدم هذه الأسرار أثناء بناء الصورة فقط، ولا تصل إلى بيئة عمل الوكيل.

وسرّع التخزين المؤقت للطبقات (layer caching) عمليات البناء بنسبة 70%، إذ لا تُعاد سوى الطبقات التي تغيّرت. ويكتسب ذلك أهمية حاسمة عند التحديث المتكرر للبيئة.

وإذا لم تكن ترغب في كتابة Dockerfile من الصفر، فبإمكان Cursor إنشاءه تلقائيًا. إذ يفحص النظام مستودعاتك، ويحدد الأدوات والتبعيات اللازمة، ويُخرج إعدادًا جاهزًا لإدارة الإصدارات. هذه الميزة ما زالت في مرحلة تجريبية خاصة (private beta)، ويجري طرحها تدريجيًا لعملاء Enterprise.

إدارة الإصدارات والتدقيق والأمان

باتت Cursor تفهم بصورة أفضل حالة بيئة التطوير أثناء العمل. فعند الإعداد، يطرح النظام أسئلة، ويبرز بيانات الاعتماد (credentials) الناقصة، ويتحقق من صحة الإعداد. ويرى الوكيل في أي إصدار من البيئة يعمل.

وأُضيفت آلية لزيادة الموثوقية: إذا لم ينجح الإعداد، فلا يتعطل الوكيل، بل ينتقل إلى صورة أساسية مع تحذيرات. وأُضيف لكل بيئة سجل إصدارات، يمكن من خلاله استعراض التغييرات والتراجع إلى إصدار أقدم. ويمكن للمسؤولين حصر صلاحية التراجع (rollback) بأنفسهم فقط.

ويسجّل سجل التدقيق (audit log) كل إجراء. وأصبحت قواعد الدخول (ingress) والأسرار (secrets) مرتبطة بمستوى بيئة التطوير الواحدة. ويمكن للفريق منح مستويات وصول مختلفة إلى بيئات مختلفة؛ فمثلًا قد يتاح لبيئة staging الوصول إلى واجهات API الإنتاجية، بينما تقتصر بيئة dev على الخدمات الوهمية (mock).

ماذا يعني ذلك

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