Mendesain saluran pipa

Selesai

Di unit ini, Anda mengikuti tim web Tailspin sambil mereka menentukan jalur rilis mereka untuk situs web Space Game.

Ketika Anda merencanakan alur rilis, Anda biasanya mulai dengan mengidentifikasi tahapan atau divisi utama, dari alur tersebut. Setiap tahap biasanya memetakan ke lingkungan. Misalnya, dalam modul sebelumnya, alur dasar Andy dan Mara memiliki tahap Penyebaran yang dipetakan ke instans Azure App Service.

Dalam modul ini, Anda mendorong perubahan dari satu tahap ke tahap berikutnya. Dalam setiap tahap, Anda menyebarkan situs web Space Game ke lingkungan yang terkait dengan tahap tersebut.

Setelah Anda menentukan tahap mana yang Anda butuhkan, pertimbangkan cara perubahan didorong dari satu tahap ke tahap berikutnya. Setiap tahap dapat menentukan kriteria keberhasilan yang harus dipenuhi sebelum build dapat pindah ke tahap berikutnya. Azure Pipelines menyediakan beberapa cara untuk membantu Anda mengontrol cara dan waktu perubahan bergerak melalui alur. Secara keseluruhan, pendekatan ini digunakan untuk manajemen rilis.

Di bagian ini, Anda:

• Mempelajari perbedaan antara tahap alur umum, seperti Build, Dev, Pengujian, dan Pentahapan.
• Pahami cara pemicu penyebaran secara manual, terjadwal, serta berkelanjutan memungkinkan Anda mengontrol waktu artefak berpindah ke tahap berikutnya dalam alur.
• Lihat cara persetujuan rilis menjeda alur hingga pemberi persetujuan menerima atau menolak rilis.

Pertemuan

Seluruh tim web Tailspin berkumpul bersama. Di Membuat alur rilis menggunakan Azure Pipelines, tim merencanakan tugas mereka untuk sprint saat ini. Setiap tugas berkaitan dengan melakukan build alur rilis mereka untuk situs web Space Game.

Ingat bahwa tim memutuskan lima tugas ini untuk sprint mereka:

• Membuat alur multitahap.
• Menghubungkan aplikasi web ke database.
• Mengotomatiskan tes kualitas.
• Mengotomatiskan tes performa.
• Meningkatkan irama rilis.

Tim mengadakan pertemuan untuk membicarakan tugas pertama, yaitu Membuat alur multitahap. Setelah tim mendefinisikan alur, ia dapat berpindah dari bukti dasar konsepnya ke alur rilis yang mencakup lebih banyak tahap, pemeriksaan kualitas, dan persetujuan.

Amita dan Tim sedang mengamati Andy dan Mara mendemonstrasikan alur rilis untuk kedua kalinya. Keduanya mengamati bahwa artefak dibangun dan diinstal pada App Service.

Tahap alur apa yang Anda butuhkan?

Saat Anda ingin mengimplementasikan alur rilis, penting untuk mengidentifikasi tahap mana yang Anda butuhkan terlebih dahulu. Tahap yang Anda pilih tergantung pada kebutuhan Anda. Mari kita ikuti tim sambil mereka memutuskan tahap mereka.

Tim: Oke, saya memahami gagasan alur otomatis. Saya suka bagaimana mudah untuk menyebarkan ke Azure. Tapi selanjutnya kita ke mana setelah demo ini? Kita membutuhkan sesuatu yang benar-benar dapat kita gunakan untuk rilis kita.

Amita: Benar! Kita harus menambahkan tahapan lain. Misalnya, saat ini, kami tidak memiliki tempat untuk tahap pengujian.

Tim: Selain itu, kita membutuhkan tahap tempat kita dapat menampilkan fitur baru kepada manajemen. Saya tidak dapat mengirim hal apa pun ke produksi tanpa persetujuan manajemen.

