تكنولوجيا الحقائق الخاصة بك: خمس خرافات شائعة حول DevOps
إذا كنت تعمل في مجال هندسة البرمجيات أو في محيطها في العقد الماضي، فمن المحتمل أنك على الأقل على دراية بمصطلح “DevOps”.
وتَعِد هذه الفرضية بقفزة إلى الأمام في الإنتاجية وسرعة التنمية: دمج “التطوير” و”العمليات” في كيان متماسك.
ومع ذلك، فقد ضاع المعنى الأصلي والأهداف وسط سحابة من الكلمات الطنانة، والضجيج، ومغالطات “لا يوجد أسكتلندي حقيقي”، وحتى في الآونة الأخيرة نعي.
هل هو ميت حقاً، رغم ذلك؟ في هذا الجزء من “تكنولوجيا الحقائق الخاصة بك”، نفحص بعض الخرافات الشائعة حول DevOps وما إذا كان لا يزال أمامها بعض الأميال المتبقية على إطاراتها.
أسطورة DevOps رقم 1: تدور DevOps حول الأدوات
على الرغم من أن الأدوات تشكل جزءًا مهمًا من عملية DevOps، فمن المهم أن تتذكر أنها مجرد جزء من المعادلة.
الطريقة الكلاسيكية لعرض الأهمية النسبية للجوانب المختلفة لـ DevOps هي كما يلي: الأشخاص > العملية > الأدوات.
يبدو الأمر بسيطًا بما فيه الكفاية، ولكن ماذا يعني في الواقع وما هي الآثار المترتبة عليه؟ هل تحتاج مؤسسة البرمجيات ببساطة إلى المزيد من الموظفين لبناء ثقافة DevOps بنجاح؟ هل الأدوات لا تهم على الإطلاق؟ دعونا نتعمق قليلاً ونرى كيف يظهر هذا المفهوم في الحياة الواقعية.
لنأخذ بعين الاعتبار فريقًا هندسيًا (أو مؤسسة بأكملها) يتحرك من اليمين إلى اليسار في هذا التعبير؛ إنهم يبذلون قصارى جهدهم ويستثمرون بكثافة في أحدث وأفضل الأدوات والمنصات، لكنهم لا يقومون بأي استثمار إضافي في الأشخاص أو العمليات.
من المحتمل أن يكون لديهم مجموعة تكنولوجية قادرة جدًا الآن، ولكن لا يوجد أحد في طاقم العمل يعرف كيفية استخدامها بفعالية، ولا توجد عملية أو إجراءات يمكن تحديدها، والأهم من ذلك، أنهم لم يفعلوا شيئًا لتطوير وبناء ثقافة DevOps قوية.
إحدى الفلسفات الرئيسية لـ DevOps هي فكرة “التحسين المستمر”، مما يؤدي إلى إجراء تغييرات ثابتة وصغيرة ومتزايدة لتحسين البرامج وتسليمها.
ولا يقتصر الأمر على إجراء التغييرات فحسب، بل تحديد المجالات التي يجب إجراء التغييرات فيها وتعزيز الثقافة التي تشجع هذا النوع من الحوار.
لا توجد أداة أو برنامج أو منصة أو إطار عمل واحد يمكن شراؤه لتوفير هذا المستوى من التحول الثقافي.
فهو يتطلب جهدًا متسقًا من أعلى إلى أسفل من القيادة الهندسية وأصحاب المصلحة غير التقنيين والمساهمين الأفراد لجعله حقيقة واقعة، ومن هنا التركيز على “الأشخاص” بدلاً من “العملية” و”الأدوات”.
بالطبع، هذا لا يعني أنه يجب تجاهل الأدوات تمامًا أيضًا. الأدوات الأفضل تجعل الهدف الأساسي أسهل.
سيكون استخدام موفر السحابة مع Terraform أسهل بكثير في التوسع والتوظيف مقارنة بالرف القديم داخل الشركة المُدار باستخدام CFEngine .
يستفيد تطوير البرمجيات الحديثة من اختيار أفضل الأدوات للمهمة، ولكن الأدوات ببساطة ليست الصورة الكاملة.
أسطورة DevOps رقم 2: DevOps مخصص للمؤسسات الكبيرة فقط
غالبًا ما يرتبط DevOps ببيئات المؤسسات واسعة النطاق، ولكن ليس من الضروري أن يكون مخصصًا للشركات الكبيرة فقط.
لا يزال بإمكان الفرق الصغيرة الحصول على الكثير من القيمة من DevOps من خلال نهج استراتيجي تدريجي. كيف يبدو هذا النهج؟ التركيز على المكاسب الصغيرة بأقصى قدر من الرافعة المالية.
على سبيل المثال، من المرجح أن تتكون الشركات الناشئة الصغيرة بالكامل تقريبًا من مهندسي البرمجيات ومديري المنتجات.
يميل استئجار DevOps أو البنية التحتية إلى الحدوث في الدورات اللاحقة من نضج المنتج/التطبيق. إذًا ما هي المكاسب الصغيرة التي يمكن أن يحققها فريق هندسي صغير؟
- الناس: تبني نهج تعاوني لتبادل المعرفة. يجب أن يشعر المهندسون وأصحاب المصلحة غير التقنيين على حد سواء بالقدرة على التواصل عبر الفرق الوظيفية أو المؤسسات لتحقيق الأشياء. يمكن للفرق التي لديها صفحة “معلومات عنا/كيفية الاتصال” متاحة داخليًا أن تقطع شوطًا طويلًا في تعزيز هذا النوع من البيئة.
- العملية: التركيز على التغييرات المتزايدة والأسرع كفلسفة عامة. يجب أن يتم إجراء تغييرات على التعليمات البرمجية أو العملية أو الثقافة باستخدام وحدات تغيير صغيرة يسهل معالجتها. تستغرق التغييرات الضخمة والشاملة وقتًا طويلاً، وغالبًا ما تنتهي بتغييرات غير مكتملة ومتعثرة. الفرق التي تتقن تنفيذ التغييرات الصغيرة بسرعة ستجد أن ذلك سيُترجم إلى مقاييس نجاح محسنة لـ DevOps .
الأدوات: عدم وجود مهندس DevOps لا يعني أن فريقًا صغيرًا لا يمكنه الاستفادة من الأدوات التي تركز على DevOps.
تقدم العديد من الأنظمة الأساسية المستندة إلى السحابة خدمات مُدارة توفر أساسًا متينًا لتوسيع نطاق DevOps بشكل أكثر شمولاً في المستقبل.
على سبيل المثال، فإن استخدام حاويات Docker كعنصر بناء مع مستودع صور مستضاف مثل ECR أو Container Registry يمنح الفريق الهندسي إمكانية الوصول إلى مستودع عناصر مُدار بالكامل ويضع الأساس لتنفيذ تنسيق الحاوية.
أسطورة DevOps رقم 3: تتطلب DevOps إجراء إصلاح شامل لسير عمل التطوير لديك
هناك أسطورة أخرى شائعة حول DevOps وهي أنها تتطلب نسخ كل شيء والبدء من الصفر؛ وغني عن القول أن هذا لا يمكن أن يكون أبعد عن الحقيقة.
هذا لا يعني أن تنفيذ DevOps لا يتطلب أي تغيير على الإطلاق؛ من المحتمل أن يكون تحولًا زلزاليًا في الثقافة وتكوين الفريق، ولكن لا ينبغي أبدًا أن يكون هذا تغييرًا بين عشية وضحاها (تذكر التركيز على التغييرات التدريجية).
إن التركيز على الأشخاص والعمليات أولاً يعني أنه من الممكن (بل وينبغي) تجنب التغييرات التقنية الهائلة. الهدف هو تقديم الأدوات التي تدعم التحول الثقافي المستمر حسب الحاجة ببطء.
ولهذا النهج فائدة إضافية تتمثل في تسهيل الحصول على موافقة القيادة الفنية أيضًا؛ إنه يتجنب التكلفة الأولية الهائلة المرتبطة عادةً بإجراء إعادة هيكلة واسعة النطاق وإدخال الكثير من الأدوات الجديدة.
هناك طريقة رائعة لتقديم بعض ثقافة DevOps إلى سير عمل تطوير البرامج دون حدوث أي إزعاج وهي إضافة خطافات الالتزام المسبق.
يفترض هذا بالطبع أن المطورين يرسلون التعليمات البرمجية إلى مستودع التحكم في الإصدار المستند إلى Git؛ إذا لم يكن الأمر كذلك، فإن تغيير ذلك يصبح على الفور الأولوية الأولى في تغيير سير عمل التطوير! يوفر Git ميزة تسمى الخطافات، والتي تطلق إجراءات أو نصوص برمجية محددة بناءً على حدوث أحداث معينة (مثل الالتزام).
يقدم الالتزام المسبق إطارًا موحدًا يجعل مشاركة هذه الخطافات وتوزيعها أسهل بكثير. من موقعهم:
“… لقد قمنا ببناء التزام مسبق لحل مشكلات الخطافات لدينا. إنه مدير حزم متعدد اللغات لخطافات الالتزام المسبق.
يمكنك تحديد قائمة من الخطافات التي تريدها ويقوم الالتزام المسبق بإدارة تثبيت وتنفيذ أي خطاف مكتوب بأي لغة قبل كل التزام.
تم تصميم الالتزام المسبق خصيصًا بحيث لا يتطلب الوصول إلى الجذر.
إذا لم يكن لدى أحد المطورين لديك عقدة مثبتة ولكنه قام بتعديل ملف JavaScript، فإن الالتزام المسبق يتعامل تلقائيًا مع التنزيل وبناء العقدة لتشغيل eslint بدون جذر “.
يعد التحقق من الأخطاء الأساسية في الفحص أو بناء الجملة لمنع الالتزام بالقيم الحساسة أو ضمان إصدار التبعيات بشكل صحيح مجرد بعض الطرق التي يمكنك من خلالها استخدام خطافات الالتزام المسبق الأساسية.
يؤدي فرض عمليات الفحص هذه قبل مراجعة التعليمات البرمجية إلى توفير وقت ثمين لمراجعي التعليمات البرمجية، مما يسمح لهم بالتركيز على المنطق الفعلي وبنية التغيير المقترح.
إذا كانت المراجعات أسرع وأكثر كفاءة، خمن ماذا: لقد قمت للتو بتحسين سرعة النشر وقمت بإجراء تغيير تدريجي على سير عمل التطوير الخاص بك.
مع نمو تعقيد الفريق والنظام، يمكن أن يتحول هذا إلى خط أنابيب CI/CD متكامل المزايا ومؤتمت مع بيئات الاختبار والتدريج أيضًا.
أسطورة DevOps رقم 4: تحل DevOps محل التطوير والعمليات وفرق تكنولوجيا المعلومات
DevOps هو نهج فلسفي لتطوير البرمجيات والعمليات التي تسعى إلى تحسين التعاون بين ما كان يعتبر في السابق مجالات معرفة منفصلة تمامًا وصوامع العمل.
مع أخذ ذلك في الاعتبار، لا ينبغي تفسير DevOps على أنه بديل للأدوار التقليدية مثل التطوير أو العمليات أو تكنولوجيا المعلومات.
يتطلب وجود ثقافة التحسين المستمر الموارد والاهتمام عبر المؤسسة الهندسية بأكملها. DevOps هو إطار عمل يجب أن يُنظر إليه على أنه مكمل ومضاف إلى الأدوار والمسؤوليات الحالية وليس شيئًا يحل محلها بالكامل.
اختر مقياس DORA للتركيز عليه: تكرار النشر، وهو يقيس بشكل أساسي عدد المرات التي يتم فيها نشر التغيير بنجاح أو إصداره في بيئة اتفاقية مستوى الخدمة للإنتاج.
فكر الآن في هذا المقياس في سياق فكرة أن DevOps ستحل بطريقة ما محل بعض عناصر طاقم الهندسة أو العمليات. هل يؤدي استبدال أي فريق بشكل مباشر إلى زيادة وتيرة النشر أو سرعته؟
إنه أمر مستبعد جدًا. في الواقع، من المرجح أن يؤدي تقليل عدد الموظفين إلى انخفاض الروح المعنوية وزيادة الإرهاق وزيادة كبيرة في انقطاع التيار الكهربائي وغيرها من المشكلات.
إن التركيز الذي يركز على الأفراد على التحسين المستمر يعني أنه يجب منح الفرق الحالية فرصة للنمو وتطوير مهاراتهم التقنية والشخصية حيث تتبنى المؤسسة الأكبر عقلية DevOps بشكل كامل.
أسطورة DevOps رقم 5: لقد ماتت DevOps
ها نحن، قلب الوحش، الروايات العديدة التي تبلورت في الآونة الأخيرة.
- لا يريد المطورون “القيام” بـ DevOps لأنه صعب للغاية.
- DevOps هو نمط قديم تم استبداله بواسطة فريق النظام الأساسي.
- تعني مجموعة أدوات تطوير السحابة (CDK) أن المطورين لن يحتاجوا إلى العمل مع مهندسي DevOps بعد الآن.
هذه كلها أفكار جديدة ومختلفة، ولكن بكل بساطة: DevOps لن يموت بفترة طويلة.
كيف نفكر في DevOps وأفضل الطرق لتحقيق أقصى قدر من الإنتاجية والسعادة للمطورين، لكن الأهداف الأساسية تظل كما هي. حتى لو شاركت مؤسسة ما في مفهوم هندسة النظام الأساسي وشارك المطورون بشكل كامل في تكوين البنية التحتية عبر CDK، فهذا لا يعني أن “DevOps” قد مات.
ستظل الفلسفة الأساسية والتركيز دائمًا كما هو.
يصبح الخطر الكامن في ربط فكرة DevOps بأداة أو منصة معينة واضحًا: سيكون التحسين المستمر دائمًا مهمًا لتطوير البرمجيات، بغض النظر عن الأدوات المستخدمة.
مع استمرار المنصات المتطورة في تشكيل المشهد خلال مستقبل هندسة البرمجيات، ستظل DevOps في طليعة تمكين عمليات النشر السريع، وضمان معايير هندسة الجودة، وتوسيع نطاق العمليات عالميًا، وتحسين العمليات الأمنية والمزيد.
ضع في اعتبارك أن أساطير DevOps هذه قد تم كسرها.
DevOps لن يذهب إلى أي مكان. إنها تتطور فقط مع تطور تطوير البرمجيات والأنظمة الموزعة. سيكون التركيز على التحسين المستمر والثقافة دائمًا في قلب مبادرة DevOps الجيدة.
لا ينبغي للمؤسسات والمهندسين على حد سواء أن يقلقوا بشأن “موت DevOps”، أو اختيار الأداة المناسبة، أو توظيف مهندسين يتمتعون بالمزيج الدقيق من المهارات.
طريقة البدء هي إجراء تحسينات صغيرة ومركزة وهادفة على سير عمل وثقافة تطوير البرامج لديك. استمر في التحسين المستمر، وسوف تجني مؤسستك فوائد DevOps النشطة للغاية.
المصدر: pluralsight
شاهد المزيد:
