مرحبا بالجميع!
قمنا بطباعة
كتاب "فلسفة DevOps" ونخطط أيضًا لعمل كتاب جديد حول هذا الموضوع.
يتم نسخ الكثير من النسخ حول ما هو DevOps وما هو ليس كذلك ، بالإضافة إلى العلاقة بين DevOps والتكامل المستمر. لذلك ، نطلب منك التحدث بموضوعية قدر الإمكان ، هل تشارك وجهة نظر مؤلف اليوم آدم ماكاي (آدم ماكاي) فيما يتعلق بجوهر DevOps - أو ، في رأيك ، الصورة التي اقترحها غير مكتملة أو متحيزة إلى حد ما؟
نقرأ ونعلق!
لقد عملت في المجال التكنولوجي طوال حياتي ، وأمام عيني نضجت العديد من منهجيات تطوير البرمجيات وتشكلت. تعود معظم الأفكار التي تقوم عليها إلى التحسين المعتاد للإنتاجية بروح الفطرة السليمة ويتم استعارتها من مختلف قطاعات الاقتصاد. قبل بضع سنوات ، أراد الجميع الانتقال من نموذج تطوير الشلال إلى التنمية الرشيقة الرشيقة. ذهبت مؤخرًا للعمل في شركة تقدمية ، حيث يحاولون تنفيذ DevOps. هذه الشركة ، Verifa ، تلتزم منذ فترة طويلة ب Agile وتحاول توسيع مزايا هذا النموذج ليس فقط لتطوير البرمجيات ، ولكن أيضًا للعمل ككل.
DevOps هي كلمة طنين جديدة في صناعة البرمجيات. يجمع هذا المفهوم بين الكثير من الأفكار السليمة حول دمج الأعمال التجارية والتنمية ، بالإضافة إلى صياغة سرد يسمح لنا بالتحدث عن تطوير البرنامج وتشغيله في سياق واحد.
DevOps هو نهج يشارك فيه مهندسو التطوير والمهندسون الإداريون معًا في دورة حياة منتج البرنامج بالكامل ، بدءًا من التصميم والتطوير وصولًا إلى الدعم الشامل للمنتج. وبالتالي ، تم تصميم DevOps للقضاء على الانقسام التقليدي ، حيث يكتب فريق واحد الرمز ، والاختبارات الأخرى عليه ، وينشر الثالث ، والرابع مسؤول عن العملية.
مع DevOps ، يبدأ موظفو مسؤول النظام في استخدام ، بدعم من الأنظمة الموكلة إليهم ، العديد من التقنيات التي تم إصلاحها في ترسانة المطور. في DevOps ، تم تصميم هندسة النظم تمامًا مثل تدفق المهام أثناء التطوير. يتم إدخال جميع الموارد في نظام محاسبة المصدر وتغطيها الاختبارات المناسبة.
لدينا العديد من موضوعات DevOps الرئيسية في شركتنا: القيم والمبادئ والأساليب والممارسات والأدوات.
القيميتم سجن أي مهندس لإيجاد حل ، ويترجم مثل هذا الطموح أحيانًا إلى رفض التقنيات الجديدة ، وعدم الرغبة في تجربة أشياء جديدة ، والتي يتم التعبير عنها بطرق مختلفة: من متلازمة "رفض تطور شخص آخر" إلى محاولات عكسية للدفاع عن مكانه. للانتقال حقًا إلى DevOps ، يجب أولاً الاعتراف بهذه الأحكام المسبقة ثم التغلب عليها. لا توجد تقنية ، ولا Docker أو Kubernetes أو Amazon Web Services سوف تحل مشاكلك إذا لم تفهم ما هو عرض القيمة.
"امسك أيدي الأصدقاء!"
لقطة Rawpixel من
Unsplashالمبادئتستند مبادئ شركتنا على نموذج الطرق الثلاثة. تم تطويره من قبل جين كيم ، مؤلف "Visible Ops" و "The Phoenix Project" ، ومايك أورزين ، مؤلف "Lean IT". نوصي ببناء بيئة يتم فيها تحفيز التفكير النظامي ، وتعزيز دورات التغذية الراجعة ، وغرس ثقافة التجريب المستمر والتعلم.
فكر باستمرار في النظام بأكمله. اسأل نفسك: "كيف تحصل على المزيد من حلقات التغذية الراجعة؟" المراقبة والقياسات وتسجيل الدخول هي ثلاث من هذه الدورات التي تساعد المسؤولين على المشاركة في التصميم. في بيئة DevOps الصحية ، يتم تحفيز العمليات التي تعزز إنشاء دورات تغذية مرتدة قصيرة وفعالة ، ومن الأمثلة على هذه العمليات إدارة الحوادث ، والتحليل الموضوعي للوفاة ، والشفافية ...
"مصافحة قبل MacBook Pro" ، لقطة من
rawpixel من
Unsplashطرقإدارة مرنةمرن = بسيط. قسّم مشروعك إلى مجالات عمل صغيرة ، وقم ببناء ، والحد من التقدم ، وتنفيذ حلقات التغذية المرتدة وتحقيق التصور. هذا هو العنصر المفضل لدي في أي مشروع. تقنيات الإدارة المرنة تعطي نتائج أكثر فعالية ، بما في ذلك تحسين إنتاجية النظام واستقراره ؛ يعاني الموظفون من ضغط أقل في العمل ويحصلون على مزيد من الرضا الوظيفي.
الناس أولاً ، ثم العمليات ، ثم الأدواتتمت صياغة إحدى المنهجيات الأولى التي اقترحها رواد DevOps على أنها "الأشخاص الأوائل ، ثم العمليات ، ثم الأدوات". في شركتنا ، يوصى بأن توافق أولاً على المسؤول عن مهمة عمل معينة. ثم نحدد العمليات اللازمة لحل هذه المشكلة. بعد ذلك ، يتم اختيار الأدوات اللازمة لتنفيذ العملية. على الورق ، يبدو كل هذا منطقيًا ، ومع ذلك ، غالبًا ما يستسلم المهندسون والمديرون إلى "أسرع في الحصول عليه!" من الموردين وفي هذه الحالة يحاولون القيام بالعكس تمامًا: شراء أداة ، ثم تشكيل تدفق المهام بالكامل لها.
التسليم المستمرهذا المصطلح يتعلّق بشفاه الجميع لدرجة أنه أحيانًا يكون معادلًا خطأً مع DevOps. من حيث المبدأ ، هذه هي ممارسة البرمجة الديناميكية واختبار البرمجيات ، مما يوفر إصدارات سريعة من أجزاء صغيرة جدًا وكاملة وجاهزة. بشكل عام ، يمكن أن يؤدي التسليم المستمر إلى تحسين الجودة والسرعة بشكل عام. يُعد التسليم المستمر أحد المكونات الرئيسية للمشروع ، والذي يجب إنشاؤه في أقرب وقت ممكن ، وهو العامل الدافع للتنفيذ الناجح لـ DevOps.
إدارة التغيير
في تجربتي ، هناك ارتباط مباشر بين مدى جودة تشغيل النظام وكيفية تنظيم إدارة التغيير. هذا لا يعني أنك بحاجة إلى تنفيذ التحكم التقليدي ، مما يبطئ عملية التطوير ويحتمل أن يكون ضارًا أكثر من المساعدة. في هذه الحالة ، تحتاج إلى منصة قابلة للتطوير وموثوقة للتسليم المستمر. التركيز على التخلص من القطع الأثرية الهشة ، وإعادة إنتاج عملية البناء ، وإدارة التبعيات ، وخلق بيئة مواتية للتحسين المستمر.
البنية التحتية في التعليمات البرمجية (التكوين في التعليمات البرمجية ... كل شيء في التعليمات البرمجية)أحد الاكتشافات التي أثرتها لي الشركة الحالية هو أنه يمكن وينبغي تفسير أي نظام على أنه رمز. يتم إدخال مواصفات النظام في أنظمة التحكم في الإصدار ومراجعة النظراء. باستخدام آليات النشر الحديثة ، على وجه الخصوص ، Docker و Kubernetes ، يمكنك تلقائيًا إنشاء أنظمة حقيقية واختبارها وإنشائها بناءً على المواصفات وإدارتها برمجيًا. يسمح لك هذا النهج بتجميع النظام وتشغيله ، وعدم جعل العكازات الشاقة طويلة المدى ، والتي يصعب تطويرها بمرور الوقت.
تدربفي جميع مؤسسات تكنولوجيا المعلومات السابقة التي عملت فيها ، كان نهج المشاريع هو: "دعنا نكتب شيئًا ... وبعد ذلك سنوجه شخصًا لاختباره ونشره." لا تتناسب هذه الطريقة بشكل جيد مع الخطط ، حيث يتغير التوقيت ، وعندما ينتقل فريق التطوير إلى المشروع التالي ، تصبح تكاليف التشغيل غير محتملة.
"السفينة الدوارة تحت السماء الزرقاء والسحب البيضاء" ، لقطة من
Priscilla Du Preez من
Unsplashفي المؤسسة الحالية ، نسعى جاهدين لإبقاء المطورين على اطلاع بالخدمة التي أنشأوها ومسؤولة جزئيًا عن تشغيلها. والنتيجة هي دورات ردود فعل أكثر فعالية تساعد الفريق على الاستجابة بسرعة أكبر ليس فقط للأخطاء ، ولكن أيضًا للميزات الجديدة وضمان تطوير المنتج في الاتجاه الصحيح.
الأدواتنحن نحب أدواتنا! فهي تساعد برنامج المهندس ، وتجميع ، واختبار ، وحزم ، وإطلاق ، وتكوين وتتبع كل من الأنظمة والتطبيقات. نحن نمتلك أدواتنا ببراعة ونعرف مجموعة كاملة من الحلول التي تهمنا - سواء مفتوحة المصدر أو تجارية. قبل أن يبدأ نموذج DevOps في التطور ، كان الابتكار والأدوات في حالة ركود. لفترة طويلة ، استخدمت نفس الأدوات المستخدمة في بداية مسيرتي المهنية (لقد كنت أبرمج منذ عام 2000). العديد من الأدوات المستخدمة في DevOps متعددة الاستخدامات بشكل مذهل وتساعد على تنظيم دورة حياة الخدمة بطريقة جديدة تمامًا.
"جميع أنواع أدوات النجارة في ورشة العمل" من مجموعة
Barn Images من
Unsplashتحتاج إلى تحديد أدوات موثوقة لـ DevOps. لا توجد أداة واحدة لجميع المناسبات ، فأنت بحاجة إلى خط كامل ، يمكن دمج مخزونه مع مراعاة الاحتياجات الحالية. وبما أننا نريد أن يعمل كل هذا معًا ... فإن أي أداة مفيدة فقط لأنها تساعد نظامنا بالكامل.
تحتاج إلى اختيار الأدوات التي تعمل بشكل جيد مع بقية المخزون الخاص بك. يجب أن تساعد الأدوات في أتمتة أي عمل. يجب أن يكون من السهل الاتصال بهم من API أو من سطر الأوامر. من حيث المبدأ ، لا تتناسب الأدوات التي تعتمد بشكل كبير على واجهة المستخدم بشكل جيد للغاية حتى في الأدوات المتكاملة جيدًا.
ما هي الخطوة التالية ...قم بتنزيل صورة عامل الميناء وابدأ التجربة. احملي كود شخص آخر وابدئي في بنائه. نشر خادم أو كتلة خادم مع Kubernetes. لذلك أنت تفعل DevOps. ابدأ على جهاز الكمبيوتر الخاص بك ، ثم انتقل إلى السحابة.
"صبي يقف على الدرج ويصل إلى الغيوم" ، من تصوير صامويل زيلر من Unsplashعندما تسمع لأول مرة عن نموذج "البنية التحتية في التعليمات البرمجية" أو "التسليم المستمر" ، فأنت تريد على الفور أن تقول "لا ، إنها تعمل معنا بشكل مختلف". ومع ذلك ، من أجل النجاح مع DevOps ، تحتاج إلى إتقان هذه التقنيات تدريجيًا ، فهي ليست معقدة للغاية. لسنوات عديدة ، استخدمت الصناعة أساليب معاكسة تمامًا لـ DevOps ، لكن DevOps يعمل حقًا.