التوسع أكثر

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

الرؤية والفهم

في جميع الشركات باستثناء أصغرها، لا يتّخذ المطوّرون وحدهم قرارات ما الذي يجب تطويره. غالباً ما يُستخدم مصطلح «صاحب المصلحة» (stakeholder) للإشارة إلى أشخاص، داخل فريق التطوير وخارجه، قد تكون لديهم مصلحة في متابعة تقدّم التطوير. وتحقيقاً لذلك، توجد غالباً تكاملات بين Git وأي برنامج لإدارة المشاريع/تتبّع الأخطاء يستخدمه الفريق.

من الاستخدامات الشائعة لذلك وجود إشارة ما إلى نظام التتبّع في طلبات السحب أو الـ commits في Git. بهذه الطريقة، مثلاً، عندما تعمل على المشكلة رقم 123، قد تسمّي طلب السحب BUG-123: إصلاح مشكلة نسخ المستخدم، فيلاحظ نظام تتبّع الأخطاء الجزء الأول من اسم طلب السحب وينقل المشكلة تلقائياً إلى تم عند دمج طلب السحب.

الإشعارات

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

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

هناك عدة حلول لهذه المشكلة تتراوح بين إشعارات بسيطة وعمليات أكثر تعقيداً تدمج ببساطة الشيفرة الناجحة إذا تحققت شروط معيّنة. سنناقش الإشعارات كحل بسيط لأنها الأقل تدخلاً في سير عمل الفريق.

افتراضياً، يرسل GitHub Actions بريداً إلكترونياً عند فشل البناء. يمكن تغيير ذلك لإرسال إشعارات بغض النظر عن حالة البناء، ويمكن أيضاً إعداده لتنبيهك في واجهة GitHub على الويب. رائع. لكن ماذا لو أردنا المزيد؟ ماذا لو لم يناسبنا هذا لأي سبب كان في حالة استخدامنا.

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

المقاييس

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

رغم وجود أمور يمكن فعلها حيال هذه الزيادة في أزمنة البناء، فمن المفيد الحصول على رؤية أفضل للصورة الكاملة. من المفيد معرفة كم كان البناء يستغرق قبل بضعة أشهر مقابل ما يستغرقه الآن. هل كان التطور خطياً أم قفز فجأة؟ إن معرفة سبب زيادة زمن البناء يمكن أن تكون مفيدة جداً في المساعدة على حلّه. إذا زاد زمن البناء خطياً من 5 دقائق إلى 10 دقائق خلال السنة الماضية، فربما يمكننا توقع أن يستغرق بضعة أشهر أخرى ليصل إلى 15 دقيقة، ويكون لدينا تصور عن قيمة الوقت الذي ننفقه في تسريع عملية CI.

يمكن أن تكون المقاييس ذاتية الإبلاغ (وتسمى أيضاً مقاييس «الدفع» (push)، حيث يبلّغ كل بناء عن المدة التي استغرقها)، أو يمكن جلب البيانات من API لاحقاً (وتسمى أحياناً مقاييس «السحب» (pull)). والخطر في الإبلاغ الذاتي هو أن الإبلاغ الذاتي نفسه يستغرق وقتاً وقد يكون له تأثير كبير على «إجمالي الوقت المستغرق لجميع عمليات البناء».

يمكن إرسال هذه البيانات إلى قاعدة بيانات سلاسل زمنية أو إلى أرشيف من نوع آخر. وهناك العديد من الخدمات السحابية التي يمكنك من خلالها تجميع المقاييس بسهولة، ومن الخيارات الجيدة Datadog.

المهام الدورية

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

تشمل الفئة الأولى أشياء مثل فحص الحزم بحثاً عن ثغرات أمنية. وهناك عدة أدوات يمكنها فعل ذلك نيابة عنك بالفعل. بل إن بعض هذه الأدوات قد يكون مجانياً لأنواع معينة من المشاريع (مثل المشاريع مفتوحة المصدر). ويوفّر GitHub إحدى هذه الأدوات، Dependabot.

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

وماذا عن المهام التي لا توجد لها أداة؟ يمكنك أتمتة هذه بنفسك باستخدام GitHub Actions أيضاً. يوفّر GitHub Actions محفّزاً مجدولاً (scheduled trigger) يمكن استخدامه لتنفيذ مهمة في وقت معيّن.