السابق

التالي

تمرين - إنشاء طلب سحب

مكتمل

ستتدرب في هذه الوحدة على عملية إرسال طلب سحب ودمج التغييرات في الفرع main حتى يستفيد الجميع من عملك.

في Create a build pipeline with Azure Pipelines، قمت بإنشاء فرع Git يسمى build-pipeline، حيث قمت بتعريف البنية الأساسية لبرنامج ربط العمليات التجارية للبناء بشكل أساسي لموقع ويب Space Game. تذكر أن تعريف البناء يتوفر في ملف يسمى azure-pipelines.yml.

على الرغم من أن فرعك ينتج أداة بناء، إلا أن هذا العمل موجود فقط على build-pipeline الفرع. تحتاج إلى دمج الفرع خاصتك بالفرع main.

تذكر أن طلب السحب يخبر المطورين الآخرين أن لديك تعليمات برمجية جاهزة للمراجعة، إذا لزم الأمر، وتريد دمج التغييرات في فرع آخر مثل الفرع main.

قبل أن نبدأ، دعونا نتحقق مع مارا وأندي.

أندي: مرحبا، مارا. أعرف أن لديك مسار بناء يعمل على Azure. أقوم بإضافة ميزة إلى موقع الويب وأريد أن أرى عملية البناء لنفسي. هل نحن مستعدون للقيام بذلك؟

مارا: بالتأكيد. لقد أنشأت البنية الأساسية لبرنامج ربط العمليات التجارية على فرع. لماذا لا نُنشئ طلب سحب وندمجه في main حتى نتمكن من استخدام البنية الأساسية لبرنامج ربط العمليات التجارية أيضًا؟

أندي: يبدو رائعا. دعونا نلقي نظرة.

إنشاء فرع وإضافة رمز البدء

على الرغم من أنه يمكنك استخدام البنية الأساسية لبرنامج ربط العمليات التجارية للبنية التي أنشأتها في الوحدة النمطية السابقة، لننشئ فرعًا جديدًا يسمى code-workflow. يستند هذا الفرع إلى main، بحيث يمكنك ممارسة العملية من البداية.

1. في Visual Studio Code، افتح المحطة الطرفية المتكاملة.

2. التبديل إلى main الفرع:

   git checkout main
   

3. تأكد من أن لديك أحدث إصدار من التعليمات البرمجية من GitHub:

   git pull origin main
   

4. إنشاء فرع باسم code-workflow:

   git checkout -B code-workflow
   

   -b تحدد الوسيطة إنشاء فرع جديد إذا لم يكن موجودا. احذف الوسيطة -b عندما تريد التبديل إلى فرع موجود.

   بشكل افتراضي، يعتمد فرعك الجديد على الفرع السابق من حيث قمت بتشغيل git checkout الأمر. هنا، الفرع الأصل هو main، ولكن يمكن أن يكون الفرع الأصل فرعا آخر، مثل فرع ميزة بدأه شخص آخر تريد البناء عليه أو تجربته.

   من الآمن الآن إجراء أي تغييرات تحتاج إليها، لأنك في فرعك المحلي. إذا كنت تريد معرفة الفرع الذي تعمل عليه، فقم بتشغيل git branch -v.

5. من مستكشف الملفات، افتح azure-pipelines.yml واستبدل محتوياته بهذا:

   trigger:
   - '*'
   
   pool:
     vmImage: 'ubuntu-20.04'
     demands:
     - npm
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - $(buildConfiguration)'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration $(buildConfiguration)'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - $(buildConfiguration)'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
       zipAfterPublish: true
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

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

دفع فرعك إلى GitHub

هنا، ستدفع فرعك code-workflow إلى GitHub وتشاهد Azure Pipelines تبني التطبيق.

1. في المحطة الطرفية، قم بتشغيل git status لمعرفة ما هو العمل غير الملتزم به الموجود على الفرع الخاص بك:

   git status
   

   سترى أنه أُدخلت تعديلات على azure-pipelines.yml. ستثبّت ذلك بفرعك قريبًا، ولكن عليك أولاً التأكد من أن Git يتتبع هذا الملف المُسمى staging.

   يتم تنفيذ التغييرات المرحلية فقط عند تشغيل git commit. بعد ذلك، يمكنك تشغيل الأمر git add لإضافة azure-pipelines.yml إلى منطقة العرض أو الفهرس.

2. قم بتشغيل الأمر git add التالي لإضافة azure-piplines.yml إلى منطقة التشغيل المرحلي:

   git add azure-pipelines.yml
   

3. شغّل الأمر التالي git commit لتثبيت الملف المرحلي بالفرع code-workflow:

   git commit -m "Add the build configuration"
   

   -m تحدد الوسيطة رسالة التثبيت. تصبح رسالة التثبيت جزءا من محفوظات ملف تم تغييره. تساعد المراجعين على فهم التغيير، وتساعد المشرفين في المستقبل على فهم كيفية تغيير الملف بمرور الوقت.

   تلميح

   أكملت أفضل رسائل التثبيت الجملة ، "إذا قمت بتطبيق هذا التثبيت، فستتم ..."

   إذا حذفت الوسيطة -m ، فإن Git يجلب محرر نص حيث يمكنك تفصيل التغيير. يكون هذا الخيار مفيدا عندما تريد تحديد رسالة تثبيت تمتد عبر أسطر متعددة. يحدد النص حتى السطر الفارغ الأول عنوان التثبيت.

4. شغّل الأمر git push هذا لدفع الفرع code-workflow أو تحميله إلى مستودعك على GitHub:

   git push origin code-workflow
   

