أريد أن أبدي تحفظًا على الفور: لا تقدم هذه المقالة وصفة جاهزة للاستخدام. إنها بالأحرى قصتي في السفر إلى عالم Typescript و NodeJS ، وكذلك نتائج تجاربي. ومع ذلك ، في نهاية المقال ، سيكون هناك رابط إلى مستودع GitLab ، والذي يمكنك أن ترى ، وربما تأخذ شيئًا تريده لنفسك. ربما حتى في تجربتي ، قم بإنشاء الحل الآلي الخاص بك.
لماذا هو ضروري
لذا ، لماذا تحتاج إلى إنشاء مكتبات على الإطلاق ، أو في حزم NPM في حالة معينة؟
- إعادة استخدام الرمز بين المشاريع.
بدأ كل شيء بحقيقة أنني لاحظت عادة إنشاء مجلد / أدوات في المشاريع. بالإضافة إلى ذلك ، آخذ معي أيضًا معظم هذا المجلد عندما أقوم بالتبديل إلى مشروع جديد. ثم طرحت على نفسي سؤالًا ، لماذا لا أقوم بإنشاء حزمة NPM بدلاً من نسخ اللصق ، ثم قم بتوصيله بأي مشروع؟ - دورة حياة مختلفة. في أحد التطبيقات ، كان هناك مجموعة كبيرة من المكونات للشركات تبعية. كان من الممكن تحديثه فقط بالكامل ، حتى لو تم تحديث مكون واحد فقط. التغييرات في المكونات الأخرى يمكن أن تكسر شيئًا وليس دائمًا لدينا وقت كافٍ لإعادة اختباره. هذا النموذج غير مريح للغاية. عندما تخدم كل حزمة غرضها أو مجموعة صغيرة من الأهداف ذات الصلة ، يمكن تحديثها بالفعل عند الحاجة إليها. أيضًا ، يتم إصدار الإصدارات التالية من الحزمة فقط عندما يكون لديهم بعض التغييرات ، وليس "للشركة".
- افصل الكود البسيط عن منطق العمل الأساسي. DDD لديها مبدأ تقطير المجال ؛ فهو يتضمن تحديد أجزاء من الكود التي لا تنتمي إلى المجال الرئيسي وعزل نفسها عنها. وكيف يكون عزل أفضل من أخذ هذا الرمز في مشروع منفصل.
بالمناسبة ، يشبه تقطير المجال مبدأ SRP فقط على مستوى مختلف. - تغطية رمز الخاصة. في أحد المشاريع التي شاركت فيها ، بلغت التغطية بالرمز حوالي 30٪. والمكتبة التي أخرجتها لها تغطية حوالي 100 ٪. المشروع ، رغم أنه فقد نسبة التغطية ، كما كان في المنطقة الحمراء قبل الإزالة ، إلا أنه ظل. والمكتبة لديها مثل هذه المؤشرات تحسد عليه حتى يومنا هذا ، بعد ما يقرب من عام و 4 إصدارات رئيسية.
- المصدر المفتوح الرمز الذي لا يحتوي على منطق العمل هو المرشح الأول للانفصال عن المشروع ، بحيث يمكن فتحه.
إطلاق مكتبات جديدة "غالية"
هناك مشكلة من هذا القبيل: من أجل إنشاء مكتبة ، لا يكفي الحصول على مستودع بوابة. تحتاج أيضًا إلى تكوين المهمة بحيث يمكن تجميع المشروع وإجراء التحقق الثابت (الوبر) والاختبار. أيضًا ، بالإضافة إلى الاختبار ، يُنصح بجمع تغطية الشفرة. بالإضافة إلى ذلك ، سيكون عليك نشر الحزمة يدويًا في كل مرة. ولا تزال بحاجة إلى كتابة التمهيدي. هذا فقط مع التمهيدي لا أستطيع المساعدة.
لذا ، ما الذي يمكن القيام به مع كل هذه المهام المملة غير المثيرة للاهتمام؟
الخطوة الأولى: البذور
لقد بدأت بإنشاء مشروع أساسي. إنه نوع من أدوات بداية التشغيل ، وكان له نفس هيكل مشروعي الأول لأخذ الرمز في حزمة منفصلة. لقد أنشأت في ذلك المهام والبرامج النصية التي من شأنها بناء واختبار وجمع تغطية الحزمة في إجراء واحد. الآن ، لإنشاء مشروع آخر ، كنت بحاجة لاستنساخ البذور في مجلد جديد وتغيير الأصل بحيث يشير إلى مستودع تم إنشاؤه حديثًا على GitHub (ثم ما زلت استخدم GitHub).
هذه الطريقة لإنشاء المشاريع توفر ميزة أخرى. الآن ، يتم إجراء التغييرات المتعلقة ببناء أو اختبار المشروع مرة واحدة ، في مشروع البذور. ونسخ لصق هذه التغييرات لم تعد ضرورية. بدلاً من ذلك ، في المشروع النهائي ، في المرة القادمة التي يجب أن أعمل فيها ، أقوم بإنشاء جهاز تحكم عن بعد ثانٍ يسمى البذور وأخذ هذه التغييرات من هناك.
وانها عملت بالنسبة لي لفترة من الوقت. حتى استخدمت البذور في مشروع شارك فيه العديد من المطورين. لقد كتبت تعليمات في ثلاث خطوات: خذ آخر ماجستير ، والبناء والنشر. وفي مرحلة ما ، أكمل أحد المطورين ، لسبب ما ، الخطوة الأولى والثالثة. كيف يكون هذا ممكنًا؟
الخطوة الثانية: النشر التلقائي
على الرغم من حقيقة أنه كان خطأً واحدًا ، فإن الإجراءات اليدوية مثل النشر مملة. لذلك ، اعتقدت أنه كان من الضروري لأتمتة ذلك. بالإضافة إلى ذلك ، كانت هناك حاجة CI لمنع ارتكاب ارتكاب الحمراء من سيد. في البداية حاولت استخدام Travis CI ، لكن واجهت القيود التالية. إنه يعتبر طلب السحب في الماجستير يعادل الالتزام بالسيد. وكان علي أن أفعل أشياء مختلفة.
نصحني أحد زملائي بالاهتمام بـ GitLab و CI التابعة لها ، وكل ما أريده كان يعمل هناك.
لقد أنشأت العملية التالية للعمل مع المشروع ، والتي يتم استخدامها عندما تحتاج إلى إصلاح الخلل أو إضافة وظائف جديدة أو إنشاء إصدار جديد:
- أنا إنشاء فرع من سيد. أنا أكتب رمز والاختبارات في ذلك.
- أقوم بإنشاء طلب دمج.
- يقوم GitLab CI تلقائيًا بإجراء الاختبارات في عقدة: حاوية أحدث
- يمرر الطلب مراجعة الكود.
- بعد تجميد الطلب ، تدير GitLab المجموعة الثانية من النصوص. تنشئ هذه المجموعة علامة على الالتزام برقم الإصدار. يتم أخذ رقم الإصدار من package.json ، إذا تم زيادته يدويًا هناك ، وإذا لم يكن كذلك ، فسيتم أخذ أحدث إصدار منشور وزيادة تلقائية.
- البرنامج النصي يبني المشروع ويدير الاختبارات مرة أخرى.
- في الخطوات الأخيرة ، يتم إرسال علامة الإصدار إلى المستودع ويتم نشر الحزمة على NPM.
وبالتالي ، فإن الإصدار المشار إليه في العلامة يطابق دائمًا إصدار الحزمة المنشورة من هذا الالتزام. لكي تعمل هذه العمليات ، تحتاج إلى تحديد متغيرات البيئة باستخدام مفاتيح الوصول إلى المستودع و NPM في مشروع GitLab.
الخطوة الأخيرة: أتمتة كل شيء
في هذه المرحلة ، قمت بالفعل بأتمتة الكثير ، ولكن لا يزال هناك الكثير من الإجراءات اليدوية لإنشاء مشروع. هذا ، بالطبع ، كان بالفعل تقدمًا على أي حال ، لأن الإجراءات تم تنفيذها مرة واحدة لكل مشروع ، وليس على كل إصدار. ولكن لا يزال ، وتألفت التعليمات من 11 خطوة. وأنا شخصياً كنت مخطئًا عدة مرات من خلال اتخاذ هذه الخطوات. ثم قررت أنه منذ أن بدأت التشغيل الآلي ، أحتاج إلى إنهاء هذا الأمر.
لكي تعمل هذه الأتمتة الكاملة ، لكن الكمبيوتر أحتاج إلى 3 ملفات في المجلد .ssh. اعتقدت أن هذا المجلد محمي تمامًا ، لأن المفتاح الخاص id_rsa مخزّن بالفعل هناك. سيتم استخدام هذا الملف أيضًا لتمكين GitLab CI من تمرير العلامات إلى المستودع.
الملف الثاني الذي وضعته هناك هو "gitlab" ، وهو يحتوي على مفتاح الوصول إلى GitLab API. والملف الثالث هو "npm" ، وهو مفتاح الوصول لنشر الحزمة.
ثم يبدأ السحر. كل ما تحتاج إليه لإنشاء حزمة جديدة هو تشغيل أمر واحد في المجلد الرئيسي: "gulp startNewLib -n [npmName] / [libName]". تم ، تم إنشاء الحزمة ، جاهزة للتطوير والنشر التلقائي.
على سبيل المثال ، تم إنشاء الحزمة "vlr / validity" بهذه الطريقة.
يقوم هذا الأمر بما يلي:
- يخلق مشروع على GitLab
- استنساخ البذور إلى مجلد محلي بجوار المجلد الذي يتم تشغيل الأمر منه.
- تغيير الأصل إلى المشروع الذي تم إنشاؤه في الخطوة 1
- ادفع الفرع الرئيسي
- ينشئ متغيرات البيئة في مشروع من ملفات في مجلد .ssh
- يخلق أول فرع للتنفيذ
- يغير اسم المكتبة في package.json ، يرتكب ويدفع الفرع
كل ما تحتاجه بعد ذلك هو وضع الكود هناك وإنشاء طلب دمج.
نتيجة لذلك ، والتي يمكن أن نفخر بها ، من اللحظة التي تقرر فيها وضع نوع من التعليمات البرمجية في مشروع منفصل حتى يتم نشر الإصدار الأول ، يستغرق الأمر حوالي خمس دقائق. يشغل أربعة منهم خطي أنابيب GitLabCI ، ودقيقة واحدة لبدء تشغيل الأمر أعلاه ، واسحب الكود وإفلاته ، وانقر على الأزرار الموجودة في واجهة GitLab لإنشاء الطلب مع الاستمرار.
هناك بعض القيود: يجب أن يتطابق اسم GitLab مع الاسم في npm. ومع ذلك ، فإن هذا الأمر ، بخلاف بقية الوظائف في المشروع الأولي ، يعمل فقط على نظام Windows.
إذا كنت مهتمًا بهذا المشروع الأولي ، يمكنك
دراسته على الرابط التالي .