مشاركة عبر

تقديم إثبات المفهوم لنشر مؤسسة Azure DevTest Labs

  • مقالة

تعتمد الشركات السحابة بسرعة بسبب الفوائد التي تشمل السرعة والمرونة والاقتصاد. غالبًا ما تكون الخطوات الأولى هي التطوير واختبار أعباء العمل. توفر Azure DevTest Labs ميزات تفيد المؤسسة وتدعم سيناريوهات التطوير/الاختبار الرئيسية.

توضح هذه المقالة كيف يمكن للمؤسسة تقديم إثبات ناجح للمفهوم أو الإصدار التجريبي لنشر Azure DevTest Labs. يستخدم إثبات المبدأ جهدًا مركزًا من فريق واحد لإنشاء قيمة مؤسسية.

لكل مؤسسة متطلبات مختلفة لدمج Azure DevTest Labs في مؤسستها. إثبات المفهوم هو خطوة أولى نحو نشر ناجح من طرف إلى طرف.

للحصول على إثبات ناجح للمبدأ:

  1. اختر فريقًا أو فريقين.
  2. تحديد سيناريوهات الفرق، مثل الأجهزة الظاهرية للمطور (VMs) أو بيئات الاختبار.
  3. وثّق حالات الاستخدام الحالية.
  4. نشر مختبرات DevTest لتحقيق سيناريوهات الفرق وحالات الاستخدام.
  5. تقييم النجاح والدروس المستفادة.

تتضمن سيناريوهات DevTest Labs الرئيسية تطوير السحابة واختبارها وبيئات التدريب. تشمل حالات الاستخدام ما يلي:

  • إنشاء أسطح مكتب المطور.
  • تكوين بيئات الاختبار.
  • تمكين VM والوصول إلى موارد Azure.
  • إعداد بيئة الاختبار المعزولة للتعلم والتجريب.
  • تكوين نهج المختبر وضوابط التكلفة التي تتوافق مع لوائح الشركة.

المتطلبات الأساسية

لإكمال إثبات المفهوم لـ DevTest Labs بنجاح، يجب استيفاء المتطلبات الأساسية التالية:

تعرف على الأساسيات

تعرف على Azure وDevTest Labs باستخدام الموارد التالية:

فهم مجالات تركيز المؤسسة

تتضمن المخاوف الشائعة للمؤسسات التي تقوم بترحيل أحمال العمل إلى السحابة ما يلي:

الحصول على اشتراك Azure

  • يمكن للمؤسسات التي لها اتفاقية Enterprise موجودة تمكن الوصول إلى Azure استخدام اشتراك موجود أو جديد لـ DevTest Labs. إذا كان هناك اتفاقية Enterprise موجودة، يمنحك اشتراك Enterprise Dev/Test إمكانية الوصول إلى أنظمة تشغيل العميل Windows 10/Windows 8.1، ومعدلات مخفضة لأحمال عمل التطوير والاختبار.

  • بدلاً من ذلك، يمكنك استخدام اشتراك Visual Studio للتوزيع التجريبي، والاستفادة من أرصدة Azure المجانية.

  • يمكنك أيضًا إنشاء واستخدام حساب Azure مجاني للطيار.

  • لاستخدام Windows صور نظام التشغيل العميل (Windows 7 أو إصدار أحدث) لتطوير أو اختبار Azure، نفذ أحد الخطوات التالية:

    لمزيد من المعلومات حول اعتمادات Azure لكل عرض MSDN، راجع رصيد Azure الشهري للمشتركين في Visual Studio.

تسجيل جميع المستخدمين في معرف Microsoft Entra

للإدارة، مثل إضافة مستخدمين أو إضافة مالكي مختبر، يجب أن ينتمي جميع مستخدمي المختبر إلى مستأجر معرف Microsoft Entra لاشتراك Azure الذي يستخدمه الإصدار التجريبي. تقوم العديد من المؤسسات بإعداد هوية مختلطة لتمكين المستخدمين من استخدام هوياتهم المحلية في السحابة. لا تحتاج إلى هوية مختلطة لدليل DevTest Labs على المفهوم.