5. كخطوة اختيارية، انتقل إلى مشروعك في Azure Pipelines وتتبع البنية أثناء تشغيله.

   يسمى هذا الإصدار بناء CI. يستخدم تكوين البنية الأساسية لبرنامج ربط العمليات التجارية ما يسمى المشغل للتحكم في الفروع التي تشارك في عملية الإنشاء. هنا، يحدد "*" جميع الفروع.

   trigger:
   - '*'
   

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

   سترى نجاح اكتمال البنية ونتج عنصرًا يحتوي على تطبيق الويب المدمج.

إنشاء طلب سحب

ستُنشئ هنا طلب سحب للفرع:

1. في المتصفح، سجل الدخول إلى GitHub.

2. انتقل إلى مستودع mslearn-tailspin-spacegame-web الخاص بك.

3. في القائمة المنسدلة Branch حدد فرع code-workflow لديك.

   

4. لبدء طلب السحب، حدد Contribute ثم Open pull request.

   

5. تأكد من أن القاعدة تحدد المستودع المتشعب وليس مستودع Microsoft.

   يبدو التحديد الخاص بك كما يلي:

   

   هام

   هذه الخطوة مهمة لأنه لا يمكنك دمج تغييراتك في مستودع Microsoft. تأكد من أن المستودع الأساسي يشير إلى حسابك على GitHub وليس MicrosoftDocs.

   إذا انتهى بك الأمر بطلب سحب مقابل MicrosoftDocs، فما عليك سوى إغلاق طلب السحب وتكرار هذه الخطوات.

   تتضمن هذه العملية خطوة إضافية لأنك تعمل من مستودع متشعب. عند العمل مباشرة مع المستودع الخاص بك، وليس نسخة المستودع، يتم تحديد فرعك main بشكل افتراضي.

6. أدخل عنوانا ووصفا لطلب السحب.

   • العنوان:

     تكوين Azure Pipelines

   • الوصف:

     ينشئ تكوين البنية الأساسية لبرنامج ربط العمليات التجارية هذا التطبيق وينتج بنية لتكوين الإصدار.

7. لإكمال طلب السحب، حدد إنشاء طلب سحب.

   لا تدمج هذه الخطوة أي تعليمة برمجية. يخبر الآخرين بأنك قد اقترحت تغييرات لتُمج في الفرع main.

   

   يتم عرض نافذة طلب السحب. يمكنك أن ترى أن حالة الإنشاء في Azure Pipelines تم تكوينها لتظهر كجزء من طلب السحب. وبهذه الطريقة، يمكنك أنت والآخرين عرض حالة البنية أثناء تشغيلها.

   

   تماما كما هو الحال عند دفع فرع إلى GitHub، يؤدي طلب السحب، بشكل افتراضي، إلى تشغيل Microsoft Azure Pipelines لإنشاء التطبيق الخاص بك.

   تلميح

   إذا لم تظهر حالة الإنشاء على الفور، فانتظر بضع لحظات أو قم بتحديث الصفحة.

8. اختياريا، حدد ارتباط Details ، ثم تتبع البنية أثناء انتقالها عبر المسار.

   يمكنك تسليم الإصدار الخاص بك إلى الخطوة التالية في العملية، مثل سؤالجواب. في وقت لاحق، يمكنك تكوين البنية الأساسية لبرنامج ربط العمليات التجارية لدفع التغيير الخاص بك إلى معمل QA أو الإنتاج.

9. ارجع إلى طلب السحب الخاص بك على GitHub.

   انتظر حتى يكتمل البناء. أنت الآن جاهز لدمج طلب السحب الخاص بك.

   

10. حدد Merge pull request، ثم حدد Confirm merge.

11. لحذف الفرع code-workflow من GitHub، حدد Delete branch.

    

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

    من المفترض أن تكون فروع Git قصيرة الأجل. بعد دمج فرع، لا تدفع تثبيتات إضافية إليه أو تدمجه مرة ثانية. في معظم الحالات، في كل مرة تبدأ فيها بميزة جديدة أو إصلاح الأخطاء، تبدأ بفرع نظيف يستند إلى main الفرع.

    لا يؤدي حذف فرع على GitHub إلى حذف هذا الفرع من النظام المحلي. للقيام بذلك، يمكنك تمرير -d التبديل إلى git branch الأمر .

كم مرة تم بناء تغيير؟

تعتمد الإجابة على كيفية تعريف تكوين البناء الخاص بك. تمكنك Azure Pipelines من تحديد المشغلات التي تحدد الأحداث التي تتسبب في حدوث البنيات. يمكنك التحكم في الفروع التي يتم إنشاؤها أو حتى الملفات التي تشغل البنية.

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

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

بشكل افتراضي، يتم تشغيل بناء عند دفع تغيير إلى أي ملف على أي فرع.

بناء التكامل المستمر (CI) هو بناء يتم تشغيله عند دفع تغيير إلى فرع.

بناء طلب السحب (PR) هو بناء يتم تشغيله عند فتح طلب سحب أو عند دفع تغييرات إضافية إلى طلب سحب موجود.

يتم إنشاء التغييرات التي تجريها من code-workflow خلال الفرع ضمن ثلاثة شروط:

• يحدث بناء CI عند دفع التغييرات إلى code-workflow الفرع.
• يحدث بناء PR عند فتح طلب سحب على code-workflow الفرع مقابل main الفرع.
• يحدث بناء CI النهائي بعد دمج طلب السحب في الفرع main.

يساعدك بناء PR على التحقق من أن التغييرات المقترحة ستعمل بشكل صحيح بعد دمجها في فرع main آخر مستهدف.

يتحقق بناء CI النهائي من أن التغييرات لا تزال جيدة بعد دمج PR.

كخطوة اختيارية، انتقل إلى Azure Pipelines وشاهد إنشاء CI النهائي يحدث على main الفرع.

متابعة