Andy: Tentu saja! Sekarang setelah mempercepat apa yang dilakukan alur rilis, bagaimana kita membuat alur ini melakukan apa yang kita butuhkan?

Mara: Mari kita buat sketsa persyaratan kita untuk membantu merencanakan langkah selanjutnya. Mari kita mulai dengan hal yang kita miliki.

Mara pindah ke papan tulis dan membuat sketsa alur yang ada.

Mara: Tahap Build membangun kode sumber dan menghasilkan sebuah paket. Dalam kasus kita, paket tersebut adalah file .zip. Tahap Penyebaran menginstal file .zip, yang merupakan situs web Space Game, pada instans App Service. Apa yang kurang dari alur rilis kita?

Menambahkan tahap Dev

Andy: Saya mungkin condong sebelah, tetapi menurut saya kita memerlukan tahap Dev. Tahap ini harus menjadi perhentian pertama untuk artefak setelah dibangun. Pengembang tidak selalu dapat menjalankan seluruh layanan dari lingkungan pengembangan lokal mereka. Misalnya, sistem e-niaga mungkin memerlukan situs web, database produk, serta sistem pembayaran. Kita membutuhkan tahap yang mencakup semua yang dibutuhkan aplikasi.

Dalam kasus kita, fitur papan peringkat situs web Space Game membaca skor tertinggi dari sumber eksternal. Saat ini, permainan tersebut membaca skor fiktif dari sebuah file. Menyiapkan tahap Dev akan memberi kita lingkungan tempat kita dapat mengintegrasikan aplikasi web dengan database nyata. Basis data itu mungkin masih menyimpan skor fiktif, tetapi cara ini membawa kita selangkah lebih dekat ke aplikasi terakhir kita.

Mara: Saya menyukainya. Kita belum akan berintegrasi dengan database yang sebenarnya. Namun dalam tahap Dev, kita dapat menyebarkan ke lingkungan tempat kita dapat menambahkan database.

Mara memperbarui gambarnya di papan tulis. Dia mengganti "Deploy" dengan "Dev" untuk menunjukkan tahap Dev.

Andy: Kamu mengemukakan hal yang menarik. Kita membangun aplikasi setiap kali kita mendorong perubahan ke GitHub. Apakah itu berarti setiap build didorong ke tahap Dev setelah selesai?

Mara: Membangun secara terus-menerus memberi kita umpan balik penting tentang kondisi build dan pengujian kita. Namun kita ingin mendorong ke tahap Dev hanya setelah kita menggabungkan kode ke beberapa cabang pusat: baik cabang utama atau cabang rilis lainnya. Saya akan memperbarui gambar untuk menampilkan persyaratan itu.

Mara: Menurut saya pendorongan ini akan mudah dilakukan. Kita dapat menentukan kondisi yang mendorong ke tahap Dev hanya setelah perubahan terjadi pada cabang rilis.

Apa itu syarat?

Pada Azure Pipelines, tugas atau pekerjaan Gunakan kondisi untuk dijalankan didasarkan pada status alur. Anda telah bekerja dengan kondisi tersebut di modul sebelumnya.

Ingat, beberapa kondisi yang bisa Anda tentukan adalah:

• Hanya setelah semua tugas dependen sebelumnya telah berhasil.
• Bahkan jika dependensi sebelumnya telah gagal, kecuali jika eksekusi dibatalkan.
• Bahkan jika dependensi sebelumnya telah gagal, bahkan jika eksekusi dibatalkan.
• Hanya setelah dependensi sebelumnya telah gagal.
• Beberapa kondisi kustom.

Berikut ini contoh dasarnya:

steps:
  - script: echo Hello!
    condition: always()

Kondisi always() menyebabkan tugas ini mencetak "Halo!" tanpa syarat, bahkan jika tugas sebelumnya gagal.

Kondisi ini digunakan jika Anda tidak menentukan kondisi:

condition: succeeded()

