كيف يعمل GitHub على تسريع اعتماد السحابة

نظرة عامة

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

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

يوفر GitHub مجموعة من الميزات التي يمكن أن تساعد الشركات على:

  • استفد من خدمات وقدرات Azure.
  • تحديث ممارساتهم.
  • كن أكثر مرونة وابتكارا خلال هذا التحول الثقافي.

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

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

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

الاستفادة من الأصول مفتوحة المصدر

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

بينما يمكن تفسير OSS على أنها الحزم والمكتبات والبرامج النصية والتبعيات المدمجة في التطبيقات، هناك الآلاف من الأصول مفتوحة المصدر في شكل بنية أساسية كتعليمية (IaC) والوثائق والإرشادات والمخططات لبنى Azure المحددة جيدا. تم المساهمة بهذه المخططات في مجتمع OSS من قبل Microsoft والشركاء والبائعين والعملاء والأفراد، وهي متاحة بسهولة في GitHub. يمكن تعديلها وإعادة استخدامها وتوزيعها بسهولة في بيئة Azure معينة.

البنية الأساسية كتعليمات برمجية

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

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

باستخدام IaC، تجري الفرق تغييرات على وصف البيئة وإصدار نموذج التكوين، والذي يكون عادة بتنسيقات التعليمات البرمجية الموثقة جيدا مثل JSON؛ راجع قوالب Azure Resource Manager لمزيد من المعلومات. يمكن للمطورين تبسيط مهام سير العمل الخاصة بهم عن طريق استضافة التعليمات البرمجية ل IaC في نفس مستودع GitHub مثل التعليمات البرمجية المصدر للتطبيق الخاص بهم واعتماد نفس ممارسات التكامل المستمر (CI) /CD ل IaC المدعومة من GitHub Actions.

راجع إجراء AzOps GitHub للحصول على مثال حول كيفية نشر قوالب Resource Manager المخصصة في نطاقات Azure المختلفة. إذا كنت جديدا على Resource Manager القوالب أو IaC، يمكنك أيضا استعراض azure-quickstart-templates المستودع على GitHub، والعثور على القالب الذي ترغب في نشره، وتحديد الزر Deploy to Azure لاختبار كيفية عمله.

لقطة شاشة لزر Deploy to Azure.

مكونات نمط السحابة وأفضل الممارسات

يسلط الرسم التخطيطي للبنية التالية الضوء على عمليات التحقق من الأمان التي تعمل في مكونات GitHub وAzure لبيئة GitHub DevSecOps:

رسم تخطيطي للبنية يبرز عمليات التحقق من الأمان التي تعمل في مكونات GitHub وAzure لبيئة GitHub DevSecOps.

  • يوفر GitHub نظاما أساسيا لاستضافة التعليمات البرمجية يمكن للمطورين استخدامه للتعاون في مشاريع المصدر المفتوح و InnerSource.

  • Codespaces هي بيئة تطوير عبر الإنترنت. تستضيفها GitHub ويتم تشغيلها بواسطة Microsoft Visual Studio Code، توفر هذه الأداة حلا كاملا للتطوير في السحابة.

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

  • GitHub Actions هي مهام سير عمل مخصصة توفر إمكانات CI/CD مباشرة في المستودعات. تستضيف أجهزة الكمبيوتر المسماة المشغلات مهام CI/CD هذه.

  • Azure Active Directory هي خدمة هوية متعددة المستأجرين تستند إلى السحابة تتحكم في الوصول إلى Azure والتطبيقات السحابية الأخرى مثل Microsoft 365 وGitHub.

  • توفر Azure App Service إطار عمل لإنشاء تطبيقات الويب وتوزيعها وتوسيع نطاقها. توفر هذه المنصة صيانة البنية التحتية المدمجة وترقيع الأمان والتحجيم.

  • تساعد Azure Policy الفرق على إدارة مشكلات تكنولوجيا المعلومات ومنعها من خلال تعريفات النهج التي يمكنها فرض قواعد للموارد السحابية. على سبيل المثال، إذا كان المشروع على وشك نشر جهاز ظاهري مع SKU غير معروف، يرسل نهج Azure تنبيهات حول المشكلة ويوقف التوزيع.

  • يوفر Microsoft Defender for Cloud إدارة أمان موحدة وحماية متقدمة ضد التهديدات عبر أحمال عمل المجموعة المختلطة.

  • يجمع Azure Monitor مقاييس الأداء وسجلات النشاط وبيانات تتبع الاستخدام الأخرى للتطبيق ويحللها. تنبه هذه الخدمة التطبيقات والموظفين عندما تحدد الظروف غير النظامية.

