دورة تعليمية عن ديفأوبس: دوكر، كوبرنيتيس، وأزور ديفأوبس

في هذه المقالة، سنتعلم عن DevOps وكيف يختلف عن منهجية Agile. سنغطي أيضًا بعض أدوات DevOps الشائعة وأدوارها في دورة حياة DevOps.

ستتعلم

• ما هو Docker و Kubernetes و Azure DevOps
• ما هو DevOps ولماذا نحتاجه؟
• كيف يختلف DevOps عن Agile؟
• ما هي بعض أدوات DevOps الهامة؟
• كيف يساعد Docker DevOps؟
• كيف يساعد Kubernetes DevOps؟
• كيف يساعد Azure DevOps DevOps؟
• ما هو التكامل المستمر والتسليم المستمر (CI/CD)؟
• ما هو البنية التحتية ككود؟
• كيف تساعد Terraform و Ansible DevOps؟

Docker

Docker هي أداة برمجية مفتوحة المصدر تُستخدم لبناء واختبار ونشر التطبيقات المعبأة في حاويات. ما هي الحاويات، بالمناسبة؟ الحاويات هي مفهوم تجميع جميع المكتبات والملفات مع كود التطبيق في وحدة واحدة تُسمى “حاوية” بحيث يمكن تشغيلها على أي بنية تحتية.

Kubernetes

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

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

لنبدأ بحالة استخدام بسيطة.

دورات مجانية — تعلم في 10 خطوات

• تعلم دوكر في 10 خطوات
• تعلم كوبرنيتيس في 10 خطوات
• تعلم أمازون ويب سيرفيسز في 10 خطوات

ما هو ديف أوبس؟

مثل معظم الكلمات الرنانة في تطوير البرمجيات، لا يوجد تعريف مقبول لـ DevOps.

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

DevOps هي مزيج من الفلسفات الثقافية، والممارسات، والأدوات التي تعزز قدرة المنظمة على تقديم التطبيقات والخدمات بسرعة عالية — خدمات أمازون ويب (AWS)

بدلاً من محاولة تعريف DevOps، دعونا نفهم كيف تطورت تطوير البرمجيات إلى DevOps.

نموذج المياه المتساقطة

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

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

ستقوم ببناء البرمجيات في مراحل متعددة يمكن أن تتراوح من بضعة أسابيع إلى عدة أشهر.

في معظم مشاريع المياه المتساقطة، قد يستغرق الأمر شهورًا قبل أن ترى الأعمال نسخة عاملة من التطبيق.

العناصر الرئيسية لبناء برمجيات رائعة

أثناء العمل في نموذج الشلال لعدة عقود، نفهم بعض العناصر الرئيسية حول تطوير البرمجيات الرائعة:

• التواصل
• التغذية الراجعة
• التأتير

أهمية التواصل

التواصل بين الأشخاص ضروري لنجاح مشروع البرمجيات.

في نموذج الشلال، حاولنا تعزيز التواصل من خلال إعداد وثائق تبلغ 1000 صفحة حول المتطلبات والتصميم والهندسة المعمارية والنشر.

ولكن، مع مرور الوقت، اكتشفنا أن:

• أفضل طريقة لتعزيز التواصل داخل فريق هي جمعهم معًا. وجلب مجموعة متنوعة من المهارات في نفس الفريق.
• الفرق متعددة المهام — بمجموعة واسعة من المهارات — تعمل بشكل رائع.

أهمية الردود السريعة

الحصول على الردود بسرعة مهم. بناء برمجيات رائعة يتعلق الأمر بالحصول على ردود سريعة.

• هل نقوم ببناء تطبيق يلبي توقعات الأعمال؟
• هل ستواجه تطبيقك مشاكل عند نشره في الإنتاج؟

لا ترغب في معرفة ذلك بعد عدة أشهر. تريد معرفته في وقت مبكر لأن كلما اكتشفنا مشكلة في وقت مبكر، كلما كان من الأسهل حلها.

اكتشفنا أن أفضل فرق البرمجيات مُنظمة لتمكين الردود السريعة.

أهمية التأتير

التأتير حاسم. تشمل تطوير البرمجيات مجموعة واسعة من الأنشطة. القيام بالأمور يدويًا بطيء ومعرض للأخطاء. نحن نفهم أنه من الضروري دائمًا البحث عن فرص لإدخال التأتير.

