الانطلاق - إرساء القاعدة

نظرة عامة على الوحدة

• حدّد الأهداف، ورتّب المتطلبات حسب الأولوية، واستكشف وحدات الشيفرة (modularity)، ثم انتقل إلى الاختبار وضمان الجودة.
• نفّذ اختبارات الوحدة، واتبع أفضل ممارسات Docker، واستكشف بوابات الجودة في التكامل المستمر مع GitHub Actions.
• نفّذ المشروع العملي التدريجي HiveBox المرحلة 3.

3.1 التخطيط - تحديد الأهداف والمتطلبات

الجمهور

الجمهور المستهدف: جميع الأدوار (بما فيها أدوار DevOps والبرمجيات وغيرها)

ما تحتاج إلى معرفته

• الخطوة الأولى في العمل هي التخطيط، الذي يبدأ بتحديد الأهداف والمتطلبات.
• قرّر أيّ منهجية أجايل ستستخدم. (Scrum أو Kanban أو Scrumban، إلخ). لنلتزم بـ Kanban.
• وثّق أثناء العمل. افترض دائمًا أنّ شخصًا آخر سيقرأ مشروعك في أي طور.
• تجنّب تضخّم النطاق (Scope Creep)! اجعله يعمل، ثم اجعله صحيحًا، ثم اجعله سريعًا!
• لا تنسَ! أنت مدير نفسك (Managers of One)! وهنا أقتبس من Signal v. Noise: "مدير النفس هو شخص يضع أهدافه الخاصة وينفّذها. لا يحتاج إلى توجيه ثقيل. ولا يحتاج إلى متابعة يومية".

المصادر

• ما هي إدارة المشاريع بأسلوب أجايل؟ - Businessmap
• أهم خمسة أسباب لتضخّم النطاق وما يمكن فعله حيالها - Project Management Institute
• القيادة - مديرو أنفسهم - دليل GitLab

3.2 البرمجة - الوحدات وإعادة الاستخدام

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• تقسيم شيفرة البرمجيات إلى وحدات أصغر وقائمة بذاتها له فوائد كثيرة، منها فصل الاهتمامات (separation of concerns) والتغليف (encapsulation) والتطوير والاختبار المستقلّين.
• لكن ينبغي أن توازن دائمًا بين الوحدات وتجنّب الهندسة المفرطة (over-engineering). فإن كانت الشيفرة صغيرة أصلًا، فلا حاجة إلى تقسيمها إلى وحدات دقيقة.
• وحتى في الشيفرة الصغيرة، استهدف دائمًا الوضوح والبساطة. وفكّر في الشخص التالي الذي سيعمل على تلك الشيفرة (وهو في حالات كثيرة نسخة مستقبلية منك!) وتذكّر دائمًا أنّ الشيفرة تُقرأ أكثر مما تُكتب!
• لا يهمّ أيّ لغة تستخدم، نصّ Bash أو لغة برمجة حقيقية، فطبّق المبادئ نفسها دائمًا.
• وكمهندس DevOps، فإنّ إعادة الاستخدام مهمّة للغاية بالنسبة لك، ليس على المستوى العملي فحسب بل كطريقة تفكير أيضًا.

المصادر

• اتّخاذ المسار المعياري - DevOps.com: يتيح استخدام مقاربة معيارية (قائمة على الوحدات) في البرمجة وDevOps عمومًا تطويرًا أسرع وتحديثات أسهل واستكشافًا أبسط للأعطال.
• زِن Python: لدى Python بعض المبادئ التوجيهية الرائعة للمطوّرين يمكن تطبيقها على أي شيفرة.