Fungsi bawaan succeeded() memeriksa apakah tugas sebelumnya berhasil. Jika tugas sebelumnya gagal, tugas ini serta tugas selanjutnya yang menggunakan kondisi yang sama akan dilewati.

Di sini Anda ingin membangun kondisi yang menentukan:

• Tugas sebelumnya berhasil.
• Nama cabang Git saat ini adalah rilis.

Untuk membangun kondisi ini, Anda menggunakan fungsi and() bawaan. Fungsi ini memeriksa apakah setiap kondisinya benar. Jika kondisi apa pun tidak berupa true, kondisi keseluruhan gagal.

Untuk mendapatkan nama cabang saat ini, Anda menggunakan variabel Build.SourceBranchName bawaan. Anda dapat mengakses variabel dalam suatu kondisi dalam beberapa cara. Di sini Anda menggunakan sintaks variables[].

Untuk menguji nilai variabel, Anda dapat menggunakan fungsi eq() bawaan. Fungsi ini memeriksa apakah argumennya sama.

Dengan mengingat hal itu, Anda menerapkan kondisi ini untuk menjalankan tahap Dev hanya bila nama cabang saat ini adalah "rilis":

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

Kondisi pertama dalam fungsi and() memeriksa apakah tugas sebelumnya berhasil. Kondisi kedua memeriksa apakah nama cabang saat ini sama dengan rilis.

Di YAML, Anda menggunakan sintaks alur (|) untuk mendefinisikan string yang mencakup beberapa baris. Anda dapat menentukan kondisi pada satu baris, tetapi kita menulisnya dengan cara ini agar lebih mudah dibaca.

Catatan

Dalam modul ini, kita menggunakan cabang rilis sebagai contoh. Anda dapat menggabungkan kondisi untuk menentukan perilaku yang Anda butuhkan. Misalnya, Anda dapat melakukan build kondisi yang menjalankan tahapan hanya setelah build dipicu oleh permintaan pull terhadap cabang utama.

Di unit berikutnya, saat Anda menyiapkan tahap Dev , Anda bekerja dengan contoh yang lebih lengkap.

Untuk deskripsi kondisi yang lebih lengkap di Azure Pipelines, baca dokumentasi ekspresi.

Mara: Dengan menggunakan kondisi, Anda bisa mengontrol perubahan mana yang dipromosikan ke tahap mana. Kita dapat membuat artefak build untuk perubahan apa pun guna memvalidasi build kita dan mengonfirmasi bahwa kondisinya bagus. Ketika sudah siap, kita dapat menggabungkan perubahan tersebut ke dalam cabang rilis dan mendorong build tersebut ke tahap Dev.

Menambahkan tahap Pengujian

Mara: Sejauh ini, kita memiliki tahap Build dan Dev. Apa yang selanjutnya?

Amita: Bisakah kita menambahkan tahap Pengujian selanjutnya? Tahap itu sepertinya tempat yang tepat bagi saya untuk menguji perubahan terbaru.

Mara menambahkan tahap Pengujian ke gambarnya di papan tulis.

Amita: Satu kekhawatiran yang saya miliki adalah seberapa sering saya perlu menguji aplikasi. Sebuah email memberitahu saya setiap kali Mara atau Andy membuat perubahan. Perubahan terjadi sepanjang hari, dan saya tidak pernah tahu kapan harus ikut bergabung. Menurut saya, saya ingin melihat build sekali sehari, mungkin ketika saya masuk kerja. Bisakah kita melakukannya?

Andy: Tentu saja. Mengapa kita tidak menyebarkan ke Pengujian selama jam pulang kerja? Semisal kita mengirimi Anda build setiap hari pada jam 3 pagi.

Mara: Kedengarannya bagus. Kita selalu dapat memicu proses secara manual juga jika perlu. Misalnya, kita dapat memicunya jika kita membutuhkan Anda untuk segera memverifikasi perbaikan bug penting.

