Jenis tugas penggunaan

  • Artikel
  • 11 menit untuk membaca

| Layanan Azure DevOps Azure DevOps Server 2020 | | Azure DevOps Server 2019 TFS 2018

Catatan

Di Microsoft Team Foundation Server (TFS) 2018 dan versi sebelumnya, alur build dan rilis disebut definisi, eksekusi disebut build, koneksi layanan disebut titik akhir layanan, tahapan disebut lingkungan, dan pekerjaan disebut fase.

Tugas adalah blok penyusun untuk menentukan otomatisasi dalam alur. Tugas hanyalah skrip atau prosedur kemasan yang telah diabstraksi dengan serangkaian input.

Saat Anda menambahkan tugas ke alur Anda, tugas juga dapat menambahkan sekumpulan permintaan ke alur. Tuntutan menentukan prasyarat yang harus diinstal pada agen agar tugas berjalan. Saat Anda menjalankan build atau penyebaran, agen yang memenuhi tuntutan ini akan dipilih.

Saat Anda menjalankan pekerjaan, semua tugas dijalankan secara berurutan, satu demi satu. Untuk menjalankan kumpulan tugas yang sama secara paralel pada beberapa agen, atau untuk menjalankan beberapa tugas tanpa menggunakan agen, lihat pekerjaan.

Secara default, semua tugas berjalan dalam konteks yang sama, baik itu di host atau dalam kontainer pekerjaan. Anda dapat secara opsional menggunakan target langkah untuk mengontrol konteks untuk tugas individual.

Pelajari selengkapnya tentang cara menentukan properti untuk tugas dengan tugas bawaan.

Saat Anda menjalankan pekerjaan, semua tugas dijalankan secara berurutan, satu demi satu, pada agen. Untuk menjalankan kumpulan tugas yang sama secara paralel pada beberapa agen, atau untuk menjalankan beberapa tugas tanpa menggunakan agen, lihat pekerjaan.

Tugas kustom

Kami menyediakan beberapa tugas bawaan untuk mengaktifkan skenario build dan penyebaran mendasar. Kami juga telah memberikan panduan untuk membuat tugas kustom Anda sendiri.

Selain itu, Visual Studio Marketplace menawarkan sejumlah ekstensi; yang masing-masing, saat diinstal ke langganan atau koleksi Anda, memperluas katalog tugas dengan satu atau beberapa tugas. Selain itu, Anda dapat menulis ekstensi kustom Anda sendiri untuk menambahkan tugas ke Azure Pipelines atau TFS.

Di alur YAML, Anda merujuk ke tugas berdasarkan nama. Jika nama cocok dengan tugas dalam kotak dan tugas kustom, tugas dalam kotak akan diutamakan. Anda dapat menggunakan GUID tugas atau nama yang sepenuhnya memenuhi syarat untuk tugas kustom untuk menghindari risiko ini:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Untuk menemukan myPublisherId dan myExtensionId, pilih Dapatkan tugas di marketplace. Nilai setelah itemName dalam string URL Anda adalah myPublisherId dan myExtensionId. Anda juga dapat menemukan nama yang sepenuhnya memenuhi syarat dengan menambahkan tugas ke alur Rilis dan memilih Tampilkan YAML saat mengedit tugas.

Versi tugas

Tugas diberi versi, dan Anda harus menentukan versi utama tugas yang digunakan dalam alur Anda. Ini dapat membantu mencegah masalah saat versi baru tugas dirilis. Tugas biasanya kompatibel mundur, tetapi dalam beberapa skenario Anda mungkin mengalami kesalahan yang tidak dapat diprediksi ketika tugas diperbarui secara otomatis.

Saat versi minor baru dirilis (misalnya, 1.2 hingga 1.3), build atau rilis Anda akan secara otomatis menggunakan versi baru. Namun, jika versi utama baru dirilis (misalnya 2.0), build atau rilis Anda akan terus menggunakan versi utama yang Anda tentukan sampai Anda mengedit alur dan secara manual mengubah ke versi utama baru. Log build atau rilis akan menyertakan pemberitahuan bahwa versi utama baru tersedia.

Anda dapat mengatur versi minor mana yang akan digunakan dengan menentukan nomor versi lengkap tugas setelah @ tanda (misalnya: GoTool@0.3.1). Anda hanya bisa menggunakan versi tugas yang ada untuk organisasi Anda.

Di YAML, Anda menentukan versi utama yang digunakan @ dalam nama tugas. Misalnya, untuk menyematkan PublishTestResults ke versi 2 tugas:

steps:
- task: PublishTestResults@2

Alur YAML tidak tersedia di TFS.

Opsi kontrol tugas

Setiap tugas menawarkan beberapa Opsi Kontrol.

Opsi kontrol tersedia sebagai kunci pada bagian task .

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task

Opsi kontrol tersedia sebagai kunci pada bagian task .

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Opsi kontrol tersedia sebagai kunci pada bagian task .

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  retryCountOnTaskFailure: number # Max number of retries; default is zero
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Catatan

Tugas atau pekerjaan tertentu tidak dapat memutuskan secara sepihak apakah pekerjaan/tahap berlanjut. Apa yang dapat dilakukannya adalah menawarkan status berhasil atau gagal, dan tugas/pekerjaan hilir masing-masing memiliki komputasi kondisi yang memungkinkan mereka memutuskan apakah akan berjalan atau tidak. Kondisi default yang secara efektif "berjalan jika kita dalam keadaan berhasil".