3.3 البرمجة - الاختبار وضمان الجودة

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• هدف الاختبار وضمان الجودة (QA) في البرمجيات هو التأكّد من أنّ البرمجيات تلبي المتطلبات وأنها خالية من العيوب قدر الإمكان.
• تقنيًّا، الاختبار (Testing) وضمان الجودة (QA) شيئان مختلفان، لكنهما يُستخدمان عادةً بالتبادل.
• عادةً يوجد مختصّ مخصّص يتولّى ضمان الجودة في دورة حياة تطوير البرمجيات (SDLC)، ويتعاون معه مهندسو DevOps، وقد يكون الاختبار يدويًّا أو مؤتمتًا.
• ولكن كمهندس DevOps أيضًا، تحتاج إلى تطبيق ضمان الجودة على شيفرتك وأدواتك الخاصة.
• للاختبار أنواع كثيرة، يخدم كل منها أغراضًا مختلفة، مثل:
  • اختبار الوحدات (Unit Testing): اختبار المكوّنات أو الوحدات الفردية للبرمجيات للتأكّد من أنها تعمل بشكل صحيح بمعزل عن غيرها.
  • اختبار التكامل (Integration Testing): اختبار التفاعل بين الوحدات/المكوّنات المتكاملة للتأكّد من أنها تعمل معًا كما هو متوقّع.
  • الاختبار من البداية إلى النهاية (End-to-end Testing): اختبار البرمجيات الكاملة والمتكاملة للتحقّق من أنها تلبي المتطلبات المحدّدة من البداية إلى النهاية.
  • اختبار القبول (Acceptance Testing): التحقّق من البرمجيات مقابل متطلبات المستخدم وتحديد ما إذا كانت جاهزة للإصدار. وكثيرًا ما يتضمّن ذلك اختبارًا تجريبيًّا (beta testing) مع مستخدمين حقيقيين.
  • اختبار الانحدار (Regression Testing): إعادة اختبار البرمجيات بعد التغييرات (مثل إصلاحات العلل أو الميزات الجديدة) للتأكّد من عدم تعطّل الوظائف القائمة.
  • اختبار الأداء (Performance Testing): تقييم أداء البرمجيات في ظروف مختلفة، مثل اختبار الحِمل (load testing) واختبار الإجهاد (stress testing).
  • اختبار الأمان (Security Testing): تحديد الثغرات والتأكّد من أنّ البرمجيات آمنة ضد التهديدات المحتملة.
• توجد أيضًا أنواع أخرى من الاختبارات لا تتعلّق بالجودة مثل اختبار A/B، الذي يعرض نسختين مختلفتين من البرمجيات لتحديد أيّ نسخة تحقّق أفضل النتائج واستخدام تلك المعلومات لاتخاذ قرارات مبنية على البيانات لتحسين تجربة المستخدم وتحقيق أهداف العمل.

المصادر

• ضمان الجودة مقابل الاختبار - BrowserStack: رغم أنهما يُستخدمان عادةً بالتبادل، فمن الجيد فهم الفرق الفعلي بينهما.
• استراتيجية اختبار DevOps - SmartBear: مقال مفصّل عن تطوير استراتيجية اختبار DevOps، والفوائد، وأفضل الممارسات، والأدوات.

3.4 البرمجة - كتابة اختبارات الوحدة

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• كما ذُكر من قبل، يركّز اختبار الوحدة (Unit Testing) على اختبار المكوّنات أو الوحدات أو الدوال/الطرق الفردية في الشيفرة للتأكّد من أنها تعمل بشكل صحيح بمعزل عن غيرها.
• يُعدّ فهم اختبار الوحدة عمومًا أمرًا جوهريًّا، وكمهندس DevOps ينبغي أن تكون قادرًا على كتابة اختبارات الوحدة بلغة البرمجة الرئيسية لديك.
• يُعدّ اختبار وحدة أي شيفرة نقطة دخول جيدة لفهم أي شيفرة جديدة.
• في معظم الأحيان لا تكتب اختبارات الوحدة بالشيفرة الأصلية بل باستخدام إطار عمل أو مكتبة مخصّصة لذلك.
• ينبغي أن يغطّي اختبار الوحدة معظم شيفرتك، لكنّ تغطية اختبار الوحدة بنسبة 100% غير واقعية عادةً ولا تقدّم قيمة كبيرة.
• تذكّر دائمًا أنّ اختبار الوحدة شيفرة مساعدة تُكتب للتأكّد من أنّ الشيفرة الرئيسية تعمل كما هو متوقّع، ومن ثمّ ينبغي أن تكون شيفرة اختبار الوحدة بالغة البساطة ولا تحتوي على منطق كثير.