بعد فهم العناصر الرئيسية لتطوير برمجيات رائعة، دعونا نلقي نظرة على كيف تطورنا إلى أسلوب

Agile و DevOps.

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

جمع Agile بين فرق الأعمال وفرق التطوير في فريق واحد، يعمل على بناء برمجيات رائعة في تكرارات صغيرة تُسمى Sprints.

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

كيف عزز Agile التواصل بين الفرق؟

جمع Agile بين فرق الأعمال وفرق التطوير.

• تكون الشركات مسؤولة عن تحديد ما يجب بناؤه. ما هي المتطلبات؟
• يكون التطوير مسؤولًا عن بناء منتج يلبي المتطلبات. يتضمن التطوير جميع الأشخاص المشاركين في تصميم، وبرمجة، واختبار، وتعبئة البرمجيات الخاصة بك.

في العمل الجماعي، يكون هناك ممثل عن الجانب التجاري، يُسمى صاحب المنتج، حاضر دائمًا مع الفريق، والفريق يفهم أهداف العمل بوضوح.

عندما لا يفهم فريق التطوير المتطلبات ويتجه في الاتجاه الخاطئ، يساعده صاحب المنتج على تصحيح المسار والبقاء على الاتجاه الصحيح.

النتيجة: المنتج النهائي الذي يقوم الفريق ببنائه هو ما يرغب به الجانب التجاري.

عامل آخر مهم هو أن الفرق العملية لديها مهارات متعددة الوظائف: مهارات البرمجة (واجهة المستخدم الأمامية، واجهة برمجة التطبيقات، وقواعد البيانات)، ومهارات الاختبار، ومهارات العمل التجاري. هذا يعزز التواصل بين الأشخاص الذين يجب أن يعملوا معًا لبناء برمجيات رائعة.

العمل الجماعي والتلقائية

ما هي المجالات التي يركز عليها الفرق العملية في التلقائية؟

يمكن للمنتجات البرمجية أن تحتوي على مجموعة متنوعة من العيوب:

• العيوب الوظيفية تعني عدم عمل المنتج كما هو متوقع.
• العيوب التقنية تجعل صيانة البرمجيات صعبة. على سبيل المثال، مشاكل جودة الشفرة.

عمومًا، تركز الفرق العملية على استخدام التلقائية للعثور على العيوب التقنية والوظيفية في أقرب وقت ممكن.

تركز الفرق العملية أيضًا بشكل واسع على جودة الشفرة. يُستخدم أدوات مثل SONAR لتقييم جودة الشفرة في التطبيقات.

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

كيف قامت الرشاقة بتعزيز التغذية الفورية؟

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

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

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

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

ولكن هل تتوقف التطور؟ لا.

ظهور تحديات جديدة.

تطور بنية الخدمات الصغيرة

بدأنا نتجه نحو بنية الخدمات الصغيرة، وبدأنا ببناء العديد من واجهات برمجة التطبيقات الصغيرة بدلاً من بناء تطبيقات الوحدة الضخمة.

ما هو التحدي الجديد؟

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

حان الوقت لكلمة جديدة في تطوير البرمجيات. DevOps.

ظهور DevOps

ما هو تركيز DevOps؟

تركيز DevOps كان تعزيز التواصل بين فرق التطوير والعمليات.

• كيف نجعل عمليات النشر أسهل؟
• كيف نجعل عمل فريق العمليات أكثر وضوحًا لفريق التطوير؟

كيف جعل DevOps التواصل بين الفرق أسهل؟

جلب DevOps فرق العمليات أقرب إلى فرق التطوير.

• في المؤسسات الناضجة أكثر، عملت فرق التطوير والعمليات كفريق واحد. بدأوا في مشاركة الأهداف المشتركة وبدأت كلتا الفرقين في فهم التحديات التي تواجه الفريق الآخر.
• في المؤسسات، في مراحل مبكرة من تطور ديف أوبس، يمكن أن يشارك ممثل من فريق العمليات في السبرنتس – الاجتماعات اليومية والتقييمات.

ما هي مجالات التركيز على التأتأة التي تركز عليها فرق ديف أوبس؟

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