InnerSource

نظرة عامة على InnerSource

تستخدم العديد من الشركات مصطلح InnerSource لوصف كيفية عمل فرقها الهندسية معا على التعليمات البرمجية. InnerSource هي منهجية تطوير حيث يقوم المهندسون ببناء برامج خاصة بأفضل الممارسات من مشاريع مفتوحة المصدر واسعة النطاق مثل Kubernetes أو Visual Studio Code.

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

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

تشريح مشروع InnerSource

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

  • القائمون على الصيانة: هؤلاء المساهمون مسؤولون عن قيادة الرؤية وإدارة الجوانب التنظيمية للمشروع. قد لا يكونوا المالكين الأصليين أو مؤلفي التعليمات البرمجية.

  • المساهمين: هؤلاء الأشخاص هم كل من ساهم بشيء في المشروع.

  • أعضاء المجتمع: هؤلاء هم الأشخاص الذين يستخدمون المشروع. قد يكونوا نشطين في المحادثات أو يعبرون عن آرائهم حول اتجاه المشروع.

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

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

  • القائمون على الصيانة: المطورون ومديرو المنتجات وغيرهم من صانعي القرار الرئيسيين داخل شركة مسؤولة عن قيادة رؤية المشروع وإدارة المساهمات اليومية.

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

لمزيد من المعلومات، راجع المستند التقني مقدمة إلى InnerSource.

Automation

تسمح إجراءات GitHub للمستخدمين بإنشاء مهام سير عمل مخصصة مباشرة في مستودعات GitHub الخاصة بهم. يمكن للمستخدمين اكتشاف الإجراءات وإنشاءها ومشاركتها لأداء أي مهمة، بما في ذلك CI/CD، ودمج الإجراءات في سير عمل مخصص تماما. يمكنهم أيضا إنشاء مهام سير عمل CI التي تنشئ وتختبر المشاريع المكتوبة بلغات برمجة مختلفة. تتوفر أمثلة في أدلة GitHub Actions.

يمكن استخدام GitHub Actions لدمج مفاهيم IaC وممارسات CI/CD لأتمتة دورة حياة النشر الشاملة بالكامل، بما في ذلك توفير البيئة المستهدفة أو تحديثها بطريقة قابلة للتكرار وتغليف التطبيق نفسه ونشره.

مثال:

تم إنشاء إجراءات GitHub ل Azure لتبسيط كيفية أتمتة عمليات التوزيع لاستهداف خدمات Azure مثل Azure App Service وAzure Kubernetes Service وAzure Functions والمزيد. يتضمن مستودع مهام سير عمل إجراء Azure البداية مهام سير عمل شاملة لإنشاء تطبيقات الويب وتوزيعها من أي لغة وأي نظام بيئي إلى Azure. تفضل بزيارة سوق GitHub للاطلاع على جميع الإجراءات المتوفرة.

الأمان

ميزات أمان GitHub من shift-left

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

مع العديد من قدرات الأمان، GitHub توفر الأدوات التي تدعم كل جزء من سير عمل DevSecOps:

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

مثال:

تغطي عمليات تثبيت DevSecOps من GitHub العديد من سيناريوهات الأمان. وتشمل الاحتمالات الحالات التالية:

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

لمزيد من المعلومات، راجع:

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

  • اختر فريق التنفيذ (عادة ما يكون مدير مطور وعدد قليل من المطورين الذين تم تعريفهم كمسؤولين)، وانشر GitHub.
  • تعرف على مهام سير عمل Git الشائعة والمتقدمة لتحسين كيفية استخدام GitHub.

توفر الارتباطات التالية المزيد من المعلومات حول GitHub.

  • Last updated on