Mara memperbarui gambarnya untuk menunjukkan bahwa build bergerak dari tahap Dev menjadi tahap Pengujian pada pukul 3 pagi setiap subuh.

Apa itu pemicu?

Amita: Saya merasa lebih baik sekarang karena kita tahu cara satu tahap berpindah dari satu tahap ke tahap lainnya. Tapi bagaimana kita mengontrol saat sebuah tahap berjalan?

Mara: Di Azure Pipelines, kita dapat menggunakan pemicu. Pemicu menentukan kapan tahapan berjalan. Azure Pipelines menyediakan beberapa jenis pemicu. Berikut adalah pilihan kita:

• Pemicu integrasi berkelanjutan (CI)
• Pemicu permintaan pull (PR)
• Pemicu terjadwal
• Pemicu penyelesaian build

Pemicu CI dan PR memungkinkan Anda mengontrol cabang mana yang berpartisipasi dalam keseluruhan proses. Misalnya, Anda ingin melakukan build proyek saat perubahan dibuat pada cabang mana pun. Pemicu terjadwal memulai penyebaran pada waktu tertentu. Pemicu penyelesaian build menjalankan build saat build lain, seperti build untuk komponen dependen berhasil diselesaikan. Sepertinya kita ingin pemicu terjadwal.

Apa itu pemicu terjadwal?

Pemicu terjadwal menggunakan sintaks cron untuk menyebabkan build berjalan pada jadwal yang ditentukan.

Pada sistem Unix dan Linux, cron merupakan cara yang populer untuk menjadwalkan pekerjaan agar berjalan pada interval waktu yang ditentukan atau pada waktu tertentu. Di Azure Pipelines, pemicu terjadwal menggunakan sintaks cron untuk menentukan kapan tahapan berjalan.

Ekspresi cron mencakup bidang yang cocok dengan parameter waktu tertentu. Berikut adalah bidangnya:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Misalnya, ekspresi cron ini menjelaskan "3 pagi setiap hari": 0 3 * * *

Ekspresi cron dapat menyertakan karakter khusus untuk menentukan daftar nilai atau rentang nilai. Dalam contoh ini, tanda bintang (*) cocok dengan semua nilai untuk bidang Hari, Bulan, dan Hari dalam seminggu.

Dengan kata lain, ekspresi cron ini berbunyi:

• Pada menit 0,
• Pada jam ketiga,
• Pada setiap hari dalam sebulan,
• Pada bulan apa saja,
• Pada hari apa saja dalam seminggu,
• Menjalankan pekerjaan

Untuk menentukan jam 3 pagi hanya pada hari Senin sampai Jumat, Anda akan menggunakan ekspresi ini: 0 3 * * 1-5

Catatan

Zona waktu untuk jadwal cron adalah Coordinated Universal Time (UTC), jadi dalam contoh ini, 3 AM mengacu pada 3 AM di UTC. Dalam praktiknya, Anda mungkin ingin menyesuaikan waktu dalam jadwal cron Anda relatif terhadap UTC sehingga alur berjalan pada waktu yang diharapkan untuk Anda dan tim Anda.

Untuk menyiapkan pemicu terjadwal di Azure Pipelines, Anda memerlukan bagian schedules di file YAML Anda. Berikut contohnya:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

Di bagian schedules ini:

• cron menentukan ekspresi cron.
• branches menentukan untuk menyebarkan hanya dari cabang release.
• always menentukan apakah akan menjalankan penyebaran tanpa syarat (true), atau hanya jika cabang release telah berubah sejak terakhir dijalankan (false). Di sini, Anda menentukan false karena Anda hanya perlu menyebarkan bila cabang release telah berubah sejak terakhir dijalankan.

Seluruh alur berjalan ketika Azure Pipelines menjalankan pemicu terjadwal. Alur juga berjalan dalam kondisi lain, seperti saat Anda mendorong perubahan ke GitHub. Untuk menjalankan tahapan hanya sebagai respons terhadap pemicu terjadwal, Anda bisa menggunakan kondisi yang memeriksa apakah alasan build adalah proses terjadwal.

