أضف هذا الشخص إلى Vercel كي ينشر. أو لا تفعل.

في وقت هذا التنفيذ، كان مقعد Vercel Pro يكلف $20. كان ثلاثة مهندسين سيكلفون $60 شهريًا، وخمسة أو ستة سيكلفون من $100 إلى $120. أبقى الفريق مقعد مشروع واحدًا بقيمة $20، ونقل تنفيذ النشر إلى GitHub Actions عبر Vercel CLI.

خزّن المستودع VERCEL_TOKEN وVERCEL_ORG_ID وVERCEL_PROJECT_ID كأسرار. وأمكن للمهندسين تسليم العمل المراجع عبر مسار الدمج المعتاد القائم على trunk من دون منح كل منهم بيانات اعتماد لوحة التحكم.

قسّمت النشر إلى سيرَي عمل. كانت عمليات الدمج إلى main تحدّث بيئة staging؛ أما الإنتاج فتطلّب إصدارًا يدويًا بعد QA ينفّذه مستخدم GitHub مصرّح له.

طلب سحب -> مراجعة -> دمج في main
  -> بناء staging ونشرها تلقائيًا
  -> QA
  -> سير عمل إنتاج مصرح به
  -> وسم، إصدار، نشر، إشعار Slack

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

كانت كل دفعة إلى main تسحب إعدادات بيئة staging، وتبني حزمة مسبقة البناء باستخدام --target=staging، ثم تنشر المخرجات نفسها. واستخدمت مجموعة تزامن مشتركة cancel-in-progress: true بحيث يحل commit أحدث على main محل نشر قديم في قائمة الانتظار أو قيد التشغيل.

concurrency:
  group: staging-deploy
  cancel-in-progress: true

- run: vercel pull --yes --environment=staging --token=$VERCEL_TOKEN
- run: vercel build --target=staging --token=$VERCEL_TOKEN
- run: vercel deploy --prebuilt --target=staging --token=$VERCEL_TOKEN

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

أعاد مسار skip-tagging منفصل استخدام أحدث إصدار لإعادة النشر. ولم يحتج الاسترداد إلى إنشاء رقم إصدار جديد زائف لمجرد إعادة تشغيل البنية التحتية.

on:
  workflow_dispatch:
    inputs:
      version_type:
        type: choice
        options: [patch, minor, major]
      skip_tagging:
        type: boolean
        default: false

بعد إصدار ذي وسم، أنشأ gh release create --generate-notes سجل التغييرات. وجمّع .github/release.yml طلبات السحب حسب التسمية. ألحق سير العمل بيانات النشر وأرسل إصدارًا منسقًا عبر Slack webhook.

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

كان التسلسل العملي بسيطًا: ادمج طلب سحب مراجعًا، وانشر staging، وتحقق منها، ثم دع مستخدمًا مصرحًا له يشغل الإنتاج. تركت وسوم الإصدارات وإصدارات GitHub ورسائل Slack أثرًا للإصدار خارج لوحة Vercel.

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