عندما تنشر كل فريق بطريقة مختلفة

في العديد من المؤسسات الهندسية، النشر ليس قدرة مشتركة. إنه مجموعة من العادات الفردية. الفريق (أ) لديه سكربت شل يعمل من حاسوب أحد المطورين. الفريق (ب) لديه pipeline بُني منذ عامين، ولا أحد يلمسه خوفًا من أن يتعطل. الفريق (ج) يستخدم أداة مختلفة تمامًا لأن أحد المهندسين الكبار كان مرتاحًا معها. النتيجة متوقعة: عمليات النشر غير متسقة. فريق يمكنه الإصدار في خمس دقائق. فريق آخر يحتاج ساعتين. فريق لديه استرجاع آلي. فريق آخر يستعيد من النسخ الاحتياطي يدويًا.

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

مشكلة العبء المعرفي

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

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

المشكلة ليست أن الفرق مهملة. المشكلة أن معرفة النشر موزعة عبر الأفراد والسكربتات والوثائق القديمة. لا يوجد مصدر واحد للحقيقة. كل عملية نشر تبدو وكأنها مشكلة جديدة يجب حلها.

هندسة المنصات كخدمة، وليس كأداة

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

لكن المنصة ليست أداة. إنها خدمة. الفرق لا تهتم ما إذا كانت المنصة تعمل على Jenkins أو GitLab CI أو GitHub Actions أو أي شيء آخر. ما يهتمون به هو ما إذا كانت المنصة تساعدهم على النشر بأمان وسرعة ودون الحاجة للتفكير في أشياء يجب أن تكون قد عولجت بالفعل. إذا كانت المنصة معقدة جدًا أو جامدة جدًا، ستجد الفرق طرقها الخاصة للالتفاف حولها. وتعود المؤسسة إلى نقطة البداية: عمليات نشر غير متسقة.

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

ما توفره منصة النشر عمليًا

منصة النشر ليست مجرد pipeline. إنها مجموعة من القدرات التي يمكن للفرق استخدامها دون بناء بنية تحتية من الصفر. إليك ما تتضمنه المنصة العملية عادةً:

على سبيل المثال، قد يبدو قالب وظيفة GitLab CI قابل لإعادة الاستخدام كالتالي:

.deploy-template:
  stage: deploy
  script:
    - run-security-scan
    - run-integration-tests
    - deploy-canary --percentage 10
    - wait-for-health-check
    - promote-to-production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  variables:
    DEPLOY_ENV: "production"
  artifacts:
    reports:
      security: gl-security-report.json

يمكن للفرق تضمين هذا القالب في pipelines الخاصة بهم، وراثة جميع فحوصات الأمان دون إعادة تنفيذها.

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

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

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

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

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

الاتساق دون جمود

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

المنصة الجامدة جدًا سيتم رفضها من قبل الفرق. سيتجاوزونها، أو يبنون حلولهم البديلة، أو يتجاهلونها تمامًا. المنصة المرنة جدًا ستصبح فوضوية، مع استخدام كل فريق لها بشكل مختلف وفقدان المؤسسة للاتساق الذي كانت تحاول تحقيقه.

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

قائمة تحقق عملية لبناء منصة نشر

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

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

إذا كانت الإجابة على أي من هذه الأسئلة لا، فإن المنصة لم تحقق غرضها بعد.

الهدف الحقيقي

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

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