Задание - Перевести на этап тестирования
Конвейер выпуска по-прежнему имеет два этапа, но теперь они отличаются от ранее. Этапы сборки и разработки. Каждое изменение, которое вы отправляете в GitHub, активирует этап сборки . Этап разработки выполняется только в том случае, если изменение находится в выпускной ветке . Здесь вы добавляете этап теста в конвейер.
Напомним, что команда решила использовать запланированный триггер для продвижения сборки с этапа разработки до этапа тестирования в 3 часа утра. Чтобы настроить запланированный триггер, выполните следующие действия.
- Определите расписание в конфигурации сборки.
- Определите этап теста, который включает условие, которое запускает этап, только если причина сборки помечена как
Schedule
.
В учебных целях вы определяете расписание, но позволяете сборке переходить непосредственно из Dev на Test. Эта настройка позволяет избежать необходимости ждать активации расписания. После завершения этого модуля попробуйте поэкспериментировать с различными выражениями cron, чтобы запустить этап тестирования только в запланированное время.
Продвижение изменений на этап тестирования
Здесь вы измените конфигурацию конвейера, чтобы развернуть сборку на этапе тестирования .
В Visual Studio Code измените azure-pipelines.yml следующим образом:
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 без ожидания запуска расписания.
В интегрированном терминале добавьте в индекс 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
В Azure Pipelines перейдите к сборке. Отслеживайте сборку, пока она выполняется.
После завершения сборки, чтобы вернуться на страницу сводки, нажмите кнопку "Назад".
Вы видите, что развертывание успешно завершено.
В веб-браузере перейдите по URL-адресу, связанному с экземпляром службы приложений для тестовой среды .
Если у вас по-прежнему открыта вкладка браузера, обновите страницу. Если вы не помните URL-адрес, найдите его на портале Azure, на странице сведения о службе приложений.
Вы видите, что веб-сайт Space Game развернут в службе приложений и работает.
В качестве дополнительного шага в Azure Pipelines выберите среды. Затем выберите тестовую среду .
Azure Pipelines ведет историю развертываний. В истории можно отслеживать изменения в среде до фиксаций кода и рабочих элементов.
Энди и Мара добавляют этап Test в конвейер. Они показывают результаты Амите.
Амита: мне нравится, что изменения создаются и развертываются, чтобы я смог протестировать их каждое утро. Но я не вижу, как я могу контролировать, когда изменения приходят в промежуточный сервер .
Мара: Да, развертывание с помощью автоматизации экономит много времени. Помните, что мы включили только запланированный триггер. Давайте добавим процесс утверждения выпуска при настройке Staging среды для Тима. Таким образом, изменения переключаются на промежуточный только когда вы готовы.