Berikut contohnya:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Tahapan ini, Test hanya berjalan bila tahap sebelumnya berhasil dan variabel alur Build.Reason bawaan sama dengan Schedule.

Anda akan melihat contoh yang lebih lengkap nanti dalam modul ini.

Amita: Saya suka ini. Saya bahkan tidak perlu mengambil rilis secara manual dan menginstalnya. Sudah siap untukku.

Andy: Dan ingat, jika nanti kita ingin mengotomatisasi lagi, kita bisa melakukannya. Segalanya bisa diubah. Alur berkembang seiring dengan pembelajaran dan peningkatan kita.

Menambahkan tahap Pentahapan

Tim: Giliran saya. Aku butuh panggung untuk menjalankan lebih banyak tes stres. Kita juga membutuhkan tahap tempat kita bisa demonstrasi kepada manajemen untuk mendapatkan persetujuan mereka. Untuk saat ini, kedua kebutuhan tersebut dapat kita gabungkan menjadi sebuah tahapan yang dapat kita sebut sebagai Pentahapan.

Andy: Bagus sekali, Tim. Memiliki pentahapan atau praproduksi lingkungan adalah penting. Lingkungan pentahapan ini sering kali merupakan perhentian terakhir sebelum fitur atau perbaikan bug menjangkau pengguna kita.

Mara menambahkan Pentahapan ke gambarnya di papan tulis.

Amita: Kita menggunakan pemicu terjadwal untuk mendorong perubahan dari tahap Dev ke tahap Pengujian. Tetapi bagaimana cara mempromosikan perubahan dari Uji ke Penahapan? Apakah pendorongan itu juga harus sesuai jadwal?

Mara: Menurut saya cara terbaik untuk menanganinya adalah dengan persetujuan rilis. Persetujuan rilis memungkinkan Anda secara manual mendorong perubahan dari satu tahap ke tahap berikutnya.

Amita: Tampaknya persis seperti yang saya butuhkan! Persetujuan rilis akan memberi saya waktu untuk menguji perubahan terbaru sebelum kita mempresentasikan build ke manajemen. Saya dapat mendorong build ketika saya siap.

Mara memperbarui gambarnya untuk menunjukkan bahwa build berpindah dari Pengujian ke Pentahapan hanya setelah Amita menyetujuinya.

Tim: Saya juga dapat membayangkan kita menggunakan persetujuan rilis untuk mendorong dari Pentahapan ke Produksi setelah manajemen menyetujui. Saya tidak pernah bisa memprediksi berapa lama waktu yang dibutuhkan. Setelah manajemen menandatangani, saya dapat menyetujui rilis dan mendorongnya ke produksi secara manual. Tapi bagaimana cara kerja persetujuan rilis?

Apa itu persetujuan rilis?

Persetujuan rilis adalah cara untuk menjeda alur hingga pemberi persetujuan menerima atau menolak rilis. Untuk menentukan alur kerja rilis, Anda dapat menggabungkan persetujuan, ketentuan, dan pemicu.

Ingat bahwa di Membuat alur rilis menggunakan Azure Pipelines, Anda menetapkan lingkungan dalam konfigurasi alur untuk mewakili lingkungan penyebaran Anda. Berikut ini contoh dari alur Anda yang sudah ada:

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

Lingkungan Anda dapat menyertakan kriteria khusus untuk rilis Anda. Kriteria dapat menentukan alur mana yang dapat diterapkan ke lingkungan tersebut dan persetujuan manusia apa yang diperlukan untuk mempromosikan rilis dari satu tahap ke tahap berikutnya.

Kemudian dalam modul ini, Anda menentukan lingkungan penahapan , dan menetapkan diri Anda sebagai pemberi persetujuan untuk mempromosikan aplikasi web Space Game dari tahap Pengujian ke Penahapan.

