Упражнение. Повышение уровня разработки

8 мин

Команда имеет план и готов начать реализацию конвейера выпуска. Проект Azure DevOps настроен, и экземпляры Службы приложений Azure готовы к получению артефактов сборки.

На этом этапе помните, что конвейер команды имеет только два этапа. На первом этапе создается артефакт сборки. Второй этап развертывает веб-приложение Space Game в службе App Service. Здесь вы следите за Энди и Марой, когда они изменяют конвейер. Они будут развертываться в среде службы приложений, соответствующей этапу dev.

Этап разработки напоминает этап развертывания, сделанный в модуле Создание конвейера выпуска в модуле Azure Pipelines. Там вы использовали триггер CI для запуска процесса сборки. Здесь вы делаете то же самое.

Получить ветку из GitHub

Здесь вы получите ветвь release из GitHub. Вы также можете выбрать или переключиться на ветвь.

Эта ветвь служит вашей ветвью выпуска . Он содержит проект Space Game, используемый в предыдущих модулях. Она также содержит конфигурацию Azure Pipelines для начальной настройки.

Чтобы получить и переключиться на ветвь, выполните следующие действия:

В Visual Studio Code откройте интегрированный терминал.
Чтобы получить ветвь с именем release из репозитория Майкрософт и переключиться в нее, выполните следующие команды git.
```
git fetch upstream release
git checkout -B release upstream/release
```
Формат этих команд позволяет получить начальный код из репозитория Microsoft GitHub, известного как upstream. Вскоре вы собираетесь отправить эту ветвь в репозиторий GitHub, известный как origin.
Как дополнительный шаг, в Visual Studio Code откройте azure-pipelines.yml. Ознакомьтесь с начальной конфигурацией.

Конфигурация похожа на базовую, которую вы создали в модуле Создание конвейера выпуска с помощью Azure Pipelines. Он создает только релизную конфигурацию приложения. В целях обучения эта конфигурация не выполняет проверки качества или безопасности, настроенные в предыдущих модулях.

Заметка

Более надежная конфигурация может указывать ветви, участвующие в процессе сборки. Например, чтобы помочь проверить качество кода, можно запускать модульные тесты каждый раз при отправке изменений в любой ветви. Вы также можете развернуть приложение в среде, которая выполняет более исчерпывающее тестирование. Но это развертывание выполняется только в том случае, если у вас есть pull-запрос, если у вас есть кандидат на релиз или при слиянии кода с основной веткой.

Дополнительные сведения см. в статье Реализация рабочего процесса кода в конвейере сборки с помощью Git и GitHub, и Триггеры конвейера сборки.

Перевести изменения на этап разработки

Здесь вы редактируете конфигурацию вашего конвейера, чтобы повысить сборку до этапа разработки Dev.

В 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.
На этапе Dev используется условие, которое направляет систему на запуск этапа только в том случае, если предыдущая стадия успешно выполнена, и текущая ветвь соответствует release. Эта настройка гарантирует, что релизные функции развертываются только в среде Dev.
Шаг развертывания использует переменную WebAppNameDev для развертывания в экземпляре Службы приложений, связанном с средой dev.

Заметка

На практике можно выполнить развертывание из другой ветки, такой как main. Можно включить логику, которая позволяет продвижение изменений на этап Dev из нескольких ветвей, таких как release и main.

В интегрированном терминале добавьте 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
```
В Azure Pipelines перейдите к сборке. Во время выполнения сборки выполняйте её трассировку.
После завершения сборки, чтобы вернуться на страницу сводки, нажмите кнопку "Назад".

Вы видите, что развертывание успешно завершено.
Откройте браузер и перейдите к URL-адресу, связанному с экземпляром службы приложений для среды Dev.

Если у вас по-прежнему открыта вкладка браузера, обновите страницу. Если вы не помните URL-адрес, найдите его на портале Azure, на странице сведения о службе приложений.

Вы видите, что веб-сайт Space Game развернут в App Service и работает.
В качестве дополнительного шага в Azure Pipelines выберите среды. Затем выберите среду разработки.

Azure Pipelines записывает историю развертывания. В истории можно отслеживать изменения в среде до коммитов кода и рабочих элементов.

Упражнение. Повышение уровня разработки

Получить ветку из GitHub

Перевести изменения на этап разработки

Обратная связь