Latihan - Mempromosikan ke tahap Pengembangan

8 menit

Tim memiliki rencana dan siap untuk mulai mengimplementasikan alur rilis mereka. Proyek Azure DevOps Anda 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 build. Tahap kedua menyebarkan aplikasi web Space Game untuk App Service. Di sini, Anda mengikuti Andy dan Mara saat mereka memodifikasi alur. Mereka akan menyebarkan ke lingkungan App Service yang sesuai dengan tahap Dev .

Tahap Dev menyerupai tahap penyebaran yang Anda buat 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 cabang dari GitHub

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

Cabang ini berfungsi sebagai 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. Segera, Anda akan mendorong 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 ini mirip dengan 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.

Catatan

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 pada cabang mana pun. Anda mungkin juga menyebarkan aplikasi ke lingkungan yang melakukan pengujian yang lebih lengkap. Namun, Anda melakukan penyebaran ini hanya ketika Anda memiliki permintaan pull, ketika Anda memiliki kandidat rilis, atau ketika Anda menggabungkan kode ke utama.

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

Mempromosikan perubahan ke tahap Dev

Di sini, Anda mengubah konfigurasi alur untuk menyebarkan 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 mendefinisikan variabel pada bagian atas file. Variabel digunakan di seluruh alur. Variabel mendefinisikan konfigurasi mana yang akan dibangun (Release). Variabel juga menentukan nama cabang rilis Anda (release).
Tahap Deploy dari bukti konsep sekarang bernama Dev.
Tahap Dev menggunakan kondisi yang mengarahkan sistem untuk menjalankan tahap hanya saat tahap sebelumnya berhasil dan cabang saat ini adalah release. Penyiapan ini memastikan bahwa fitur rilis hanya disebarkan ke lingkungan Dev.
Langkah penyebaran menggunakan WebAppNameDev variabel untuk disebarkan ke instans App Service yang terkait dengan lingkungan Dev .

Catatan

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

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

Tip

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
```
Di Azure Pipelines, buka build. Saat berjalan, lacak build-nya.
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-nya, temukan di portal 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 - Mempromosikan ke tahap Pengembangan

Ambil cabang dari GitHub

Mempromosikan perubahan ke tahap Dev

Saran dan Komentar