Otomatiskan sesedikit atau sebanyak yang Anda butuhkan

Azure Pipelines memberi Anda fleksibilitas untuk mengotomatiskan beberapa tahapan sambil secara manual mengontrol tahapan yang belum siap untuk otomatisasi.

Tim: Saya suka cara kita dapat menentukan kriteria yang mendorong perubahan dari satu tahap ke tahap berikutnya. Tetapi kami mendefinisikan beberapa kriteria manual dalam alur kami. Saya pikir DevOps adalah tentang mengotomatisasi segalanya.

Mara: Anda mengajukan poin yang bagus. DevOps benar-benar tentang mengotomatiskan tugas yang repetitif dan rawan kesalahan. Terkadang campur tangan manusia diperlukan. Misalnya, kita mendapatkan persetujuan dari manajemen sebelum kita merilis fitur baru. Ketika kita mendapatkan lebih banyak pengalaman dengan penyebaran otomatis, kita dapat mengotomatiskan lebih banyak langkah manual kita untuk mempercepat proses. Misalnya, kita dapat mengotomatiskan lebih banyak pemeriksaan kualitas dalam tahap Pengujian , sehingga Amita tidak perlu menyetujui setiap build.

Tim: Kedengarannya bagus. Mari kita jalankan rencana ini untuk saat ini, dan lihat cara kita bisa mempercepat sistem nanti.

Amita: Omong-omong tentang rencana kita, dapatkah kita meringkas langkah selanjutnya?

Rencananya

Mari kita tinjau rencana tim Tailspin sambil mereka bergerak menuju langkah selanjutnya.

Mara: Inilah alur rilis yang ingin kita bangun.

Mara menunjuk ke papan tulis.

Mara: Untuk meringkas, langkah-langkah kita adalah:

1. Menghasilkan artefak build setiap kali kita mendorong perubahan ke GitHub. Langkah ini terjadi pada tahap Build.
2. Mempromosikan artefak build ke tahap Dev. Langkah ini terjadi secara otomatis ketika tahap build berhasil dan perubahan ada di cabang rilis.
3. Mendorong artefak build ke tahap Pengujian setiap pagi pukul 3 subuh. Kita menggunakan pemicu terjadwal untuk mendorong artefak bangunan secara otomatis.
4. Mendorong artefak build ke Pentahapan setelah Amita menguji dan menyetujui build. Kita menggunakan persetujuan rilis untuk mendorong artefak build.

Setelah manajemen menyetujui build, kita dapat menyebarkan artefak build ke lingkungan produksi.

Amita: Apakah tahapan ini akan sulit dilakukan? Sepertinya banyak yang harus dilakukan.

Menurutku tidak terlalu buruk. Setiap tahap terpisah dari setiap tahap lainnya. Tahapan bersifat dikret. Setiap tahap memiliki serangkaian tugas masing-masing. Misalnya, apa pun yang terjadi pada tahap Test akan tetap berada di tahap Test.

Setiap tahap penyebaran di alur kita juga memiliki lingkungannya sendiri. Misalnya, saat kita menyebarkan aplikasi ke Dev atau Pengujian, lingkungannya adalah instans App Service.

Terakhir, kita hanya menguji satu rilis demi satu rilis. Kita tidak boleh mengubah rilis di tengah alur. Kita menggunakan rilis yang sama pada tahap Dev seperti pada tahap Pentahapan, dan setiap rilis memiliki nomor versinya masing-masing. Jika rilis terputus di salah satu tahap, kita memperbaikinya dan melakukan build lagi dengan nomor versi baru. Rilis baru itu kemudian melalui alur dari awal.

Beberapa saran tentang kualitas

Anda baru saja melihat tim merancang alur yang mengambil aplikasi mereka dari build hingga penahapan. Inti dari alur ini bukan hanya untuk membuat hidup mereka menjadi lebih mudah. Cara ini untuk memastikan kualitas perangkat lunak yang mereka berikan kepada pelanggan mereka.