التنصيب المستمر يتعلق بنشر إصدار جديد من البرنامج بشكل مستمر على بيئات الاختبار. في المؤسسات الأكثر نضجًا مثل غوغل وفيسبوك، يساعد التسليم المستمر في نشر البرنامج بشكل مستمر على الإنتاج – ربما مئات النشرات الإنتاجية في اليوم.

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

كيف أعان ديف أوبس على تعزيز التغذية الفورية؟

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

• تحصل أي مشاكل تشغيلية على اهتمام سريع من المطورين.
• تُعتبر أي تحديات في نشر البرمجيات ضرورية للحصول على الاهتمام المبكر من فريق العمليات.

شجع DevOps على التكامل المستمر، والتسليم المستمر، والبنية التحتية ككود.

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

أرى أن Agile وDevOps هما مرحلتان تساعداننا في تحسين كيفية بناء برمجيات رائعة. إنهما لا يتنافسان مع بعضهما البعض، بل معًا يساعداننا في بناء منتجات برمجية مذهلة.

بالنسبة لي، فإن هدف Agile وDevOps معًا هو القيام بأشياء:

• تعزيز التواصل والتغذية الراجعة بين فرق الأعمال، والتطوير، والعمليات
• تخفيف نقاط الألم من خلال الأتمتة.

قصة DevOps

إليك مثال على قصة:

• أنت المطور النجم في فريقك، وتحتاج إلى إجراء إصلاح سريع.
• تذهب إلى مستودع GitHub.
• تتحقق سريعًا من المشروع.
• تنشئ بيئتك المحلية بسرعة.
• تقوم بإجراء تغيير. تقوم بإختباره. تحدث الوحدات واختبارات التلقائي.
• تقوم بعمل commit.
• تتلقى رسالة بأنه تم نشره إلى QA.
• يتم تشغيل بعض اختبارات الإدماج تلقائيًا.
• فريق QA الخاص بك يتلقى رسالة يُطلب فيها الموافقة. يقومون بإجراء اختبار يدوي ويوافقون.
• الكود الخاص بك يكون على الهواء في الإنتاج في بضع دقائق.
• قد تعتقد أن هذا هو سيناريو مثالي. ولكن، هل تعلم أن هذا ما يحدث في المؤسسات الابتكارية مثل Netflix وAmazon وGoogle يومًا بعد يوم؟

هذه هي قصة DevOps.

DevOps = تطوير + عمليات

DevOps هو تطور طبيعي لتطوير البرمجيات. DevOps ليس مجرد أداة، إطار عمل، أو مجرد أتمتة. إنه مزيج من كل هذه العوامل.

يركز DevOps على الأشخاص، العمليات، والمنتجات. الجزء الخاص بالأشخاص في DevOps يتعلق بالثقافة وخلق عقلية رائعة – ثقافة تعزز التواصل المفتوح وتقدر الردود السريعة، ثقافة تقدر البرمجيات عالية الجودة.

ساعد Agile في تقليل الفجوة بين فرق الأعمال والتطوير. فهمت فرق التطوير أولويات الأعمال وعملت مع الأعمال لتقديم القصص التي توفر أكبر قيمة أولاً؛ ومع ذلك، لم تكن فرق التطوير والعمليات متماشية.

كانت لديهم أهداف مختلفة.

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

كما يمكنك ملاحظة أنه إذا كان من الصعب القيام بالأمور في الإنتاج، فإن فريق التطوير والعمليات غير متناغمان.

تهدف DevOps إلى تنسيق فرق التطوير والعمليات بأهداف مشتركة.

فريق التطوير يعمل مع فريق العمليات لفهم وحل التحديات التشغيلية. يكون فريق العمليات جزءًا من فريق السكرام ويفهم الميزات التي تحت التطوير.

كيف يمكننا جعل هذا ممكنًا؟ اهدم الجدار بين التطوير والعمليات!

جمع التطوير والعمليات معًا

الخيار 1

في المؤسسات الناضجة في مجال DevOps، يعمل التطوير والعمليات كجزء من نفس فريق السكرام ويتشاركون في المسؤوليات.

الخيار 2

ومع ذلك، إذا كنت في المراحل الأولى من تطور DevOps، كيف يمكنك جعل التطوير والعمليات لديهم أهداف مشتركة ويعملون معًا؟

إليك بعض الأشياء التي يمكنك القيام بها:

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

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

