تمرين - الترقية إلى مرحلة التطوير

مكتمل

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

في هذه المرحلة، تذكر أن البنية الأساسية لبرنامج ربط العمليات التجارية للفريق لديها مرحلتين فقط. تنتج المرحلة الأولى البيانات الاصطناعية للبناء. المرحلة الثانية تنشر Space Game تطبيق الويب إلى App Service. هنا، يمكنك المتابعة مع أندي ومارا أثناء تعديلهما للبنية الأساسية لبرنامج ربط العمليات التجارية. سينشرون في بيئة App Service التي تتوافق مع مرحلة Dev.

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

إحضار الفرع من GitHub

هنا، يمكنك إحضار فرع release من GitHub. يمكنك أيضا سحب الفرع أو التبديل إليه.

يعمل هذا الفرع كفرع إصدار. يحتوي على مشروع Space Game المستخدم في الوحدات النمطية السابقة. كما يحتوي على تكوين Azure Pipelines للبدء به.

لجلب الفرع والتبديل إليه:

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

2. لإحضار فرع يسمى release من مستودع Microsoft، وللتبديل إلى هذا الفرع، قم بتشغيل أوامر git التالية.

   git fetch upstream release
   git checkout -B release upstream/release
   

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

3. كخطوة اختيارية، من Visual Studio Code، افتح azure-pipelines.yml. تعرف على التكوين الأولي.

   يشبه التكوين الأساسي الذي قمت بإنشائه في الوحدة النمطية Create a release pipeline with Azure Pipelines. يقوم بإنشاء تكوين إصدار التطبيق فقط. لأغراض التعلم، لا يقوم هذا التكوين بتشغيل اختبارات الجودة أو الأمان التي قمت بإعدادها في الوحدات النمطية السابقة.

   ملاحظه

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

   لمزيد من المعلومات، راجع تنفيذ سير عمل التعليمات البرمجية في البنية الأساسية لبرنامج ربط العمليات التجارية للبناء باستخدام Git وGitHub ومشغلات البنية الأساسية لبرنامج ربط العمليات التجارية .

ترقية التغييرات إلى مرحلة التطوير

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

1. في Visual Studio Code، قم بتعديل azure-pipelines.yml.

   trigger:
   - '*'
   
   variables:
     buildConfiguration: 'Release'
     releaseBranchName: 'release'
   
   stages:
   - stage: 'Build'
     displayName: 'Build the web application'
     jobs: 
     - job: 'Build'
       displayName: 'Build job'
       pool:
         vmImage: 'ubuntu-20.04'
         demands:
         - npm
   
       variables:
         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
   
       - publish: '$(Build.ArtifactStagingDirectory)'
         artifact: drop
   
   - stage: 'Dev'
     displayName: 'Deploy to the dev environment'
     dependsOn: Build
     condition: |
       and
       (
         succeeded(),
         eq(variables['Build.SourceBranchName'], variables['releaseBranchName'])
       )
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: dev
       variables:
       - group: Release
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameDev)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   

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

   • يعرف هذا التكوين المتغيرات في بداية الملف. يتم استخدام المتغيرات في جميع أنحاء البنية الأساسية لبرنامج ربط العمليات التجارية. وهي تحدد التكوين الذي يجب إنشائه (Release). كما أنها تحدد اسم فرع الإصدار الخاص بك (release).
   • تسمى مرحلة Deploy من إثبات المفهوم الآن Dev.
   • تستخدم مرحلة Dev شرطا يوجه النظام لتشغيل المرحلة فقط عند نجاح المرحلة السابقة ويتم releaseالفرع الحالي. يضمن هذا الإعداد نشر ميزات الإصدار فقط في بيئة Dev.
   • تستخدم خطوة التوزيع متغير WebAppNameDev للتوزيع إلى مثيل App Service المقترن ببيئة Dev.

   ملاحظه

   في الممارسة العملية، يمكنك النشر من فرع آخر، مثل main. يمكنك تضمين المنطق الذي يسمح بترقية التغييرات إلى مرحلة Dev من فروع متعددة، مثل releasemain.

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

   بقشيش

   قبل تشغيل أوامر Git هذه، احفظ azure-pipelines.yml.

   git add azure-pipelines.yml
   git commit -m "Deploy to the Dev stage"
   git push origin release
   

3. في Azure Pipelines، انتقل إلى البنية. أثناء تشغيله، تتبع البنية.

4. بعد انتهاء البناء، للعودة إلى صفحة الملخص، حدد الزر رجوع.

   

   ترى أن النشر قد انتهى بنجاح.

5. من مستعرض ويب، انتقل إلى عنوان URL المقترن بمثيل App Service لبيئة Dev.

   إذا كان لا يزال لديك علامة تبويب المستعرض مفتوحة، فقم بتحديث الصفحة. إذا لم تتذكر عنوان URL، فابحث عنه في مدخل Microsoft Azure، في صفحة App Service details.

   ترى أن موقع لعبة الفضاء يتم نشره إلى App Service، وأنه قيد التشغيل.

   

6. كخطوة اختيارية، في Azure Pipelines، حدد Environments. ثم حدد بيئة dev.

   يسجل Azure Pipelines محفوظات النشر الخاصة بك. في المحفوظات، يمكنك تتبع تغييرات البيئة مرة أخرى إلى عمليات تثبيت التعليمات البرمجية وعناصر العمل.