Bagaimana Anda mengukur kualitas proses rilis Anda? Kualitas proses rilis Anda tidak dapat diukur secara langsung. Apa yang dapat Anda ukur adalah seberapa baik proses Anda bekerja. Jika Anda terus mengubah proses, mungkin ada indikasi bahwa ada sesuatu yang salah. Rilis yang gagal secara konsisten pada titik tertentu dalam alur mungkin juga menunjukkan bahwa ada masalah dengan proses rilis.

Apakah rilis selalu gagal pada hari atau waktu tertentu? Apakah rilis selalu gagal setelah Anda menyebarkan ke lingkungan tertentu? Cari masalah ini dan pola lainnya untuk melihat apakah beberapa aspek dari proses rilis dependen atau terkait.

Cara yang baik untuk melacak kualitas proses rilis Anda adalah dengan membuat visualisasi kualitas rilis. Misalnya, tambahkan widget dasbor yang menunjukkan status setiap rilis kepada Anda.

Saat Anda ingin mengukur kualitas rilis itu sendiri, Anda dapat melakukan semua jenis pemeriksaan di dalam alur. Misalnya, Anda dapat menjalankan berbagai jenis pengujian, seperti pengujian beban, dan pengujian UI saat menjalankan alur Anda.

Menggunakan gerbang kualitas juga merupakan cara yang bagus untuk memeriksa kualitas rilis Anda. Ada banyak gerbang kualitas yang berbeda. Misalnya, gerbang item pekerjaan dapat memverifikasi kualitas proses persyaratan Anda. Anda juga dapat menambahkan lebih banyak pemeriksaan keamanan dan kepatuhan. Misalnya, apakah Anda mematuhi prinsip empat mata atau apakah Anda memiliki keterlacakan yang tepat?

Saat Anda maju melalui jalur pembelajaran ini, Anda melihat banyak teknik ini dimasukkan ke dalam praktik.

Terakhir, ketika Anda merancang proses rilis berkualitas, pikirkan jenis dokumentasi atau catatan rilis apa yang perlu Anda berikan kepada pengguna. Menjaga dokumentasi Anda tetap diperbarui bisa jadi sulit. Anda mungkin ingin mempertimbangkan untuk menggunakan alat, seperti Azure DevOps Release Notes Generator. Generator merupakan aplikasi fungsi yang berisi fungsi, yang dipicu HTTP. Dengan menggunakan Azure Blob Storage, ia membuat file Markdown setiap kali rilis baru dibuat di Azure DevOps.

Uji pengetahuan Anda

1.

Alur Anda mencakup banyak pengujian dan pemeriksaan kualitas yang membutuhkan waktu beberapa menit untuk diselesaikan. Jenis pemicu mana yang terbaik untuk menjalankan pengujian hanya pada kode yang ditinjau serekan?

Pemicu penyelesaian build

Pemicu CI atau pemicu PR

Pemicu terjadwal

2.

Apa cara terbaik untuk menjeda alur sampai pemberi persetujuan menyetujui perubahan?

Menggunakan persetujuan rilis.

Instal ekstensi Marketplace yang menyediakan tugas Azure Pipelines yang dapat menjeda alur.

Minta pemberi persetujuan Anda untuk melihat perubahannya. Kemudian secara manual picu alur untuk berjalan.

3.

Anda ingin menyebarkan aplikasi web Anda ke lingkungan Pengujian setiap kali pembangunan selesai. Apa cara termudah untuk menyiapkan proses tersebut?

Menggunakan pemicu terjadwal.

Perhatikan email pemberitahuan build dan picu build Anda secara manual saat build yang lain berhasil selesai.

Menggunakan pemicu penyelesaian build.

Anda harus menjawab semua pertanyaan sebelum memeriksa pekerjaan Anda.