كيفية إعداد التكامل المستمر لتطبيق firebase الخاص بك

في أحد الأيام ، قررت أنني بحاجة لتجربة الطفل الجديد اللامع في السوق ، قاعدة النيران.

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

حتى الان جيدة جدا.

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

أنا شخصيا لم أعد أي CI لأي من المشاريع التي عملت بها. هذه هي محاولتي الأولى لإنشاء واحدة. لذلك قبل أن نذهب بعمق ، إخلاء قليلاً.

هذا ليس بأي حال من الأحوال تعليمي أو دليل خبير. إنها ببساطة سرد لرحلتي لفهم مفهوم بعيد المنال.

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

لإعداد CI ، يحتاج gitlab ببساطة إلى ملف باسم .gitlab-ci.yml في جذر المشروع. بمجرد إضافتها ، ستحاول CI المضمنة إنشاء مشروعك عن طريق تشغيل المهام كما هو مذكور في YAML.

يكفي الحديث. دعنا نرى بعض الكود :)

دعنا نحاول تقسيمها سطر واحد في وقت واحد.

الصورة: العقدة: الأحدث

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

before_script:
 - تقليم npm
 - تثبيت npm
 - npm install -g grunt-cli
 - npm install -g firebase-tools

يرشد هذا القسم CI الخاص بي إلى تشغيل مجموعة من الأوامر قبل تنفيذ أي من مراحلي. لأخذها من الأعلى ، لدينا تقليم npm الذي يستخدم حسب الوثائق:

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

بعد ذلك ، لدينا تثبيت npm لتثبيت جميع التبعيات في تطبيقي.

npm install -g grunt-cli & npm install -g firebase-tools إلى حد كبير تشرح نفسها بنفسك. آخر جوجل ذلك. :)

مراحل:
 - نشر

تعلن هذه الكتلة المراحل في خط أنابيب الإنشاء. اعتبارا من الآن ، لدينا فقط مرحلة نشر. تحقق https://gitlab.com/help/ci/yaml/README.md#stages

إذا لزم الأمر ، يمكن للمرء اختيار إضافة المجموعة بأكملها.

الانتقال ، هناك

مخبأ:
 مسارات:
 - وحدات العقدة /
 المفتاح: "$ CI_BUILD_REPO"

هذا هو الجزء الممتع. يخبر محرك CI بالتخزين المؤقت للمجلد node_modules عبر البنيات. هذا يعني أنه لا يلزم تنزيل جميع وحدات node_modules في كل مرة تشغل فيها بنية.

الوسيطة الرئيسية هي في الواقع المعرف الذي يتم من خلاله التحقق من صحة ذاكرات التخزين المؤقت. اقرأ https://gitlab.com/help/ci/yaml/README.md#cachekey

deploy_to_firebase:
 المرحلة: نشر
 فقط:
 - رئيس
 النصي:
 - نخر كل شيء
 - نشر firebase - الرمز المميز $ FIREBASE_DEPLOY_KEY

وأخيرا لدينا الجزء نشر. تم وضع علامة على هذه الكتلة publish_to_firebase. هذا هو أشبه وظيفة مخصصة. يأتي مع مجموعة من المهام التي يجب على CI تشغيلها. الذهاب سطرا سطرا ،

المرحلة: نشر

هذه علامات المرحلة هذه المهمة يشير إلى. في هذه الحالة ، يتم نشره.

فقط:
 - رئيس

هذا يخبر CI لتشغيل البنيات فقط عندما يتغير فرع الفرع الرئيسي. اقرأ https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell.

النصي:
 - نخر كل شيء
 - نشر firebase - الرمز المميز $ FIREBASE_DEPLOY_KEY

هذا هو الجزء الأخير من العرف نشر المهمة.

هنا ، نطلب من CI تشغيل مهمة النملة التي تم تكوينها مسبقًا.

تقوم هذه المهمة بنقل ES6 وتجميع ملف JSX الخاص بي وتصغير ملف css وأخيراً نسخ الملفات المدمجة إلى دليل بناء للنشر عبر السلك إلى قاعدة firebase.

ثم هناك: نشر firebase - الرمز المميز $ FIREBASE_DEPLOY_KEY

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

يتم إنشاء $ FIREBASE_DEPLOY_KEY بواسطة firebase login: ci command. اقرأ https://firebase.google.com/docs/cli/#administrative_commands.

وهذا هو.

اضغط على الرئيسي ، ويجب أن تبدأ في البناء.

حظا سعيدا وسرعة الله :)

ملاحظة: تقرأ على ES6 ، رد فعل ونخر ، وإذا لزم الأمر ، ارجع لي مرة أخرى على التعليقات.