المصادر

• اختبار الوحدة: المبادئ والفوائد و6 من أفضل الممارسات السريعة - Codefresh
• اختبار الوحدة والبرمجة: لماذا تهمّ الشيفرة القابلة للاختبار

3.5 الحاويات - أفضل ممارسات Docker

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• في الوحدة السابقة غطّينا أساسيات Docker. وفي هذه المرحلة، ينبغي أن تبدأ بتطبيق أفضل ممارسات Docker والحاويات.
• عمومًا، وكحال كل أفضل الممارسات، لست بحاجة إلى حفظها، بل ابدأ دائمًا بأداة تساعدك على التحقّق من أفضل الممارسات الشائعة.
• Hadolint من مدقّقات (linters) ملفات Dockerfile الشائعة. وهو يتكامل أيضًا مع بيئات تطوير متكاملة (IDEs) مختلفة مثل VS Code.
• في ما يلي بعض الفئات الرئيسية لأفضل الممارسات (اطّلع على المصادر للقائمة الكاملة):
  • الشائعة
  • الخاصة بلغة معيّنة
  • الأمان
  • ملف الحاوية
  • صورة الحاوية
  • بيئة تشغيل الحاوية

المصادر

• أفضل ممارسات بناء Dockerfile - Docker Docs
• ورشة أفضل ممارسات Docker - Ahmed AbouZaid

3.6 التكامل المستمر - مقدمة وحلول السوق

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• بعبارات بسيطة، التكامل المستمر (Continuous Integration) ممارسة تُدمَج فيها تغييرات الشيفرة بانتظام في مستودع مشترك، ويُشغّل كل دمج عملية بناء واختبار مؤتمتة، ما يتيح للفرق اكتشاف الأخطاء بسرعة، وضمان جودة الشيفرة، وتسهيل تكامل الميزات الجديدة.
• توجد أنظمة تكامل مستمر (CI) مختلفة مثل Jenkins وGitHub Actions وGitLab CI وغيرها.
• لا يهمّ النظام ما دمت تفهم مبادئ التكامل المستمر.
• لكن لا تبدأ بـ Jenkins! فلا أحد يتعلّم القيادة باستخدام دبّابة! ابدأ بشيء أكثر مباشرة مثل GitHub Actions.
• التكامل المستمر ممارسة حاسمة في تطوير البرمجيات الحديث لجودة شيفرة أفضل وسرعة تسليم أكبر.

المصادر

• أساسيات التكامل المستمر في DevOps - GitHub
• ما هو التكامل المستمر؟ - Atlassian
• 7 مفاهيم في CI/CD يجب أن تعرفها - Codefresh

3.7 التكامل المستمر - أساسيات GitHub Actions

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• كما ذُكر في القسم السابق، ابدأ بمنصّة تكامل مستمر مباشرة وتجنّب Jenkins في البداية! فـ Jenkins قوي جدًّا بحيث لا يصلح كنقطة بداية، وستجد نفسك تتعامل مع مجالات كثيرة تتعلّق بـ Jenkins نفسه أكثر ممّا تتعلّق بالتكامل المستمر كمفهوم.
• لهذا السبب، يُعدّ GitHub Actions بداية رائعة. فهو منصّة قوية مدمجة مباشرة في GitHub، وتتيح للمهندسين أتمتة مسارات عملهم، بما يشمل بناء الشيفرة واختبارها ونشرها.
• لـ GitHub Actions المفاهيم الجوهرية التالية:
  • مسارات العمل (Workflows): بيان YAML الرئيسي الذي يؤتمت عمليات مثل بناء الشيفرة واختبارها. وتتكوّن من مهمة واحدة أو أكثر يمكن أن تعمل بالتوازي أو بالتسلسل.
  • المهام (Jobs): المهمة مجموعة من الخطوات تُنفَّذ على الجهاز نفسه. ويمكن أن تعمل المهام على أنواع مختلفة من الأجهزة (مثل Ubuntu وmacOS وWindows).
  • الخطوات (Steps): مهام فردية داخل المهمة. ويمكن أن تتضمّن الخطوات إجراءات (actions، وهي وحدات قابلة لإعادة الاستخدام) أو أوامر صدفة مخصّصة.
  • الإجراءات (Actions): قطع شيفرة قابلة لإعادة الاستخدام تؤدّي مهام محدّدة. فكّر في Actions كإضافات (extensions) أو ملحقات (plugins). ويمكنك الحصول عليها من GitHub Marketplace.
  • المُشغّلات (Runners): خوادم تشغّل مسارات العمل. ويوفّر GitHub هذه المُشغّلات لك مع بعض القيود، لكن يمكنك أيضًا استضافة المُشغّلات بنفسك لتحكّم أكبر.
