لقد قمت مؤخرًا بعمل برنامج تعليمي حول كيفية استخدام Travis CI كأداة لاختبار الكود الذي دفعته للتو أو حاولت دفعه إلى فرع master تلقائيًا. مما يجعل تجميعه واختباره وإبلاغك أخيرًا بحالة هذا التغيير.

ولكن يمكننا الاستمرار في تحسينها **على سبيل المثال، المكتبة الأساسية التي تم إنشاؤها في هذا البرنامج التعليمي الأخير، أريد أن أجعلها عامة باستخدام موجز NuGet، حتى يتمكن الجميع من إجراء عملية سهلة في مكتباتهم!

ولكن كيف؟ كيف سنقوم بتجميع هذه الحزمة واختبارها ثم نشرها في الموجز ليتمكن الجميع من تنزيلها في مشاريعهم؟

حسنًا، هذا هذا البرنامج التعليمي لـ 😁!

ما الجديد؟

لا توجد أي تغييرات تقريبًا فيما يتعلق بالكود، والأشياء التي نحتاج إلى تغييرها هي التعبئة والنشر ومن ثم كيف يمكننا أتمتتها.

.NET CLI الأساسية

سنستخدم .NET Core CLI، الذي استخدمناه في البرنامج التعليمي السابق مع أوامر مثل dotnet restore، dotnet build و dotnet test.

الآن سوف نستخدم مجموعة جديدة من الأوامر!

dotnet nuget

يمكنك التحقق من الوثائق الخاصة بمجموعة الأدوات هذه هنا، ولكن مع شرح مختصر:

dotnet nuget عبارة عن مجموعة من الأدوات الأساسية التي تتضمن تثبيت الحزم واستعادتها وإزالتها ونشرها.

تغذية نوجيت

NuGet هو مدير الحزم لـ .NET. توفر أدوات عميل NuGet القدرة على إنتاج الحزم واستهلاكها. يعد NuGet Gallery مستودع الحزم المركزي الذي يستخدمه جميع مؤلفي الحزم والمستهلكين.

NuGet مجاني، لذا يمكنك التسجيل والتقاط مفتاح API الخاص بك والبدء في تحميل الحزم. سيتم تحميلها والتحقق منها ثم إدراجها في الجميع.

احصل على مفتاح API

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

ضع في اعتبارك أن مفتاح واجهة برمجة التطبيقات (API) تنتهي صلاحيته لمدة 365 يومًا.

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

إنشاء حزمة NuGet

الآن بعد أن حصلنا على المفتاح API، فإن خطوتنا التالية هي إنشاء حزمة NuGet من الحل، لذا تابع وافتح الحل حيث توجد مكتبة الفصل الخاصة بك.

سأستخدم الحل من البرنامج التعليمي الأخير، والذي يحتوي على فئة مكتبة .NET Core تسمى CalculatorCLI.Core.

انتقل الآن إلى خصائص المشروع ثم الحزمة، وسترى الكثير من المعلومات المتعلقة بالحزمة مثل إصدار الحزمة والمؤلفين والأوصاف والمزيد.

التالي هو ملء هذا، ليس عليك حقًا ملء كل شيء، ولكن العناصر المهمة والإلزامية هي Package id، Package version، Authors و Description. وأيضًا إذا حاولت تحميل الملف بنفسك، فسوف يطلب License، وسنحتاج إلى إضافته أيضًا.

ثم يمكنك الحفظ، انقر بزر الماوس الأيمن في المشروع وحدد Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

سيُظهر الإخراج أنه إذا كان كل شيء على ما يرام، فسيتم طباعة Successfully created package.

استخدام dotnet

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

تلك الأوامر هي:

1. dotnet pack -c <configuration>
2. dotnet nuget push <package> <k <apikey> -s <source>

البرامج النصية للنشر

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

لذلك دعونا ننشئ مجلدًا يسمى scripts بثلاثة نصوص bash في جذر المستودع.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

تحسين ملف .travis.yml

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

ما سنفعله الآن بالملف .travis.yml هو ما يلي:

1. أضف stages مختلفًا
2. كل stage يعتمد على الفرع
3. إذا كان الإصدار الخاص بك هو الإصدار الرئيسي، فهذا يعني أنه يجب تحديث الحزمة، لذلك سنقوم بدفع الحزمة الخاصة بنا إلى خلاصات NuGet
4. إذا كان البناء عبارة عن طلب سحب، فمازلنا سنتحقق مما إذا كان البناء قد تم تجميعه واختباره، ولكننا لن ننشره.

المراحل

من وثائقهم:

يمكنك تصفية ورفض الإصدارات والمراحل والوظائف عن طريق تحديد الشروط في تكوين الإصدار الخاص بك (ملف .travis.yml الخاص بك).

يمكنك العثور على مزيد من المعلومات بخصوص TravisCI stages في صفحة الوثائق الخاصة بهم.

لذلك سنقوم بتغيير الملف وإضافة المراحل التي تنتهي بهذا الشكل:

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

كما ترون لدينا ثلاث مراحل مختلفة compile، test و push، والتي سيتم تشغيل المرحلة الأخيرة فقط عندما يكون branch هو master وليس pull request لها، فقط push.

إذا لم تفهم هذا الأمر، فما عليك سوى الانتقال إلى الوثائق وسيتم شرحه بسهولة تامة.

مع أخذ ذلك في الاعتبار، لن يقوم كل pull request بدفع أي شيء إلى موجز NuGet.

تعيين مفتاح API كمتغير بيئة

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

إنشاء pull request

الآن بعد أن تم إعداد كل شيء، حان الوقت لإجراء pull request والتحقق مما إذا كان التجميع لطلب السحب هذا يتجاهل آخر stage.

التحقق من البنيات

بمجرد قيامك بتقديم طلب السحب، سيتم وضع البنية في قائمة الانتظار في لوحة معلومات TravisCI، وكما ترى أن لدينا نسختين مختلفتين هناك وليس ثلاثة.

الآن دعونا نقبل pull request ونتحقق من البناء مرة أخرى لنرى أن لدينا الآن ثلاث وظائف بدلاً من اثنتين.

وبمجرد أن ترى البناء في قائمة الانتظار، يمكنك رؤية المهام الثلاث بما في ذلك Deploy-prod في النهاية.

بمجرد اكتمال هذا البناء بالكامل، يمكنك أن ترى في السجلات أنه تم دفع الحزمة إلى المصادر.

ومن الواضح أنه يمكنك رؤيته في صفحة NuGet

هذا كل شيء

اكتشفنا في هذا البرنامج التعليمي كيفية أتمتة تسليم حزم NuGet الخاصة بنا. استخدمنا بعض الأدوات مثل TravisCI، stages و dotnet nuget.

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

يمكنك العثور على الكود المصدري، مع ملف .travis.yml مباشرة هنا، إذا كانت لديك أي أسئلة فلا تتردد في الاتصال بي على twitter!