تحديد نطاق إثبات المفهوم

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

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

قم بهذه المهام لتحديد نطاق الإصدار التجريبي:

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

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

اتخاذ قرارات أخرى للتخطيط والتصميم

يتضمن حل DevTest Labs الكامل بعض قرارات التخطيط والتصميم المهمة. يمكن أن يساعدك إثبات المفهوم في اتخاذ هذه القرارات. وتشمل الاعتبارات الأخرى ما يلي:

طوبولوجيا الاشتراك

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

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

طبولوجيا الشبكة

قد لا تفي البنية الأساسية الافتراضية للشبكة التي ينشئها DevTest Labs تلقائيًا بالمتطلبات والقيود لمستخدمي المؤسسة. على سبيل المثال، غالبًا ما تستخدم المؤسسات:

لمزيد من المعلومات، راجع مكونات الشبكات.

يدعم DevTest Labs أيضًا إضافة شبكات ظاهرية موجودة إلى المختبر لاستخدامها لإنشاء أجهزة ظاهرية جديدة. للحصول علي المزيد من المعلومات، راجع إضافة شبكة ظاهرية في Azure DevTest Labs.

الوصول عن بعد للجهاز الظاهري

هناك العديد من الخيارات لمستخدمي المؤسسة للوصول عن بعد إلى أجهزة DevTest Labs الظاهرية:

الوصول إلى المختبر والأذونات

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

إكمال إثبات المفهوم

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

مثال على خطة إثبات المفهوم

يوضح هذا المثال التالي خطة تحديد نطاق نشر إثبات المفهوم لـ DevTest Labs.

نظرة عامة

تخطط المؤسسة لتطوير بيئة Azure DevTest Labs جديدة للموردين لاستخدامها، والتي يتم عزلها عن شبكة الشركة. لتحديد ما إذا كان الحل سيلبي المتطلبات، تطور المؤسسة إثباتًا للمفهوم للتحقق من صحة السيناريو الشامل.

الأهداف

إثبات المفهوم له الأهداف التالية:

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

المتطلبات

يتضمن الحل المتطلبات التالية:

  • يمكن لفرق الموردين استخدام مجموعة من المختبرات في Azure DevTest Labs.
  • يمكن للموردين الوصول إلى المختبرات عبر معرف Microsoft Entra وتعيينات الأدوار.
  • لدى الموردين طريقة للاتصال بمواردهم بنجاح، مثل VPN من موقع إلى موقع الذي يتيح الوصول إلى الأجهزة الظاهرية دون استخدام عناوين IP العامة.
  • تتصل المختبرات ببنية أساسية للشبكة تدعم المتطلبات.
  • يقوم DevTest Labs بتثبيت مجموعة أدوات البرامج التي يحتاجها الموردون على الأجهزة الظاهرية.

المتطلبات الأساسية

  • اشتراك لاستخدامه للمشروع
  • مستأجر Microsoft Entra، وMicrosoft Entra Global مسؤول istrator الذي يمكنه توفير تعليمات وإرشادات معرف Microsoft Entra
  • طرق تعاون أعضاء المشروع، مثل:
    • مستودعات Azure Repos للتعليمات البرمجية المصدر والبرامج النصية
    • Microsoft Teams أو SharePoint للمستندات
    • Microsoft Teams للمحادثات
    • Azure Boards لعناصر العمل

مهام الإعداد

  • حدد منطقة Azure التي يجب استخدامها لإثبات المفهوم.
  • حدد ما إذا كنت تريد الانضمام إلى الأجهزة الظاهرية للمختبر إلى مجال Microsoft Entra، وما إذا كان يجب استخدام Microsoft Entra Domain Services أو أسلوب آخر.
  • تحديد الموردين الذين سيستخدمون بيئة إثبات المفهوم.
  • حدد الموارد المطلوبة للموردين، مثل البرامج المتوفرة على الأجهزة الظاهرية.
  • حدد خدمات Azure، بخلاف الأجهزة الظاهرية، التي يمكن للموردين استخدامها في DevTest Labs.
  • خطط لكيفية تدريب البائعين على استخدام المختبر.

الخطوات التالية