لماذا يحتاج فريقك إلى منصة داخلية (وكيف تبدأ في بنائها)

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

"لماذا يبني كل فريق خط أنابيب خاص به من الصفر؟" "لماذا نجهز البيئات يدويًا لكل مشروع جديد؟" "لماذا ينتظر المطورون فريق البنية التحتية فقط للحصول على قاعدة بيانات اختبارية؟"

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

ما هي المنصة الداخلية في الواقع

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

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

قد تبدأ كالتالي:

• قالب خط أنابيب واحد يتضمن خطوات البناء واختبار الوحدة والفحص الأمني والنشر في بيئة الاختبار
• طريقة موحدة لتشغيل بيئة تطوير تطابق بيئة الإنتاج
• بوابة صغيرة حيث يمكن للمطورين إنشاء قاعدة بيانات اختبارية دون فتح تذكرة

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

ابدأ بما يطلبه المطورون فعليًا

لست بحاجة لتصميم المنصة المثالية مسبقًا. تحتاج إلى النظر في ما يبطئ فريقك الآن.

اسأل نفسك: ما أكثر ما يسأل عنه المطورون؟

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

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

المنصة تنمو من المشاكل الحقيقية

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

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

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

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

لماذا الاتساق أهم من السرعة

المنصة الداخلية تجعل فريقك أسرع. لكن القيمة الحقيقية هي الاتساق.

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

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

نقطة بداية عملية

إذا كنت مستعدًا لبدء بناء منصتك الداخلية، إليك قائمة تحقق بسيطة للبدء:

إليك قالب خط أنابيب GitHub Actions بسيط يغطي الخطوات الأربع المذكورة سابقًا:

name: Standard CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: make build
      - name: Unit tests
        run: make test
      - name: Security scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          format: 'sarif'
          output: 'trivy-results.sarif'

  deploy-staging:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: |
          echo "Deploying to staging environment..."
          # Replace with actual deploy command

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

المنصة تسرع، لا تستبدل

المنصة الداخلية هي مسرع، وليست بديلاً عن قدرة الفريق. إنها تسرع ما يعمل بالفعل. لا تخلق القدرة من العدم.

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

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