Latihan - Promosikan ke tahap Pengembangan

8 menit

Tim memiliki rencana dan siap untuk mulai menerapkan alur rilis mereka. Proyek Azure DevOps Anda telah disiapkan, dan instans Azure App Service Anda siap menerima artefak build.

Pada titik ini, ingatlah bahwa alur tim hanya memiliki dua tahap. Tahap pertama menghasilkan artefak pengembangan. Tahap kedua menyebarkan aplikasi web Space Game ke App Service. Di sini, Anda mengikuti Andy dan Mara saat mereka memodifikasi alur. Mereka akan menerapkan ke lingkungan App Service yang sesuai dengan tahap pengembangan Dev.

Tahap Dev menyerupai tahap penyebaran yang Anda buat di dalam modul Membuat alur rilis di Azure Pipelines. Di sana, Anda menggunakan pemicu CI untuk memulai proses build. Di sini Anda melakukan hal yang sama.

Ambil branch dari GitHub

Di sini, Anda mengambil cabang release dari GitHub. Anda juga memeriksa, atau beralih ke cabang.

Cabang ini merupakan cabang rilis Anda. Ini berisi proyek Space Game yang digunakan dalam modul sebelumnya. Ini juga berisi konfigurasi Azure Pipelines untuk memulai.

Untuk mengambil dan beralih ke cabang:

Di Visual Studio Code, buka terminal terintegrasi.
Untuk mengambil cabang bernama release dari repositori Microsoft, dan untuk beralih ke cabang tersebut, jalankan perintah git berikut.
```
git fetch upstream release
git checkout -B release upstream/release
```
Format perintah ini memungkinkan Anda mendapatkan kode pemula dari repositori Microsoft GitHub, yang dikenal sebagai upstream. Sebentar lagi, Anda akan mem-push cabang ini ke repositori GitHub Anda, yang dikenal sebagai origin.
Sebagai langkah opsional, dari Visual Studio Code, buka azure-pipelines.yml. Biasakan diri Anda dengan konfigurasi awal.

Konfigurasi menyerupai konfigurasi dasar yang Anda buat di modul Membuat alur rilis dengan Azure Pipelines. Ini hanya membangun konfigurasi rilis aplikasi. Untuk tujuan pembelajaran, konfigurasi ini tidak menjalankan pemeriksaan kualitas atau keamanan yang Anda siapkan di modul sebelumnya.

Nota

Konfigurasi yang lebih kuat mungkin menentukan cabang yang berpartisipasi dalam proses build. Misalnya, untuk membantu memverifikasi kualitas kode, Anda dapat menjalankan pengujian unit setiap kali Anda mendorong perubahan di cabang mana pun. Anda juga dapat menyebarkan aplikasi ke lingkungan yang melakukan pengujian yang lebih lengkap. Tetapi Anda melakukan penyebaran ini hanya ketika Anda memiliki permintaan pull, ketika Anda memiliki kandidat rilis, atau ketika Anda menggabungkan kode untuk utama .

Untuk informasi selengkapnya, lihat Menerapkan alur kerja kode di alur build Anda dengan menggunakan git dan GitHub dan pemicu alur build .

Memindahkan perubahan ke tahap Dev

Di sini, Anda memodifikasi konfigurasi alur untuk mempromosikan build ke tahap Dev.

Di Visual Studio Code, ubah 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'

Konfigurasi ini menyerupai dengan yang Anda buat di modul sebelumnya. Di sana, Anda dan tim membangun bukti konsep untuk penyebaran berkelanjutan. Tetapi perhatikan perbedaan ini, yang disorot dalam contoh kode sebelumnya:

Konfigurasi ini menentukan variabel di awal file. Variabel-variabel digunakan di seluruh alur proses. Mereka menentukan konfigurasi mana yang akan dibangun (Release). Mereka juga menentukan nama cabang rilis Anda (release).
Tahap Deploy dari tahap bukti konsep kini dinamai Dev.
Tahap Dev menggunakan kondisi yang mengarahkan sistem untuk menjalankan tahap hanya ketika tahap sebelumnya berhasil dan cabang saat ini adalah release. Penyiapan ini memastikan bahwa fitur rilis hanya disebarkan ke lingkungan Dev.
Langkah penyebaran menggunakan variabel WebAppNameDev untuk disebarluaskan ke instans App Service yang terkait dengan lingkungan Dev.

Nota

Dalam praktiknya, Anda dapat menyebarkan dari beberapa cabang lain, seperti main. Anda dapat menyertakan logika yang memungkinkan perubahan dipromosikan ke tahap Dev dari beberapa cabang, misalnya release dan main.

Dari terminal terintegrasi, tambahkan azure-pipelines.yml ke indeks. Terapkan perubahan, dan dorong ke GitHub.

Ujung

Sebelum Anda menjalankan perintah Git ini, simpan azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
Pergi ke Azure Pipelines, lalu buka build. Saat berjalan, lacak proses pembangunan.
Setelah build selesai, untuk kembali ke halaman ringkasan, pilih tombol kembali.

Anda melihat bahwa penyebaran berhasil diselesaikan.
Dari browser web, buka URL yang terkait dengan instans App Service untuk lingkungan Dev Anda.

Jika Anda masih membuka tab browser, refresh halaman. Jika Anda tidak ingat URL, temukan di portal Microsoft Azure, di halaman detail App Service.

Anda melihat bahwa situs web Space Game disebarkan ke App Service, dan sedang berjalan.
Sebagai langkah opsional, di Azure Pipelines, pilih lingkungan . Kemudian, pilih lingkungan dev.

Azure Pipelines merekam riwayat penyebaran Anda. Dalam riwayat, Anda dapat melacak perubahan lingkungan kembali ke penerapan kode dan item kerja.

Latihan - Promosikan ke tahap Pengembangan

Ambil branch dari GitHub

Memindahkan perubahan ke tahap Dev

Saran dan Komentar