Lanjutkan pada kesalahan mengubah ini dengan cara yang halus. Ini secara efektif "mengelabui" semua langkah/pekerjaan hilir untuk memperlakukan hasil apa pun sebagai "keberhasilan" untuk tujuan membuat keputusan itu. Atau untuk meletakkannya dengan cara lain, ia mengatakan "jangan mempertimbangkan kegagalan tugas ini ketika Anda membuat keputusan tentang kondisi struktur yang mengandung".

Periode batas waktu dimulai saat tugas mulai berjalan. Ini tidak termasuk waktu tugas diantrekan atau sedang menunggu agen.

Dalam YAML ini, PublishTestResults@2 akan berjalan bahkan jika langkah sebelumnya gagal karena kondisi succeededOrFailed().

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.7'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Kondisi

  • Hanya ketika semua dependensi sebelumnya dengan kumpulan agen yang sama telah berhasil. Jika Anda memiliki kumpulan agen yang berbeda, tahap atau pekerjaan tersebut akan berjalan bersamaan. Ini adalah default jika tidak ada kondisi yang ditetapkan dalam YAML.

  • Bahkan jika dependensi sebelumnya gagal, kecuali eksekusi dibatalkan. Gunakan succeededOrFailed() dalam YAML untuk kondisi ini.

  • Bahkan jika dependensi sebelumnya gagal, bahkan jika eksekusi dibatalkan. Gunakan always() dalam YAML untuk kondisi ini.

  • Hanya ketika dependensi sebelumnya telah gagal. Gunakan failed() dalam YAML untuk kondisi ini.

Target langkah

Tugas berjalan dalam konteks eksekusi, yang merupakan host agen atau kontainer. Langkah individual dapat mengambil alih konteksnya dengan menentukan target. Opsi yang tersedia adalah kata host untuk menargetkan host agen ditambah kontainer apa pun yang ditentukan dalam alur. Contohnya:

resources:
  containers:
  - container: pycontainer
    image: python:3.8

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Di sini, SampleTask berjalan pada host dan AnotherTask berjalan dalam kontainer.

Jumlah percobaan ulang jika tugas gagal

Gunakan retryCountOnTaskFailure untuk menentukan jumlah percobaan ulang jika tugas gagal. Defaultnya adalah nol.

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Catatan

  • Memerlukan agen versi 2.194.0 atau yang lebih baru. Tidak didukung untuk tugas tanpa agen.
  • Tugas yang gagal segera dicoba kembali.
  • Tidak ada asumsi tentang idempotensi tugas. Jika tugas memiliki efek samping (misalnya, jika membuat sumber daya eksternal sebagian), maka mungkin gagal saat kedua kali dijalankan.
  • Tidak ada informasi tentang jumlah coba lagi yang tersedia untuk tugas.
  • Peringatan ditambahkan ke log tugas yang menunjukkan bahwa ia gagal sebelum dicoba kembali.
  • Semua upaya untuk mencoba kembali tugas ditampilkan di UI sebagai bagian dari simpul tugas yang sama.

Alur YAML tidak tersedia di TFS.

Variabel lingkungan

Alur YAML didukung pada Azure DevOps Server 2019 dan yang lebih tinggi.

Setiap tugas memiliki env properti yang merupakan daftar pasangan string yang mewakili variabel lingkungan yang dipetakan ke dalam proses tugas.

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

Contoh berikut menjalankan script langkah yang merupakan pintasan untuk tugas baris Perintah, diikuti oleh sintaks tugas yang setara. Contoh ini menetapkan nilai ke AZURE_DEVOPS_EXT_PAT variabel lingkungan, yang digunakan untuk mengautentikasi dengan Azure DevOps CLI.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

Alat penginstal build (Azure Pipelines)

Alat penginstal memungkinkan alur build Anda menginstal dan mengontrol dependensi Anda. Secara khusus, Anda dapat:

  • Instal alat atau runtime dengan cepat (bahkan pada agen yang dihosting Microsoft) tepat pada waktunya untuk build CI Anda.

  • Validasi aplikasi atau pustaka Anda terhadap beberapa versi dependensi seperti Node.js.

Misalnya, Anda dapat menyiapkan alur build untuk menjalankan dan memvalidasi aplikasi untuk beberapa versi Node.js.

Contoh: Menguji dan memvalidasi aplikasi Anda di beberapa versi Node.js

Buat file azure-pipelines.yml di direktori dasar proyek Anda dengan konten berikut.

pool:
  vmImage: 'Ubuntu 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Buat alur build baru dan jalankan. Amati bagaimana build dijalankan. Alat PenginstalNode.js mengunduh versi Node.js jika belum ada di agen. Skrip Baris Perintah mencatat lokasi versi Node.js pada disk.

Alur YAML tidak tersedia di TFS.

Tugas alat penginstal

Untuk daftar tugas alat penginstal kami, lihat Tugas alat penginstal.

Menonaktifkan tugas dalam kotak dan Marketplace

Pada halaman pengaturan organisasi, Anda bisa menonaktifkan tugas Marketplace, tugas dalam kotak, atau keduanya. Menonaktifkan tugas Marketplace dapat membantu meningkatkan keamanan alur Anda. Jika Anda menonaktifkan tugas dalam kotak dan Marketplace, hanya tugas yang Anda instal tfx yang akan tersedia.

Bantuan dan dukungan