• تذكّر دائمًا أنّ الخطوات في GHA تتسلسل، وأنّ المهام متوازية افتراضيًّا لكنها قد تكون متسلسلة أيضًا بضبط الاعتماديات بين المهام. لكن كل مهمة تعمل على جهازها الخاص وتحتاج إلى خطوات إضافية لمشاركة المعلومات بينها.

المصادر

• بداية سريعة لـ GitHub Actions - GitHub Docs
• كيف تبني خطّ أنابيب CI/CD باستخدام GitHub Actions في أربع خطوات بسيطة - GitHub Blog

3.8 التكامل المستمر - خطوط الأنابيب وبوابات الجودة

الجمهور

الجمهور المستهدف: أدوار DevOps وأدوار البرمجيات

ما تحتاج إلى معرفته

• كما ذُكر من قبل، تُنشأ خطوط أنابيب التكامل المستمر (CI) لضمان جودة شيفرتك (أي شيفرة، بما يشمل لغة برمجة أو نصًّا بسيطًا أو شيفرة بنية تحتية مثل ملفات Dockerfile أو بيانات Kubernetes الوصفية).
• فكرة بوابات الجودة هي وجود بعض الإجراءات المفروضة للتأكّد من أنّ أي تغييرات تستوفي معايير معيّنة قبل الدمج أو الانتقال إلى الخطوات التالية.
• في أيامنا هذه، ينبغي أن يكون لدى 100% من المشاريع خطّ أنابيب تكامل مستمر بسيط على الأقل يتضمّن التدقيق (linting) ونمط الشيفرة (code style)، وربما أداة أمان (security) إضافة إلى خطوات البناء (build) المعتادة لإنشاء المخرجات (artifact) مثل صورة Docker أو ما شابه.
• يُوصى باستخدام منصّة التكامل المستمر مثل GitHub Actions أو Jenkins كمُشغّل (runner) فحسب، وهذا يعني أنّه ينبغي أن يكون ممكنًا تشغيل كل ما في خطّ أنابيب CI محليًّا أيضًا. ويستخدم كثير من الناس أدوات مثل Make لذلك، لكن توجد أدوات حديثة مثل Task.
• كما ينبغي تشغيل بوابات الجودة تلك (الجوهرية والسريعة على الأقل) محليًّا حتى قبل الدفع إلى المستودع البعيد لتجنّب تنفيذ غير ضروري لخطوط أنابيب CI. ويمكن فعل ذلك عبر خطافات Git الأصلية (Git hooks) أو أداة مثل pre-commit، وهي إطار عمل لإدارة خطافات ما قبل الالتزام (pre-commit hooks) متعدّدة اللغات وصيانتها.

المصادر

• أهمية بوابات الجودة في خطوط الأنابيب وكيفية تنفيذها - InfoQ

الاختبار

التطبيق العملي

اتبع التعليمات في المرحلة 3 من مشروع HiveBox.

أسئلة المقابلات

راجع أسئلة المقابلات المتعلّقة بـ الوحدة 3.