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

مكتمل

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

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

تشبه مرحلة التطوير مرحلة النشر التي أجريتها في الوحدة النمطية إنشاء مسار إصدار في 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 و Build pipeline.

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

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

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).
   • مرحلة التوزيع من إثبات المفهوم تسمى الآن Dev.
   • تستخدم مرحلة التطوير شرطاً يوجه النظام لتشغيل المرحلة فقط عند نجاح المرحلة السابقة واستخدام الإصدار الفرعي الحالي release. يضمن هذا الإعداد نشر ميزات الإصدار فقط في بيئة التطوير .
   • تستخدم WebAppNameDev خطوة التوزيع المتغير للنشر إلى مثيل App Service المقترن ببيئة التطوير .

   إشعار

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

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 لبيئة التطوير الخاصة بك.

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

   ترى أن موقع Space Game على الويب تم نشره في App Service، وأنه قيد التشغيل.

   

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

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