تظهر خيار مثير للاهتمام بسبب الأتمتة. من خلال استخدام البنية التحتية ككود وتمكين التوفير الذاتي للمطورين، يمكنك إنشاء لغة مشتركة يفهمها كل من فرق العمليات والتطوير – وهي الكود.

حالة استخدام DevOps

اعتبر الصورة أدناه:

تظهر هذه الصورة سيرتين عمل بسيطتين

1. البنية التحتية ككود باستخدام Terraform وAzure DevOps لتوفير مجموعات Kubernetes.
2. النشر المستمر للخدمات الصغيرة باستخدام Azure DevOps لبناء ونشر صور Docker للخدمات الصغيرة في مجموعات Kubernetes.

هل يبدو هذا معقدًا؟

دعنا نقوم بتفكيكه ونحاول فهمه.

لنبدأ بالرقم 2 – النشر المستمر أولاً.

#2: النشر المستمر في DevOps مع Azure DevOps وJenkins

ما فائدة وجود اختبارات رائعة وفحوصات جودة الكود إذا لم تقم بتشغيلها بشكل متكرر؟

ما فائدة أتمتة النشر إذا لم تقم بنشر البرمجيات بشكل متكرر بما فيه الكفاية؟

بمجرد أن يلتزم المطور بالكود في نظام التحكم في النسخ، يتم تنفيذ الخطوات التالية:

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

بمجرد الموافقة من فريق الاختبار، يتم نشر التطبيق على البيئة التالية على الفور

يُعرف هذا بالنشر المستمر. إذا قمت بنشر مستمر حتى الإنتاج، يُعرف بالتسليم المستمر

أدوات CI/CD الأكثر شهرة هي Azure DevOps و Jenkins

#1: البنية التحتية لـ DevOps ككود بواسطة Terraform

في الأيام القديمة، كنا نقوم بإنشاء البيئات ونشر التطبيقات يدويًا

في كل مرة تقوم فيها بإنشاء خادم، يجب القيام بذلك يدويًا

• يجب تحديث إصدار البرنامج
• يجب تثبيت التصحيحات الأمنية يدويًا

تقوم بذلك يدويًا، والنتائج كالتالي:

• فرصة عالية لحدوث أخطاء
• البيئات المكررة صعبة

البنية ككود

البنية ككود — يعامل البنية التحتية بنفس الطريقة كشفرة التطبيق

إليك بعض الأمور المهمة لفهم البنية ككود:

• يركز فريق البنية على العمل المضاف (بدلاً من العمل الروتيني)
• أقل عدد من الأخطاء واستعادة سريعة من الأخطاء
• الخوادم متسقة (تجنب تغييرات التكوين)

أدوات IaC الأكثر شهرة هي Ansible و Terraform.

عادةً هذه هي الخطوات في IaC:

• توفير الخوادم (يتيحه السحاب) من قالب
• تثبيت البرنامج
• تكوين البرنامج

توفير الخادم

عادةً، يتم استخدام أدوات التوفير لتوفير الخوادم وإعداد الخادم الجديد مع قدرات الشبكة. أدوات التوفير الأكثر شهرة هي Cloud Formation و Terraform.

باستخدام Terraform، يمكنك توفير الخوادم وبقية البنية التحتية الخاصة بك، مثل توازن الحمل، قواعد البيانات، تكوين الشبكة، وما إلى ذلك. يمكنك إنشاء خوادم باستخدام صور مُنشأة مسبقًا باستخدام أدوات مثل Packer و AMI (Amazon Machine Image).

إدارة التكوين

تُستخدم أدوات إدارة التكوين ل:

• تثبيت البرنامج
• تكوين البرنامج

أدوات إدارة التكوين الشهيرة هي Chef و Puppet و Ansible و SaltStack. تم تصميم هذه الأدوات لتثبيت وإدارة البرمجيات على الخوادم الحالية.

دور Docker و Kubernetes في DevOps

في عالم الخدمات المصغرة، يمكن بناء بعض الخدمات المصغرة باستخدام Java، وبعضها باستخدام Python، وبعضها باستخدام JavaScript.

ستكون للخدمات المصغرة المختلفة طرق مختلفة لبناء التطبيقات ونشرها على الخوادم. هذا يجعل عمل فريق العمليات أكثر صعوبة. كيف يمكننا أن نحصل على طريقة مماثلة لنشر أنواع متعددة من التطبيقات؟ ها هي الحاويات و Docker.

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

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

