تم تصميم DevOps لتعزيز التعاون بين التطبيقات والعمليات في التخطيط للتطبيقات والأنظمة وإنشائها ونشرها. بالمعنى الحقيقي، كان DevOps موجودًا دائمًا.
يجتمع مطورو التطبيقات ومتخصصو قواعد البيانات ومتخصصو الشبكات ومتخصصو العمليات في جلسات التخطيط قبل بدء مشاريع التطبيقات أو الأنظمة الرئيسية. في هذه الاجتماعات، ينظر فريق متعدد التخصصات من المطورين ومبرمجي الأنظمة ومتخصصي الشبكات ومحللي قواعد البيانات إلى كل مشروع من جميع الزوايا لمعرفة التأثير الإجمالي للمشروع على موارد تكنولوجيا المعلومات والبنية الأساسية.
من منظور المشروع، هناك حاجة إلى هذه الاجتماعات التمهيدية، لأنك لا تعرف حقًا مدى حجم المشروع حتى تفهم كيف يجب تعديل البنية الأساسية لتكنولوجيا المعلومات لدعم تطبيق جديد. يمكن أن تصبح تغييرات البنية الأساسية لتكنولوجيا المعلومات عملاً رئيسيًا، مثل تغيير مخطط قاعدة البيانات، أو إضافة المزيد من النطاق الترددي والأجهزة إلى الشبكة، أو تنفيذ أنظمة تشغيل جديدة، أو تعديل وحدات تشغيل النظام والبرامج الفرعية. مع تقدم المشروع، يجب أيضًا دمج كل هذه التغييرات، والمرور بضمان الجودة، والتحقق من الأداء.
في عالم مثالي، من المفترض أن يوفر DevOps أتمتة متزايدة لهذا أعمال تهيئة البنية التحتية للتطبيقات الجديدة يتم تطويرها بمنهجيات مثل Agile. الهدف النهائي لكل من Agile و DevOps هو تسريع وقت طرح التطبيق في السوق، مع عمل الجميع معًا في كل جانب من جوانب المشروع، من تطوير التطبيق إلى تكامل البنية الأساسية إلى اختبار ضمان الجودة ثم النشر.
تذكر: ما ترغب تكنولوجيا المعلومات والمستخدمون النهائيون في رؤيته هو أتمتة DevOps التي يمكنها مواكبة Agile، بالإضافة إلى منهجيات التطوير الأخرى مثل التطبيقات التي لا تتطلب أكوادًا أو تتطلب أكوادًا منخفضة.
ومن الأمثلة التوضيحية تطوير تطبيق منخفض التعليمات البرمجية.
في تطوير التطبيقات منخفضة الكود، يستطيع المستخدم النهائي أن يشير وينقر في واجهة سهلة الاستخدام على منطق البرمجة وخيارات البيانات لبناء تطبيق دون معرفة أي كود أساسي. يستطيع المستخدم القيام بذلك لأن جميع مسارات الوصول والمنطق لبناء هذا البرنامج الذي يتم بالضغط على الزر يتم أتمتة وتنفيذه نيابة عنه.
ومع ذلك، لا يمتلك هذا المستخدم أي معرفة بالبرمجة أو بالبنية الأساسية لتكنولوجيا المعلومات (على سبيل المثال، الأنظمة الأخرى وقواعد البيانات والشبكات وبرامج التشغيل والأمان وما إلى ذلك) اللازمة لتثبيت هذا التطبيق الجديد وتشغيله بالكامل. في هذه المرحلة، ينتقل التطبيق منخفض الكود إلى تكنولوجيا المعلومات، التي تكمل تكامل التطبيق واختباره ونشره.
وفي هذه الأثناء، يشعر المستخدم بالإحباط، لأنه ينتظر قسم تكنولوجيا المعلومات مرة أخرى.
يرغب مزودو حلول DevOps في حل هذه المعضلة. فهم يريدون جعل DevOps آليًا وسلسًا للغاية بحيث لا يتعين على تكنولوجيا المعلومات التدخل على الإطلاق، ولا يتعين على المستخدمين انتظار خدمات تكنولوجيا المعلومات.
لسوء الحظ، فإن عدد قليل من المواقع، إن وجدت، لديها حلول DevOps آلية بالكامل يمكنها مواكبة تطوير التطبيقات Agile وبدون أكواد ومنخفضة الكود – على الرغم من أن الجميع لديه رؤية لتحقيق أتمتة البنية التحتية المحسنة لتطبيقاتهم وأنظمتهم في يوم من الأيام.
وفيما يلي بعض الأساليب والممارسات الشائعة التي ينبغي أخذها في الاعتبار اليوم:
قم بإلقاء نظرة فاحصة على البنية التحتية كرمز (IaC).
البنية الأساسية ككود هي طريقة تمكن تكنولوجيا المعلومات من تحديد البنية الأساسية لتكنولوجيا المعلومات مسبقًا لأنواع معينة من التطبيقات التي من المحتمل إنشاؤها. من خلال تحديد وتوحيد مكونات البنية الأساسية الأساسية لتشغيل تطبيقات جديدة على Linux، على سبيل المثال، يمكنك ضمان إمكانية تكرار وتوقع أداء أي تطبيق يتم نشره على Linux، مما سيسرع عمليات النشر.
يمكن تعريف العديد من مكونات تكنولوجيا المعلومات (مثل الشبكات والخوادم الافتراضية والموصلات) داخل هذه البنية التحتية. تعد الحاويات أمثلة رائعة على IaC. لذا، لنفترض أنك تريد تشغيل تطبيق جديد عبر جميع أنظمة التشغيل المختلفة (على سبيل المثال، Linux وWindows وMacOS) التي يستخدمها المستخدمون. يمكنك القيام بذلك بالضغط على زر لأن البنية التحتية موجودة بالفعل في الحاويات المعنية حيث سيتم تشغيل التطبيق.
افهم ما ستحصل عليه عندما تبدأ في استخدام IaC.
إن الانتقال إلى IaC ليس بالأمر السهل. فهذا يعني أن مجموعة تكنولوجيا المعلومات سوف تضطر إلى الالتزام بقواعد وإرشادات، مثل عدم تغيير تكوينات البنية الأساسية الأساسية أثناء التنقل، وهو ما يتعارض مع التقييس.
إن المقايضة هنا هي أن التطبيقات قد لا تعمل بكفاءة كما لو كنت قادرًا على ضبط البنية الأساسية لتحقيق الأداء الأمثل لكل تطبيق.
خذ في الاعتبار التداعيات الثقافية المترتبة على الانتقال إلى أتمتة IaC وDevOps.
إذا كنت تنتقل إلى المزيد من الأتمتة التشغيلية والأساليب مثل DevOps وIaC التي تعمل كبرامج خلفية للتطبيقات في Agile، فلا يوجد كود أو كود منخفض، فيجب على الفرق متعددة التخصصات من المستخدمين النهائيين ومطوري التطبيقات ومسؤولي ضمان الجودة ومبرمجي النظام ومتخصصي قواعد البيانات ومتخصصي الشبكات أن تتعاون معًا في نهج تكراري لتطوير التطبيقات ونشرها وصيانتها. سيتطلب هذا المزيد من الاجتماعات والقدرة على التعاطف مع المستخدمين النهائيين وأهداف العمل، وهو أمر ليس سهلاً دائمًا بالنسبة للمتخصصين الفنيين الذين يفضلون العمل بمفردهم.
تشديد معايير التحكم في الإصدارات والنشر في تكنولوجيا المعلومات.
في كثير من الأحيان، تتعطل التطبيقات وتتحرك تكنولوجيا المعلومات بسرعة لتطبيق الإصلاح. ولكن لسوء الحظ، في ميدان المعركة، لا يتم تطبيق هذه الإصلاحات دائمًا على التطبيقات الأخرى التي تحتاج إليها. ما يمكن أن تقدمه أتمتة DevOps هو طريقة لأتمتة وتطبيق الإصلاح عالميًا، بالإضافة إلى طريقة للتحكم في الإصدارات. يمكن أن تعمل هذه الأتمتة، ولكن فقط إذا التزمت تكنولوجيا المعلومات بالقواعد ولم تحاول التحايل على الأتمتة.
لا تنسى الأمن.
نادرًا ما يتم ذكر الأمان في المناقشات حول Agile وno-and-low-code. ويبدو أن الافتراض هو أنه في مرحلة ما، ستتولى تكنولوجيا المعلومات مسؤولية الأمان.
من يناير إلى مايو 2024، ما يقرب من 36 مليون تم اختراق السجلات المعروفة.
خلاصة القول هي أن الأمان قضية خطيرة للغاية، وهو أحد العناصر التي يجب دمجها في التطوير Agile، وno-code، وlow-code، وDevOps، وIaC، وDevOps باعتباره اهتمامًا بالغ الأهمية، وليس مجرد فكرة لاحقة.
