مقدمة
مفردات التكامل المستمر، ومعيار اختيار ما نقوم بأتمتته.
في مستودع لا يعتمد التكامل المستمر، تقوم الجودة على جملة لم يكتبها أحد: «قبل الدفع، شغّل الاختبارات». تصمد هذه الجملة بضعة أسابيع. ثم في مساء جمعة يدفع أحدهم إصلاحًا من سطر واحد دون تشغيلها، لأن سطرًا واحدًا لا يكسر شيئًا. وفي يوم الإثنين يكون الفرع الرئيسي أحمر، وقد سحب منه ثلاثة أشخاص بالفعل، ويلزم نصف يوم للتمييز بين الـ commit المسؤول عن العطل والـ commits التي اكتفت بالبناء فوقه. التكلفة الحقيقية ليست في الاختبار الذي لم يُشغَّل، بل في المدة الفاصلة بين وقوع الخطأ واكتشافه.
يستهدف التكامل المستمر هذه المدة تحديدًا. فهو ينقل عملية التحقق من جهاز المطوّر إلى جهاز محايد ينفّذها عند كل دفع، دون استثناء ودون الاعتماد على انضباط أي شخص. ويقدّم ثلاثة أشياء لا تمنحها أي قاعدة اتفق عليها الفريق: قابلية التكرار، لأن البيئة موصوفة في ملف خاضع للإصدارات لا في جهاز عمل؛ والأثر، لأن كل عملية تنفيذ تترك سجلًا مؤرَّخًا مرتبطًا بـ commit محدد؛ والإلزام، لأن النتيجة الحمراء يمكن أن تمنع الدمج، وهو ما لم يفعله تذكير شفهي قط.
ما الذي تنفّذه GitHub Actions فعليًا
GitHub Actions ليست أداة اختبار ولا أداة نشر. إنها مُجدوِل: يراقب أحداث المستودع، وينفّذ ردًّا عليها أوامر كان بإمكانك كتابتها بنفسك في الطرفية. وكل ما لا يعمل على جهازك لن يعمل هنا بصورة أفضل. سلسلة التكامل المستمر تؤتمت إجراءً قائمًا، ولا تخترع إجراءً جديدًا.
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش