السابق

التالي

تمرين - الترقية إلى مرحلة الاختبار

مكتمل

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

تذكر أن الفريق قرر استخدام مشغّل مجدول لترقية الإصدار من مرحلة التطوير إلى مرحلة الاختبار الساعة 3 صباحاً يومياً. لإعداد المشغل المجدول:

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

لأغراض التعلم، هنا، يمكنك تحديد الجدول الزمني ولكن السماح للبناء بالانتقال مباشرة من Dev إلى Test. يتجنب هذا الإعداد الحاجة إلى الانتظار حتى يتم تشغيل الجدول الزمني. بعد إكمال هذه الوحدة، حاول تجربة تعبيرات «cron» مختلفة لتشغيل مرحلة الاختبار فقط في الوقت المجدول.

ترقية التغييرات إلى مرحلة الاختبار

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

1. قم بتعديل azure-pipelines.ymlفي تعليمة Visual Studio البرمجية، كما يلي:

   trigger:
   - '*'
   
   variables:
     buildConfiguration: 'Release'
     releaseBranchName: 'release'
   
   schedules:
   - cron: '0 3 * * *'
     displayName: 'Deploy every day at 3 A.M.'
     branches:
       include:
       - release
     always: false 
   
   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'
   
   - stage: 'Test'
     displayName: 'Deploy to the test environment'
     dependsOn: Dev
     #condition: eq(variables['Build.Reason'], 'Schedule')
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: test
       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: '$(WebAppNameTest)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   

   schedules يعرف القسم تعبير cron واحدا. يمكنك تعريف أكثر من تعبير واحد في التكوين الخاص بك. يُشغل التعبير البنية الأساسية لبرنامج ربط العمليات التجارية لتشغيل الإصدار الفرعي في الساعة 3 صباحاً يومياً. always يتم تعيين العلامة إلى false بحيث يتم تشغيل المسار فقط عندما يحتوي فرع الإصدار على تغييرات من التشغيل السابق.

   Test تحدد المرحلة شرطا يقوم بتشغيل المرحلة فقط عندما يساوي Scheduleسبب الإنشاء . (يحدد المتغير Build.Reason المضمن سبب الإنشاء.) إذا كان هذا الشرط خاطئا، يتم تخطي المرحلة، ولكن تستمر المراحل السابقة في التشغيل.

   إشعار

   يتم عرض هذا الشرط لأغراض التعلم. تم التعليق عليه لتمكين التغيير من الانتقال من Dev إلى Test دون انتظار تشغيل الجدول الزمني.

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

   تلميح

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

   git add azure-pipelines.yml
   git commit -m "Deploy to the Test 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 محفوظات النشر الخاصة بك. في المحفوظات، يمكنك تتبع التغييرات في البيئة مرة أخرى إلى عمليات تثبيت التعليمات البرمجية وعناصر العمل.

   

يضيف أندي ومارا مرحلة الاختبار إلى البنية الأساسية لبرنامج ربط العمليات التجارية. يعرضون النتائج على أميتا.

أميتا: أحب أن يتم بناء التغييرات ونشرها حتى أتمكن من اختبارها كل صباح. ولكن لا أرى كيف يمكنني التحكم عند وصول التغييرات إلى التقسيم المرحلي.

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

متابعة