يوفر Kubernetes أيضًا:

• اكتشاف الخدمة
• توازن الحمل
• التكوين المركزي

تجعل Docker و Kubernetes عملية DevOps سهلة.

مقاييس DevOps المهمة

ما يلي هي بعض من المقاييس الهامة في DevOps يمكنك تتبعها وتحسينها على مر الزمن.

• تكرار النشر — كم مرة يتم نشر التطبيقات إلى الإنتاج؟
• الوقت حتى السوق — كم من الوقت تحتاج لنقل ميزة من البرمجة إلى الإنتاج؟
• معدل فشل الإصدارات الجديدة — كم عدد الإصدارات التي تفشل؟
• وقت الرصد للإصلاحات — كم من الوقت تحتاج لإجراء إصلاح في الإنتاج ونشره إلى الإنتاج؟
• الوقت المتوسط للاسترداد — كم من الوقت تستغرق لاستعادة بيئتك الإنتاجية من مشكلة كبيرة؟

أفضل ممارسات DevOps

إدارة المشاريع السريعة

إدارة المشاريع السريعة هي نهج تكراري لتطوير تطبيقات البرمجيات. من خلال هذه الممارسة، يمكن للفرق تعزيز سرعة التطوير والاستجابة بشكل جيد لاحتياجات العملاء المتنوعة. منهجية Agile مختلفة عن الطريقة التقليدية للشلالة حيث كانت هناك دورات إصدار طويلة. تستخدم Agile إطارات Scrum و Kanban لتقديم البرنامج وفقًا لاحتياجات العميل.

استخدام مجموعة الأدوات المناسبة

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

فيما يلي بعض أمثلة على الأدوات التي يمكن استخدامها من قبل مهندسي DevOps ومسؤولي النظام وأصحاب المصلحة الآخرين:

1. تساعد الأدوات مثل Jira الفريق على تقسيم المهام إلى قطع أصغر وأكثر إدارة وبالتالي تساعد في زيادة إنتاجية الفريق. 
2. تساعد الأدوات مثل Jenkins وBitbucket في أتمتة تدفقات الشفرة مباشرة من مرحلة الاختبار إلى مرحلة النشر.
3. تساعد الأدوات مثل Slack وGetFeedback، وما إلى ذلك، فرق DevOps على دمج أدوات الدردشة مع منصات الاستطلاع لجمع ومراجعة التغذية الراجعة في الوقت الفعلي.

التكامل المستمر / التسليم المستمر

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

دمج الأمان

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

قابلية الملاحظة مهمة أثناء تطوير التطبيقات المعقدة التي تستخدم البنى المعمارية للميكروسيرفس والسحابة. تساعد قابلية الملاحظة فرق DevOps على فهم الهيكل المعقد لتطبيقات مختلفة (الميكروسيرفسات، تطبيقات السحابة، إلخ) وتساعد في معالجة احتياجات البيئة المستقبلية. قابلية الملاحظة في Kubernetes وSplunk هي بعض من أفضل منصات قابلية الملاحظة.

إشارات نضوج DevOps

• كيف تقيس نضج تنفيذاتك لـ DevOps؟
• يجب أن يكون الوقت المستغرق من عملية التطوير إلى النشر مرضيًا بشكل عام
• تحديد تردد نشر الشيفرة الجديدة
• يجب أن تكون متوسط ​​الوقت لاستعادة المعطيات (MTTR) من حادث أو حدث غير متوقع أقل ما يمكنيجب أن تتفوق النشرات الناجحة على النشرات الفاشلة
• يجب أن تؤدي الإصدارات الأسرع والموثوقة إلى عائد استثمار عالي.

أفضل الممارسات في تحويل ديفأوبس

• شراء القيادة أمر حاسم
• تنطوي على تكاليف مسبقة
• إعداد مراكز التميز لمساعدة الفرق
• اختيار التطبيق والفريق المناسب
• ابدأ بشكل صغير
• مشاركة التعلم (النشرات الإخبارية، الاتصال، مراكز التميز)
• تشجيع الأشخاص على الاستكشاف والتفكير التلقائي
• الاعتراف بفرق الديفأوبس