انشر عند كل دفع

من نشر أول يدوي إلى نشر عند كل دفع، من GitHub Actions أو GitLab CI/CD، ببيانات اعتماد لا تستطيع أكثر من ذلك، وما يحدث حين يفشل إصدار.

نصف ساعة. في النهاية يُنشر الدفع إلى فرعك الرئيسي من تلقاء نفسه، وتصير المهمّة حمراء حين يكون الإصدار سيّئًا، والإصدار السيّئ لا يُسقط الموقع.

قبل أن تبدأ

  • الـ CLI مثبّتة ومسجَّل الدخول بها. انظر تثبيت واجهة سطر الأوامر.
  • مستودع على GitHub أو GitLab، مربوط بمؤسّستك. يجب أن يعرضه isogrid repos list، وأن يتضمّن العمود YOU القيمتين create-app وdeploy. انظر مستودعات Git.
  • jq على جهازك، للخطوة 2.

يسمّي هذا الدرس التطبيق shop والمستودع acme/shop.

1. انشر مرة واحدة يدويًا

isogrid apps create --name shop --url https://github.com/acme/shop \
  --replicas 2 --public --wait

ينبغي أن ترى Build #1 succeeded.، ثم shop is running. وعنوانه. افتحه.

لا تتخطَّ هذه الخطوة. خطّ النشر الذي يفشل في تشغيله الأول قد يفشل بسبب بيانات الاعتماد أو المتغيّرات أو التطبيق. وبعد نشر يدوي أول، لا يمكن أن يكون الخطأ إلا في التطبيق.

نسختان، لا واحدة. بنسخة واحدة لا مكان لتشغيل الإصدار الجديد بينما القديم يخدم، ففي كل نشر فجوة من بضع ثوانٍ.

2. أنشئ بيانات اعتماد لخطّ النشر

ليست بياناتك أنت. واحدة لـ CI وحده، يمكن إبطالها دون تسجيل خروجك:

export ISOGRID_CONFIG_HOME="$(mktemp -d)"
isogrid --api https://api.isogrid.skyvault.pro login \
  --scope application:write-any \
  --name shop-ci

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

jq -r '.contexts[].token' "$ISOGRID_CONFIG_HOME/config.json"
rm -rf "$ISOGRID_CONFIG_HOME"
unset ISOGRID_CONFIG_HOME

ينبغي أن ترى سطرًا واحدًا طويلًا: الرمز. انسخه الآن.

لا تنسَ السطر الأخير. دونه، يظلّ هذا الطرفي يبحث عن تسجيل دخولك في مجلّد لم يعد موجودًا.

النطاق قصير عن قصد. التطبيق موجود، فلا يحتاج خطّ النشر إلى application:create، والخطأ المطبعي في اسمه يفشل بدل أن ينشئ تطبيقًا ثانيًا. وapplication:deploy-any أضيق منه، ويكفي ما دام خطّ النشر لا يمرّر أي إعدادات: لا ملف بيئة، ولا تغيير للفرع.

تدوم بيانات الاعتماد 90 يومًا ما لم تختر مدّة أقصر في صفحة الموافقة. دوّن التاريخ في تقويمك.

3. سلّمها لنظام CI

GitHub، تحت Settings → Secrets and variables → Actions: سرّ (secret) باسم ISOGRID_TOKEN، ومتغيّر (variable) باسم ISOGRID_API_URL قيمته https://api.isogrid.skyvault.pro.

GitLab، تحت Settings → CI/CD → Variables: ISOGRID_TOKEN معلَّمًا بـ Masked، وISOGRID_API_URL.

لا تعلّم الرمز بـ Protected إلا إن كان الفرع الذي ينشر محميًّا. فالمتغيّر المحميّ لا يُمرَّر إلى الفروع الأخرى، وتقول المهمّة حينها not signed in.

4. أضف خطّ النشر

في جذر المستودع:

isogrid ci init github --app shop
isogrid ci init gitlab --app shop

شغّل الأمر الموافق لمستضيف شيفرتك. ينبغي أن ترى Wrote .github/workflows/isogrid-deploy.yml (أو .gitlab-ci.yml)، متبوعًا بإعدادَي الخطوة 3. أودِع الملف (commit) وادفعه.

يجب أن يكون --app هو اسم الخطوة 1. إن أُغفل، استخدم خطّ النشر اسم المستودع. وإن اختلف الاسمان، بحث عن تطبيق غير موجود، وحاول إنشاءه، فرُفض، وهذا بالضبط ما وُضع النطاق القصير من أجله.

لا يُستبدل ملف موجود. ويطبع --output - خطّ النشر بدل كتابته، لتدمج المهمّة في الملف الذي لديك.

5. راقب التشغيل الأول

الدفع يبدؤه. في سجلّ المهمّة ينبغي أن ترى إصدار الـ CLI، ثم Started build، وBuild … succeeded.، وshop is running. المهمّة خضراء.

ما فعلته: سألت هل shop موجود، وبنت الإيداع الذي دفعته بعينه لا ما يشير إليه الفرع حينها، وانتظرت النتيجة.

إن صارت حمراء قبل أن تبني شيئًا، فاجعل isogrid whoami أول أمر في المهمّة. يطبع صاحب بيانات الاعتماد، ومؤسّستها، وما يُسمح لها به. not signed in تعني أن الرمز لم يصل إلى المهمّة. وخطأ الصلاحية يعني النطاق.

6. ادفع إصدارًا يفشل

مرة واحدة، عن قصد. اجعل التطبيق يخرج عند الإقلاع، وادفع.

ينبغي أن ترى المهمّة تفشل بـ shop was rolled back to the previous version، والسبب بعدها. افتح الآن العنوان: الإصدار السابق ما زال يجيب.

مهمّة حمراء والموقع ما زال يعمل: هذه هي المنصّة وهي تعمل. الإصدار الجديد لم يصبح سليمًا قط، فأُعيد القديم.

لمعرفة السبب، ثم الإصلاح والدفع من جديد:

isogrid apps status shop
isogrid apps logs shop

البناء الذي يفشل يوقف المهمّة أبكر، ولا يُنشر شيء إطلاقًا.

7. قرّر ما يفعله الفشل

في صفحة التطبيق، افتح عمليات النشر الفاشلة.

  • التراجع تلقائيًا هو الافتراضي: يُعاد الإصدار السابق بمجرّد أن تفشل نسخة جديدة.
  • التوقف وترك القرار لي يوقف النشر عند أول نسخة فاشلة. والنسخ التي لم تُستبدل بعد تحتفظ بالإصدار السابق.
  • عدم التراجع أبدًا يعطي كل نسخة الإصدار الجديد حتى إن فشل بعضها. مفيد لتنقيح إصدار؛ وقد يتعطّل التطبيق إلى أن تصلحه.

نافذة المراقبة (بالثواني) هي المدّة التي يجب أن تبقى فيها نسخة جديدة عاملة لتُعدّ سليمة: 30 افتراضيًا، من 5 إلى 300. ارفعها لتطبيق بطيء الإقلاع، وإلا ظلّ يُتراجع عن إصدار كان سيعمل. حفظ السياسة؛ وتُطبَّق من النشر التالي.

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

ماذا تقرأ بعد ذلك