التكامل المستمر والتسليم المستمر والنشر المستمر
التكامل المستمر (Continuous Integration أو CI) والتسليم المستمر (Continuous Delivery) والنشر المستمر (Continuous Deployment) ثلاث ممارسات تُبنى كل منها على سابقتها. في التكامل المستمر يدمج المطورون عملهم في فرع رئيسي مشترك (mainline) يومياً على الأقل، ويتحقق بناءٌ آلي مع اختباراته من كل دمج. ويُبقي التسليم المستمر كل تغيير يجتاز خط الأنابيب (pipeline) قابلاً للإصدار، فيستطيع الفريق نشره متى قرر ذلك. أما النشر المستمر فيلغي هذا القرار: كل تغيير ناجح يذهب إلى الإنتاج تلقائياً.
خذ إصلاحاً لطريقة تقريب ضريبة القيمة المضافة في الفواتير. مع التكامل المستمر يُدمج في اليوم نفسه ويُتحقق منه خلال دقائق. ومع التسليم المستمر يجتاز أيضاً اختبارات على بيئة staging، ثم ينتظر بوصفه مرشحاً للإصدار (release candidate) حتى يُصدره مالك المنتج. ومع النشر المستمر يصل إلى العملاء بمجرد نجاح آخر فحص آلي.
لماذا يهم
الدمج النادر والإصدار النادر كلاهما محفوف بالمخاطر. فحين يلتقي عمل أسابيع لعدة أشخاص دفعة واحدة، تتراكم التعارضات وعيوب التكامل، ولا يستطيع أحد أن يحدد أي تغيير سبّب أي إخفاق. تستبدل هذه الممارسات بالأحداث الكبيرة النادرة أحداثاً صغيرة متكررة، يُفحص كل منها وصاحبه ما زال يتذكره.
وبالنسبة للمختبِر، تحدد الممارسة ما يثبته خط الأنابيب أصلاً، وهل يفحص أي شخص التغيير قبل أن يراه المستخدمون. ومعرفة الممارسة التي يتبعها فريقك فعلاً تخبرك أي المخاطر ما زال يحتاج إليك.
التكامل المستمر: ادمج كثيراً وتحقق من كل دمج
يعرّف مارتن فاولر (Martin Fowler)، في مقاله الذي يُستشهد به على نطاق واسع، التكاملَ المستمر بأنه ممارسة يدمج فيها كل عضو في الفريق تغييراته في قاعدة الكود المشتركة يومياً على الأقل، ويُتحقق من كل عملية تكامل ببناء آلي يتضمن الاختبارات. فالتعارض بين تغييرين كُتبا هذا الصباح سريع الإصلاح، أما إذا اكتُشف بعد ثلاثة أسابيع فليس كذلك.
التكامل المستمر عادة فريق تدعمها أداة، لا الأداة نفسها. فخادم CI يبني فرعاً طويل العمر مرة في الأسبوع، أو فرع رئيسي يُترك أحمر أياماً والناس يواصلون الدمج فوقه، هو أداة CI بلا تكامل مستمر. وهذه العادات هي التي تجعله ينجح:
- فرع رئيسي واحد مشترك في نظام التحكم في الإصدارات (version control)، فيه كل ما يلزم لبناء المنتج واختباره.
- بناء يختبر نفسه (self-testing build) ويعمل عند كل دفع (push) إلى الفرع الرئيسي: يشغّل الاختبارات الآلية ويفشل إذا فشل أي منها. وكثير من الفرق تبني أيضاً كل طلب دمج (pull request) قبل دمجه.
- بناء يُقاس بالدقائق، حتى ينتظر المطورون الحكم بدلاً من الانتقال إلى عمل آخر.
- البناء المكسور يُصلح أولاً: لا يضيف أحد تغييرات فوق فرع رئيسي أحمر.
التسليم المستمر والنشر المستمر
يمدّ التسليم المستمر التكاملَ المستمر إلى ما بعد الدمج. يبني خط الأنابيب المنتج مرة واحدة، وينشر البناء نفسه في بيئات اختبار تشبه الإنتاج، ويشغّل فيها فحوصاً إضافية مثل اختبارات API والاختبارات الشاملة (end-to-end) والاختبارات غير الوظيفية. وكل بناء يجتازها مرشح للإصدار يمكن نشره في الإنتاج بضغطة زر؛ أما موعد نشره فعلاً فقرار تجاري.
ويلغي النشر المستمر هذا القرار: كل تغيير يجتاز جميع المراحل الآلية يُنشر في الإنتاج تلقائياً. لذلك يتطلب النشر المستمر تسليماً مستمراً، ويتطلب التسليم المستمر بدوره تكاملاً مستمراً.
ومصطلحان يسببان الالتباس. فالاختصار CD يُستخدم للاثنين، فإذا قال فريق إنه يطبّق CI/CD فاسأل أيّهما يقصد. وبعض الفرق تفصل النشر (deployment)، أي أن النسخة الجديدة تعمل في الإنتاج، عن الإصدار (release)، أي أن المستخدمين يرون الميزة، كأن تبقى ميزة مكتملة معطّلة حتى موعد مخطط.
التكامل المستمر
دمج يومي على الأقل، وكل دمج يُبنى ويُختبر آلياً
- 1الدمج في الفرع الرئيسيتغييرات صغيرة، يومياً على الأقل
- 2بناء واختبارات آليةفحوص ساكنة واختبارات وحدة ومكوّنات خلال دقائق
- 3فرع رئيسي مُتحقَّق منهإن صار أحمر فإصلاحه يسبق أي عمل جديد
- النتيجة:
- فرع رئيسي مُتحقَّق منه
- من يقرر الذهاب إلى الإنتاج:
- ليس جزءاً من التكامل المستمر: عملية إصدار منفصلة
- ما تقرره الاختبارات الآلية:
- هل ينضم التغيير إلى الفرع الرئيسي
- تتطلب:
- فرعاً رئيسياً مشتركاً وبناءً يختبر نفسه
التسليم المستمر
كل بناء ناجح قابل للإصدار، وشخصٌ يقرر متى
- 1اجتياز التكامل المستمرالتغيير نفسه بعد التحقق منه
- 2النشر في staging واختبار أعمقاختبارات API والشاملة وغير الوظيفية، ويستكشف البشر
- 3مرشح للإصداريمكن نشره في الإنتاج في أي وقت
- 4شخصٌ يقرر: انشرفي موعد يحدده قرار تجاري
- النتيجة:
- مرشح للإصدار
- من يقرر الذهاب إلى الإنتاج:
- شخص، مثل مالك المنتج
- ما تقرره الاختبارات الآلية:
- هل البناء قابل للإصدار
- تتطلب:
- التكامل المستمر
النشر المستمر
كل بناء ناجح يذهب إلى الإنتاج تلقائياً
- 1اجتياز التكامل المستمرالتغيير نفسه بعد التحقق منه
- 2النشر في staging واختبار أعمقكل فحص مهم يجب أن يكون آلياً
- 3نشر تلقائي في الإنتاجلا أحد يوافق عليه
- 4فحوص ما بعد النشرومراقبة، وتراجع إن فشلت
- النتيجة:
- التغيير يعمل في الإنتاج
- من يقرر الذهاب إلى الإنتاج:
- لا أحد: اجتياز خط الأنابيب هو القرار
- ما تقرره الاختبارات الآلية:
- هل يصل التغيير إلى المستخدمين، دون أي فحص آخر
- تتطلب:
- التسليم المستمر، ومن ثم التكامل المستمر
المراحل توضيحية: تختلف خطوط الأنابيب الفعلية من فريق إلى آخر.
دور الاختبارات الآلية في كل ممارسة
في الممارسات الثلاث، الاختبارات الآلية هي الدليل الذي يتصرف خط الأنابيب بناءً عليه؛ ومن دونها لا يثبت التكامل المستمر إلا أن الكود يُبنى. والذي يتغير هو مقدار ما يعتمد على هذا الدليل. ويضيف منهج ISTQB للمستوى التأسيسي أنه رغم المستوى العالي من الأتمتة في DevOps، يبقى الاختبار اليدوي من منظور المستخدم ضرورياً.
- التكامل المستمر: تقرر الاختبارات هل ينضم التغيير إلى الفرع الرئيسي، لذا يجب أن تكون سريعة: فحوص ساكنة واختبارات وحدة ومكوّنات في الغالب.
- التسليم المستمر: تقرر الاختبارات هل البناء قابل للإصدار. وتعمل اختبارات API والاختبارات الشاملة وغير الوظيفية الأبطأ لاحقاً، على البناءات التي اجتازت المراحل السريعة فقط، ويبقى بوسع البشر استكشاف المرشح للإصدار قبل أن يضغط أحد الزر.
- النشر المستمر: الاختبارات هي البوابة الوحيدة قبل المستخدمين. وكل خطر لا يفحصه خط الأنابيب لا يُفحص أبداً، لذا تُكمل فحوص ما بعد النشر والمراقبة والتراجع السريع (rollback) شبكة الأمان.
- وفي كل الممارسات، الاختبار المتذبذب (flaky test)، أي الذي يفشل عشوائياً، يُضعف شبكة الأمان: يتعلم الفريق أن يعيد التشغيل ويتجاهل البناء الأحمر، فتمرّ الإخفاقات الحقيقية.
مثال تطبيقي: تغيير واحد وثلاث ممارسات
صيدلية إلكترونية تخفض حدّ التوصيل المجاني من 200.00 ريال إلى 150.00 ريال. يعرض السجل تشغيلاً واحداً لخط الأنابيب، وهذا الجزء متطابق في الممارسات الثلاث.
- التكامل المستمر: عند 09:52 كان التغيير مدموجاً، وكانت اختبارات الوحدة قد فحصت 149.99 و150.00 عند الحد الجديد، و199.99، وهي قيمة كانت تُفرض عليها رسوم توصيل وصار توصيلها مجانياً. ولو فشل اختبار عند 09:44 لبقي التغيير خارج الفرع الرئيسي وهو ما زال حاضراً في ذهن المطوّر.
- التسليم المستمر: ينتظر البناء 2.14.0+512 على staging. يستكشف المختبِر السلة (ماذا تقول لافتة التوصيل المجاني الآن؟ وماذا عن طلب قيمته 150.00 ريالاً بالضبط مع رمز خصم؟)، ويقارن استجابة API السلة على staging باستجابتها في الإنتاج. ثم يُصدره مالك المنتج عند 14:00 مع العرض الأسبوعي.
- النشر المستمر: يصل البناء نفسه إلى الإنتاج نحو 10:12 دون أن يقرر أحد. تستدعي فحوص ما بعد النشر نقاط فحص الصحة (health endpoints) وتجري اختبار دخان (smoke test) للسلة، وإن فشلت يتراجع الفريق. وكان لا بد من طرح الأسئلة الاستكشافية قبل الدمج أو تحويلها إلى فحوص آلية.
- ولو فشلت مرحلة الاختبارات الشاملة عند 10:09 لما وُجد مرشح للإصدار في أي من الممارستين: خط الأنابيب هو الذي يوقف التغيير، لا شخص.
Change: free delivery from 150.00 SAR (was 200.00 SAR)
09:40 pull request #418 opened
09:41 build .......................................... passed
09:44 static checks + unit tests ..................... passed
09:49 API tests against a temporary database ......... passed
09:52 merged to main
09:56 main: build + unit tests ....................... passed
10:01 build 2.14.0+512 deployed to staging
10:09 end-to-end checkout journeys on staging ........ passed
10:09 release candidate 2.14.0+512 is readyأخطاء شائعة
- اعتبار خادم CI تكاملاً مستمراً: البناء الأسبوعي لفروع طويلة العمر، أو ترك الفرع الرئيسي أحمر أياماً، هو الأداة بلا الممارسة.
- قول «CD» دون تحديد المقصود. ففي التسليم المستمر يبقى قرار شخصٍ قبل الإنتاج، وفي النشر المستمر لا يبقى، فتختلف استراتيجية الاختبار.
- افتراض أن الأتمتة تغني عن الاختبار اليدوي. فالاختبار الاستكشافي واختبار القبول ما زالا يجدان ما لم يتوقعه أحد؛ وفي النشر المستمر ينتقلان إلى ما قبل الدمج.
- وضع الاختبارات الشاملة البطيئة في المرحلة الأولى، فيكفّ المطورون عن انتظار الحكم ويدمجون على أي حال.
- إعادة تشغيل البناء الأحمر حتى يصير أخضر ثم اعتباره مُصلَحاً.
- الخلط بين النشر والإصدار: قد تعمل ميزة في الإنتاج وهي ما زالت معطّلة أمام المستخدمين.
من منظور ضمان الجودة
ابدأ بمعرفة ما يفعله فريقك فعلاً: كم مرة يصل العمل إلى الفرع الرئيسي، وماذا تختبر كل مرحلة في خط الأنابيب، وهل يوافق شخصٌ على النشر في الإنتاج. واقرأ آخر التشغيلات: أين تفشل، وكم تستغرق كل مرحلة، وكم مرة يُعاد تشغيل البناء الأحمر دون تحقيق. هكذا تعرف أي المخاطر تغطيها الأتمتة، وأين يضيف اختبارك أكبر قيمة.
ثم ساعد في وضع الاختبارات المناسبة في المرحلة المناسبة: اقترح حالات حدّية وسلبية لاختبارات الوحدة، واتفقوا على رحلات المستخدم الحرجة التي تنتمي إلى مرحلة الاختبارات الشاملة، وعامل الاختبار المتذبذب كعيب له مالك. وفي التسليم المستمر خطّط اختبارك الاستكشافي حول المرشح للإصدار وسجّل أي بناء اختبرت؛ وفي النشر المستمر انقله إلى مراجعة القصص وطلبات الدمج، وتأكد من أن التراجع نفسه قد اختُبر.
تمرين عملي
سمِّ الممارسة واكتشف الثغرة في الاختبار
تصف أربعة فرق طريقة عملها. حدّد لكل فريق هل يطبّق التكامل المستمر أم التسليم المستمر أم النشر المستمر أم لا شيء منها. ثم اكتب ما يجب أن تغطيه الاختبارات الآلية للفريق C، إذ لا يفحص أي شخص تغييراته قبل أن يراها المستخدمون.
الفريق A: يعمل المطورون على فروع ميزات (feature branches) أسبوعين إلى ثلاثة أسابيع.
يبني خادمٌ الفرع الرئيسي ويختبره كل ليلة، ويُدمج العمل قبل كل إصدار شهري.
الفريق B: يدمج المطورون طلبات دمج صغيرة في الفرع الرئيسي عدة مرات يومياً.
ويُبنى كل طلب دمج وكل دمج ويُختبر في نحو 12 دقيقة.
يُنشر كل بناء ناجح في staging تلقائياً ويمكن أن يذهب إلى الإنتاج.
ويضغط مالك المنتج زر «Deploy» كل خميس.
الفريق C: يدمج المطورون في الفرع الرئيسي عدة مرات يومياً، وكل دمج يجتاز
جميع مراحل خط الأنابيب يُنشر في الإنتاج تلقائياً، عادةً خلال 30 دقيقة.
الفريق D: يبني Jenkins كل إيداع، لكن الفرع الرئيسي أحمر منذ أربعة أيام.
ويواصل الفريق الدمج ويخطط «لإصلاح الاختبارات قبل الإصدار».- تحقق من عدد مرات وصول العمل إلى الفرع الرئيسي، وهل يُتحقق من كل دمج ببناء آلي مع اختبارات.
- تحقق هل كل بناء ناجح قابل للنشر، ومن أو ما الذي يقرر موعد ذهابه إلى الإنتاج.
- سمِّ الممارسة، ثم اكتب الفحوص الآلية التي لا غنى عنها للفريق C وسؤالاً واحداً توجهه إليه.
إظهار الإجابة النموذجية
الفريق A: لا شيء من الثلاث. فالعمل لا يُدمج إلا قبل كل إصدار، والبناء الليلي يختبر الفرع الرئيسي لا كل عملية تكامل، فتتراكم المشكلات أسابيع. وخادم CI وحده ليس تكاملاً مستمراً.
الفريق B: تسليم مستمر. يصل العمل إلى الفرع الرئيسي عدة مرات يومياً ويُتحقق من كل دمج (وهذا هو التكامل المستمر)، وكل بناء ناجح قابل للنشر، وشخصٌ يقرر موعد الإصدار.
الفريق C: نشر مستمر. يدمج بالوتيرة نفسها التي يدمج بها الفريق B، لكن اجتياز خط الأنابيب هو قرار الإصدار.
الفريق D: أداة CI بلا الممارسة. فالبناء المكسور لا يُصلح أولاً، لذا يقع كل دمج جديد فوق فرع رئيسي أحمر ولا معنى لنتيجته. والعلاج إيقاف الدمج وإصلاح الفرع الرئيسي الآن.
يحتاج الفريق C إلى فحوص آلية لكل خطر مهم: اختبارات وحدة وAPI لقواعد العمل، وبضع رحلات شاملة للمسارات الحرجة (تسجيل الدخول وإتمام الشراء والدفع)، والفحوص غير الوظيفية الأساسية، وفحوص ما بعد النشر مع تراجع مُجرَّب. وسؤال جيد: ما سرعة التراجع عن نشر سيئ، وهل جرّبه أحد؟
أسئلة شائعة
هل CI/CD أداة؟
لا. التكامل المستمر والتسليم المستمر أو النشر المستمر ممارسات. وأدوات مثل GitHub Actions وGitLab CI/CD وJenkins تشغّل خطوط الأنابيب التي تدعمها، لكن الفريق الذي يدمج نادراً أو يتجاهل البناء الأحمر لا يطبّق التكامل المستمر أياً كانت أداته.
هل يعني النشر المستمر أنه لا يوجد مختبِر في الفريق؟
لا. ينتقل عمل المختبِر إلى وقت أبكر ويتغير شكله: مراجعة القصص وطلبات الدمج، وتصميم الفحوص الآلية، واختبار فحوص ما بعد النشر والتراجع، واستكشاف الميزات قبل دمجها أو وهي ما زالت معطّلة أمام المستخدمين.
أي ممارسة يجب أن يختار الفريق؟
التكامل المستمر أساس الاثنتين. ويناسب التسليم المستمر الفرق التي يحتاج إصدارها إلى قرار تجاري أو موافقة تنظيمية أو تنسيق مع أحداث أخرى. ويناسب النشر المستمر الفرق التي تثق باختباراتها الآلية ومراقبتها وقدرتها على التراجع إلى حد أن وجود شخص قبل الإنتاج لن يضيف فحصاً حقيقياً. ويمكن للفريق أيضاً أن يطبّق التسليم المستمر في خدمة والنشر المستمر في أخرى.
المراجع
- Continuous Integration (Martin Fowler)الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Eradicating Non-Determinism in Tests (Martin Fowler)لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
تدرّب بأدوات متقن
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
افحص عدة نقاط نهاية لصحة API دفعة واحدة واحصل على الحالة وزمن الاستجابة وملخّص نجاح/فشل.
قارن استجابتي API (مثل بيئة التجريب مقابل الإنتاج) واحصل على قائمة بكل فرق بنيوي أو في القيم.
للتعمّق أكثر
- الاختبار في خطوط CI/CDكيف يعمل الاختبار داخل خطوط CI/CD: مراحل الاختبار وترتيبها، وبوابات الجودة، وتقارير JUnit، والتقسيم، والاختبارات المتذبذبة، وفرز الإخفاقات.
- اختبار الدخان والسلامة والانحدار: مقارنةأين يعمل كل منها في خط أنابيب CI/CD
- اختبار التحقق من النشراختبارات الدخان بعد النشر
- الاختبار اليدوي مقابل الاختبار الآليكيف تجمع الفرق بينهما
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.