تصميم النظام الأساسي للخدمة الذاتية للمطور

مكتمل

تعتمد تجربة الخدمة الذاتية للمطور على مجموعة من المفاهيم والأنماط والأدوات، والتي تمتد عبر تقنيات مصممة خصيصا وغير جاهزة ومفتوحة المصدر. الهدف هو تمكين المطورين من تنفيذ المهام المحكومة وتوفيرها مع الحفاظ على الرؤية المركزية. يجب أن يكون التركيز الأساسي على المهام المملة أو المعقدة جدا بحيث لا يمكن للمطورين التعامل معها بشكل مستقل.

مكونات النظام الأساسي للخدمة الذاتية للمطور

يتكون أساس الخدمة الذاتية للمطور من عدة مكونات رئيسية تعمل معا لتبسيط مهام سير عمل المطور وأتمتتها. تتضمن هذه المكونات واجهة برمجة تطبيقات النظام الأساسي للمطور ورسم بياني للنظام الأساسي للمطور ومنسق النظام الأساسي للمطور وموفري النظام الأساسي للمطور وملف تعريف المستخدم وبيانات تعريف الفريق.

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

استكمال واجهة برمجة تطبيقات النظام الأساسي للمطور هو مخطط النظام الأساسي للمطور، وهو بنية بيانات آمنة مدارة تسهل اكتشاف الكيانات والقوالب وارتباطها داخل النظام الأساسي. تقوم الكيانات بتجميع البيانات من مصادر متعددة، بينما توجه القوالب مدخلات المستخدم للأتمتة.

يسمح لك الرسم البياني للنظام الأساسي للمطور بربط الكيانات والقوالب من موفرين متعددين ببنية قابلة للبحث. في حين أن بيانات هذه الكيانات لا تحتاج إلى تخزينها مباشرة في قاعدة بيانات الرسم البياني، يمكن تخزين التفاعلات مع الموفرين مؤقتا مع بيانات التعريف الضرورية. يصبح هذا الرسم البياني ذا قيمة خاصة عند العمل مع الكيانات المشتركة التي يساهم بها موفرون متعددون. على سبيل المثال، قد تأتي واجهات برمجة التطبيقات من Azure API Center، بينما قد يتم سحب عمليات التوزيع والبيئات من أنظمة التوزيع المستمر. يقوم الرسم البياني بتمكين تجارب المستخدم من خلال واجهة برمجة تطبيقات مشتركة، ما يتيح الاكتشاف والبحث والحوكمة.

لتنفيذ الإجراءات المستندة إلى القالب، يقوم Developer Platform Orchestrator بتوجيه الطلبات وتعقبها، بالتنسيق مع موفري النظام الأساسي للمطورين المتخصصين الذين يتكاملون مع أنظمة انتقال البيانات من الخادم. يمكن المنسق المطورين أو الأنظمة من طلب الإجراءات باستخدام القوالب، دون تنفيذ الإجراءات مباشرة. وهو ينسق مع محرك مهام أو محرك سير عمل أو منسق آخر لتنفيذ الإجراءات. هذا المكون ضروري لتمكين الخدمة الذاتية، لأنه يسمح للمطورين بتشغيل الإجراءات دون الحاجة إلى أذونات مباشرة. على عكس CI/CD، لا تقتصر هذه الإجراءات على التعليمات البرمجية المصدر للتطبيق. يمكن أن تعمل محركات سير العمل مثل GitHub Actions أو Azure Pipelines كمنسقين، ولكن يمكن أن يكون التجريد مفيدا لدعم محركات مختلفة بمرور الوقت. تسمح هذه المرونة بترحيل المحرك، وتدعم الخطوات اليدوية للعمليات التي قد تكون تلقائية لاحقا، وتستوعب الإجراءات التي تستهدف الأدوار غير الإنمائية (على سبيل المثال، الحسابات الدائنة). بالإضافة إلى ذلك، يمكن معالجة المهام الأبسط عبر طلبات HTTP، وتجنب الحاجة إلى محركات معقدة.

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

يتضمن الأساس أيضا قدرات لإدارة ملف تعريف المستخدم وبيانات تعريف الفريق، والتي تربط معلومات الأفراد والفريق بالحسابات التي يستضيفها موفر الهوية، مثل معرف Microsoft Entra. يتم استخدام بيانات التعريف هذه لتجميع والتحكم في الوصول داخل واجهة برمجة تطبيقات النظام الأساسي للمطور. في حين أنه سيكون من الممكن تخزين هذه المعلومات في مخطط النظام الأساسي للمطور، فإن فصلها يضمن الوضوح.

يمكن الوصول إلى أساس الخدمة الذاتية للمطور عبر واجهة مستخدم مركزية/تجربة مستخدم (UI/UX). يوفر نقطة وصول موحدة يبسط التفاعلات للمطورين، ما يسهل استخدام مهام سير العمل والموارد بطريقة سلسة وبديهية.

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

مفاهيم موفر النظام الأساسي للمطور الرئيسية

في النظام الأساسي للمطورين، تعتمد الإدارة الفعالة وتنسيق الموارد على استخدام الكيانات جنبا إلى جنب مع خصائصها وقوالبها. توفر هذه المفاهيم الرئيسية البنية والأتمتة، ما يتيح التكامل السلس عبر موفري الخدمات المختلفين ويسهل سير العمل والحوكمة المتسقين.

الكيانات

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

خصائص عامة

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

الكيانات الخاصة المشتركة والموفر

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

القوالب

تم تصميم القوالب لدفع إجراءات مثل توفير البنية الأساسية أو إنشاء المستودع أو العمليات الأخرى طويلة الأمد. تتوفر هذه القوالب من خلال موفري النظام الأساسي للمطورين وتتضمن خصائص شائعة مثل اقترانات الكيانات والمدخلات المطلوبة (على سبيل المثال، أسماء الموارد). يمكن أن تمثل القوالب تنسيقات مختلفة، بما في ذلك قوالب البنية الأساسية كتعليمة برمجية (IaC) أو قوالب التطبيق أو البرامج النصية ذات المعلمات. غالبا ما تكون خاصة بالموفر، مع تمثيلات مختلفة اعتمادا على التكنولوجيا المستخدمة. تتضمن أمثلة هذه التمثيلات قوالب Terraform أو Bicep أو مخططات Helm أو مهام سير عمل GitHub Actions ذات المعلمات أو خطوط أنابيب Azure أو البرامج النصية البسيطة أو التنسيقات المخصصة المصممة خصيصا لنظم إيكولوجية محددة للموفر.

على الرغم من أن القوالب لا تحتاج إلى تخزين مركزي، يجب أن تكون قابلة للوصول عبر موفر لضمان وصول متسق عبر النظام الأساسي. يمكن أن توجد في مستودعات أو سجلات أو كتالوجات مختلفة اعتمادا على حالة الاستخدام. على سبيل المثال، قد يتم استخدام مستودعات قوالب GitHub لقوالب التطبيقات، بينما يمكن أن تتواجد قوالب IaC في مستودع كتالوج مقيد يصل إليه المطورون بشكل غير مباشر من خلال أدوات مثل Azure Deployment Environments. قد يتم تخزين قوالب IaC الأخرى في سجل بيانات اصطناعية لمبادرة الحاوية المفتوحة (OCI)، مثل مخططات Helm. في بعض الحالات، قد يشير القالب ببساطة إلى نقطة نهاية HTTP ذات معلمات.

عادة ما يؤلف مهندسو النظام الأساسي أو المتخصصون في المجال هذه القوالب ويشاركونها مع فرق التطوير لإعادة استخدامها. يسهل مركزية استخدام القوالب داخل النظام الوصول إليها مع فرض المعايير والسياسات التنظيمية. تساعد هذه العملية في الحفاظ على التحكم والامتثال عبر النظام الأساسي مع تمكين المطورين من العمل بشكل أكثر كفاءة.

إجراءات GitHub كموفري النظام الأساسي

لتوضيح كيفية عمل الموفر، دعونا نفكر في إجراءات GitHub وAzure Pipelines. يمكن لأي منهما أن يعمل كموفر نظام أساسي للمطورين عن طريق تشغيل مهام سير العمل أو تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية من خلال واجهات برمجة التطبيقات الخاصة بها، مثل GitHub Actions REST API أو Azure DevOps Pipeline API. لا يلزم وضع مهام سير العمل أو المسارات هذه في مستودعات التعليمات البرمجية المصدر للتطبيق، ما يسمح لمهندسي النظام الأساسي بالاحتفاظ بها في المستودعات المركزية والخاصة. في هذا النموذج، لا يملك المطورون وصولا مباشرا إلى مهام سير العمل ولكن يمكنهم استخدام موفر النظام الأساسي للمطورين للتفاعل معهم. يمكن للموفر إدارة الأسرار الضرورية، مثل بيانات الاعتماد أو مفاتيح واجهة برمجة التطبيقات، من خلال التكامل مع خدمات مثل Azure Key Vault. أثناء تنفيذ مهام سير العمل، يتتبع الموفر حالته، باستخدام خطافات الويب لإجراءات GitHub وخطافات الخدمة ل Azure Pipelines لمراقبة التقدم. بمجرد اكتمال سير العمل، يتم التقاط ونشر أي بيانات اصطناعية يتم إنتاجها، مثل نتائج الإنشاء أو التوزيع. يمكن إضافة هذه البيانات الاصطناعية، جنبا إلى جنب مع معلمات الإدخال والمراجع إلى مهام سير العمل، إلى الرسم البياني للنظام الأساسي للمطور. يسمح هذا النهج أيضا بالمرونة في استخدام واجهات CLIs العشوائية، ما يدعم مجموعة واسعة من مهام الأتمتة بمرور الوقت. بالإضافة إلى ذلك، فإن استخدام GitHub Actions أو Azure Pipelines في هذا السياق مستقل عن دورها التقليدي في CI/CD، ما يوفر إمكانية تطبيق أوسع لإدارة العمليات والقوالب المختلفة.

هناك أنواع أخرى من موفري النظام الأساسي للمطورين، والتي يمكنها التعامل مع المهام المختلفة من خلال القوالب. بالنسبة لعمليات التحكم بالمصادر، يمكن للموفرين المساعدة في إدارة مهام Git مثل إنشاء المستودعات أو إرسال PRs أو عمليات Git الأخرى دون الاعتماد على محركات سير العمل العامة. يمكن تبسيط توفير البنية الأساسية من خلال موفرين مخصصين مثل Azure Deployment Environments أو Terraform Cloud، مع التركيز على البنية الأساسية كتعليمة برمجية (IaC) مع الأمان والكفاءة. يدعم موفرو دعم التطبيقات، مثل Azure Developer CLI، إنشاء أشجار مصدر التطبيق ودفعها إلى مستودعات المصدر، ما يضيف مرونة للأنظمة البيئية المختلفة. يمكن أيضا إدارة العمليات اليدوية، مثل إنشاء طلبات السحب (PRs) أو أتمتة مهام سير العمل لغير المطورين، من خلال موفرين يستندون إلى القالب، ما يسمح بالأتمتة التدريجية. تسلط هذه الأمثلة الضوء على كيف يمكن للتوسعة وقابلية التكيف في موفري النظام الأساسي للمطورين تحسين قدرات الأتمتة بمرور الوقت.