Merancang alur

Selesai

Dalam unit ini, Anda mengikuti tim web Tailspin saat mereka menentukan alur rilis untuk situs web Space Game.

Saat Anda merencanakan alur rilis, Anda biasanya mulai dengan mengidentifikasi tahap , atau divisi utama, dari alur tersebut. Setiap tahap biasanya berhubungan dengan lingkungan. Misalnya, dalam modul sebelumnya, alur dasar Andy dan Mara memiliki tahap Penerapan yang dipetakan ke contoh Azure App Service.

Dalam modul ini, Anda memfasilitasi 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 tahapan mana yang Anda butuhkan, pertimbangkan bagaimana perubahan dipromosikan dari satu tahap ke tahap berikutnya. Setiap tahap dapat menentukan kriteria keberhasilan yang harus dipenuhi sebelum build dapat berpindah ke tahap berikutnya. Azure Pipelines menyediakan beberapa cara untuk membantu Anda mengontrol bagaimana dan kapan perubahan berpindah melalui alur. Secara keseluruhan, pendekatan ini digunakan untuk manajemen rilis .

Di bagian ini, Anda:

• Pelajari perbedaan antara tahap alur umum, seperti Build, Dev, Test, dan Staging.
• Pahami cara menggunakan pemicu penyebaran manual, terjadwal, dan berkelanjutan untuk mengontrol kapan artefak berpindah ke tahap berikutnya dalam alur.
• Lihat bagaimana persetujuan rilis menjeda alur proses hingga pemberi persetujuan menerima atau menolak rilis.

Rapat

Seluruh tim web Tailspin dikumpulkan bersama-sama. Di Buat alur rilis dengan Azure Pipelines, tim merencanakan tugas mereka untuk sprint saat ini. Setiap tugas berkaitan dengan membangun alur rilis mereka untuk situs web Space Game.

Ingatlah bahwa tim memutuskan lima tugas ini untuk sprint mereka:

• Membuat pipa multi-tahap.
• Sambungkan aplikasi web ke database.
• Mengotomatiskan pengujian kualitas.
• Mengotomatiskan pengujian performa.
• Meningkatkan frekuensi rilis.

Tim bertemu untuk berbicara tentang tugas pertama, Membuat rangkaian bertahap. 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 menyaksikan Andy dan Mara menunjukkan alur rilis untuk kedua kalinya. Mereka melihat bahwa artefak dibangun dan diinstal di App Service.

Tahap alur apa yang Anda butuhkan?

Saat Anda ingin menerapkan alur rilis, penting untuk terlebih dahulu mengidentifikasi tahapan mana yang Anda butuhkan. Tahapan yang Anda pilih bergantung pada kebutuhan Anda. Mari kita ikuti bersama dengan tim saat mereka memutuskan tahapan mereka.

Tim: OK, saya memahami ide alur otomatis. Saya suka bagaimana mudah untuk menyebarkan ke Azure. Jadi, kemana kita pergi setelah demonstrasi ini? Kita membutuhkan sesuatu yang benar-benar dapat kita gunakan untuk rilis kita.

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

Tim: Plus, kami memerlukan tahap di mana kami dapat menampilkan fitur baru kepada manajemen. Saya tidak dapat mengirim apa pun ke produksi tanpa persetujuan manajemen.

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

Mara: Mari buat sketsa persyaratan kami untuk membantu merencanakan langkah-langkah kami berikutnya. Mari kita mulai dengan apa yang kita miliki.

Mara pindah ke papan tulis dan sketsa alur yang ada.

Mara: Tahap Build membangun kode sumber dan menghasilkan paket. Dalam kasus kami, paket itu adalah file .zip. Tahap Deploy menginstal file .zip, yang merupakan situs web Space Game, pada instance App Service. Apa yang hilang dari alur rilis kami?

Menambahkan tahap Dev

Andy: saya mungkin bias, tapi saya pikir kita perlu tahap Dev. Tahap ini harus menjadi tahapan pertama untuk artefak tersebut setelah dibuat. Pengembang tidak selalu dapat menjalankan seluruh layanan dari lingkungan pengembangan lokal mereka. Misalnya, sistem e-niaga mungkin memerlukan situs web, database produk, dan sistem pembayaran. Kami memerlukan tahap yang mencakup semua yang dibutuhkan aplikasi.

Dalam kasus kami ini, fitur papan peringkat situs web Space Game membaca skor tertinggi dari sumber eksternal. Saat ini, ia membaca skor fiktif dari berkas. Menyiapkan tahap Dev akan memberi kita lingkungan di mana kita dapat mengintegrasikan aplikasi web dengan database nyata. Database itu mungkin masih menyimpan skor fiktif, tetapi membawa kita selangkah lebih dekat ke aplikasi akhir kita.

Mara: aku menyukainya. Kami belum akan berintegrasi dengan database nyata. Tetapi 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: Anda memunculkan poin yang menarik. Kami membangun aplikasi setiap kali kami mendorong perubahan ke GitHub. Apakah itu berarti setiap build dipromosikan ke tahap Dev setelah selesai?

Mara: Proses membangun secara terus menerus menyediakan umpan balik yang penting bagi kami tentang kondisi build dan pengujian. Tetapi kami ingin mempromosikan ke tahap Dev hanya ketika kami menggabungkan kode ke suatu cabang pusat: baik itu cabang utama atau cabang rilis lainnya. Aku akan memperbarui gambar untuk menunjukkan persyaratan itu.

Mara: saya pikir promosi ini akan mudah dicapai. Kita dapat mendefinisikan kondisi yang memindahkan ke tahap Dev hanya ketika perubahan terjadi pada cabang rilis.

Apa itu kondisi?

Di Azure Pipelines, menggunakan kondisi untuk menjalankan tugas atau pekerjaan berdasarkan status alur. Anda telah bekerja dengan kondisi di modul sebelumnya.

Ingat, beberapa kondisi yang dapat Anda tentukan adalah:

• Hanya ketika semua tugas dependen sebelumnya telah berhasil.
• Bahkan jika dependensi sebelumnya gagal, kecuali pelaksanaan dibatalkan.
• Bahkan jika dependensi sebelumnya gagal, bahkan jika proses dijalankan dibatalkan.
• Hanya ketika dependensi sebelumnya gagal.
• Beberapa kondisi khusus.

Berikut adalah 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 dan tugas yang lebih baru yang menggunakan kondisi yang sama akan dilewati.

Di sini Anda ingin membangun sebuah kondisi yang ditentukan oleh:

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

Untuk membangun kondisi ini, Anda menggunakan fungsi and() bawaan. Fungsi ini memeriksa apakah masing-masing kondisinya benar. Jika ada kondisi yang tidak benar, kondisi keseluruhan gagal.

Untuk mendapatkan nama cabang saat ini, Anda menggunakan variabel Build.SourceBranchName bawaan. Anda dapat mengakses variabel dalam 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 mempertimbangkan hal tersebut, Anda menerapkan kondisi ini untuk menjalankan tahap Dev hanya ketika 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 pipa (|) untuk menentukan string yang mencakup beberapa baris. Anda dapat menentukan kondisi pada satu baris, tetapi kami menulisnya dengan cara ini untuk membuatnya lebih mudah dibaca.

Nota

Dalam modul ini, kami menggunakan cabang rilis sebagai contoh. Anda dapat menggabungkan kondisi untuk menentukan perilaku yang Anda butuhkan. Misalnya, Anda dapat membuat kondisi yang menjalankan tahap tersebut hanya ketika build dipicu oleh permintaan penarikan terhadap cabang utama .

Pada unit berikutnya, saat Anda menyiapkan tahap Dev, Anda menggunakan contoh yang lebih lengkap.

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

Mara: Dengan menggunakan kondisi, Anda dapat mengontrol perubahan mana yang dipromosikan ke tahap mana. Kami dapat menghasilkan artefak build untuk setiap perubahan guna memvalidasi build kami dan mengonfirmasi bahwa build tersebut stabil. Setelah siap, kita dapat menggabungkan perubahan tersebut ke dalam cabang rilis dan mempromosikan build tersebut ke tahap Dev.

Menambahkan tahap Uji

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

Amita: Dapatkah kita menambahkan tahap Uji berikutnya? Itu sepertinya tempat yang tepat bagi saya untuk menguji perubahan terbaru.

Mara menambahkan tahap uji ke gambarnya di papan tulis.

Amita: Satu kekhawatiran yang saya miliki adalah seberapa sering saya perlu menguji aplikasi. Email memberi tahu saya setiap kali Mara atau Andy membuat perubahan. Perubahan terjadi sepanjang hari, dan saya tidak pernah tahu kapan harus melompat masuk. Saya pikir saya ingin melihat sebuah bangunan sekali sehari, mungkin ketika saya masuk ke kantor. Bisa kita lakukan itu?

Andy: Yakin. Mengapa kita tidak menyebarkan ke Test di luar jam kerja? Misalkan kami mengirimkan build kepada Anda setiap hari pada pukul 3 pagi.

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

Mara memperbarui gambarnya untuk menunjukkan bahwa build bergerak dari tahap Dev ke tahap Test pada pukul 3 pagi setiap pagi.

diagram

Apa itu pemicu?

Amita: saya merasa lebih baik sekarang karena kita tahu bagaimana satu tahap bergerak ke tahap lain. Tapi bagaimana kita mengontrol kapan panggung berjalan?

Mara: Dalam Azure Pipelines, kita dapat menggunakan pemicu. Pemicu menentukan kapan tahap dijalankan. Azure Pipelines menyediakan beberapa jenis pemicu. Berikut adalah pilihan kami:

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

Pemicu CI dan PR memungkinkan Anda mengontrol cabang mana yang berpartisipasi dalam proses keseluruhan. Misalnya, Anda ingin membangun proyek saat perubahan dilakukan di 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 menyebabkan build berjalan pada jadwal yang ditentukan.

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

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

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

Misalnya, pernyataan cron ini menjelaskan "pukul 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 Days, Months, dan Days of week.

Dengan kata lain, ekspresi cron ini dapat dibaca sebagai:

• Pada menit 0,
• Pada jam ketiga,
• Setiap hari dalam sebulan,
• Pada bulan manapun,
• Setiap hari dalam seminggu,
• Jalankan pekerjaan

Untuk menentukan 3 A.M. hanya pada hari Senin hingga Jumat, Anda akan menggunakan ekspresi ini: 0 3 * * 1-5

Nota

Zona waktu untuk jadwal cron adalah Waktu Universal Terkoordinasi (UTC), jadi dalam contoh ini, 3 A.M. mengacu pada 3 A.M. dalam 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 dalam file YAML Anda. Berikut adalah 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 menginstruksikan untuk menyebarkan hanya dari cabang release.
• always menentukan apakah akan menjalankan penyebaran tanpa syarat (true), atau hanya ketika cabang release telah berubah sejak eksekusi terakhir (false). Di sini, Anda memilih false karena Anda hanya perlu menyebarkan ketika terjadi perubahan pada cabang release sejak eksekusi terakhir.

Seluruh alur berjalan saat Azure Pipelines menjalankan pemicu terjadwal. Pipeline juga beroperasi dalam situasi lain, seperti ketika Anda melakukan perubahan di GitHub. Untuk menjalankan tahap hanya sebagai respons terhadap pemicu terjadwal, Anda dapat menggunakan syarat yang memeriksa apakah alasan dilakukannya build adalah dijalankan sesuai jadwal.

Berikut adalah contohnya:

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

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

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

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

Andy: Dan ingat, jika kita ingin mengotomatiskan lebih banyak nanti, kita bisa. Tidak ada yang ditulis dalam batu. Alur berevolusi saat kita meningkatkan dan belajar.

Tambahkan tahap Staging

Tim: Giliranku. Aku butuh panggung untuk menjalankan lebih banyak tes stres. Kita juga membutuhkan tahap di mana kita dapat demo ke manajemen untuk mendapatkan persetujuan mereka. Saat ini, kita dapat menggabungkan kedua kebutuhan tersebut menjadi sebuah tahap yang bisa kita sebut Penahapan.

Andy: Tepat sekali, Tim. Memiliki lingkungan penahapan , atau lingkungan praproduksi, adalah penting. Lingkungan penahapan ini sering kali menjadi pemberhentian terakhir sebelum fitur atau perbaikan bug menjangkau pengguna kami.

Mara menambahkan Penahapan ke penggambarannya di papan tulis.

Amita: Kami menggunakan pemicu terjadwal untuk mempromosikan perubahan dari tahap Dev ke tahap Test. Tetapi bagaimana cara mempromosikan perubahan dari Pengujian ke Penahapan? Apakah promosi itu juga harus terjadi sesuai jadwal?

Mara: Saya pikir cara terbaik untuk menanganinya adalah persetujuan rilis . Persetujuan rilis memungkinkan Anda mempromosikan perubahan secara manual dari satu tahap ke tahap berikutnya.

Amita: Kedengarannya seperti apa yang saya butuhkan! Persetujuan rilis akan memberi saya waktu untuk menguji perubahan terbaru sebelum kami menyajikan build ke manajemen. Saya dapat mempromosikan build ketika saya siap.

Mara memperbarui gambarnya untuk menunjukkan bahwa build berpindah dari Test ke Staging hanya ketika Amita menyetujuinya.

Tim: Saya juga dapat membayangkan kami menggunakan persetujuan rilis untuk mempromosikan dari Penahapan ke Produksi setelah disetujui oleh manajemen. Aku tidak pernah bisa memprediksi berapa lama waktu yang dibutuhkan. Setelah mereka memberikan persetujuan, saya dapat menyetujui rilis dan mempromosikannya ke lingkungan produksi secara manual. Tetapi bagaimana cara kerja persetujuan rilis?

Apa itu persetujuan rilis?

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

Ingat bahwa di Buat alur rilis dengan Azure Pipelines, Anda menentukan lingkungan dalam konfigurasi alur Anda untuk mewakili lingkungan penyebaran Anda. Berikut adalah 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 disebarkan 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 izin untuk mempromosikan aplikasi web Space Game dari tahap Pengujian ke Penahapan.

Mengotomatisasi sedikit atau sebanyak yang Anda butuhkan

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

Tim: saya suka bagaimana kita dapat menentukan kriteria yang mempromosikan perubahan dari satu tahap ke tahap berikutnya. Tetapi kami mendefinisikan beberapa kriteria manual dalam proses kami. Saya pikir DevOps adalah tentang mengotomatiskan semuanya.

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

Tim: Terdengar hebat. Mari kita ikuti rencana ini untuk saat ini, dan nanti kita lihat bagaimana mempercepat sistem.

Amita: Berbicara tentang rencana kami, dapatkah kita meringkas langkah-langkah kita berikutnya?

Rencana

Mari kita tinjau rencana tim Tailspin saat mereka bergerak menuju langkah berikutnya.

Mara: Berikut adalah alur rilis yang ingin kita buat.

Mara menunjuk ke papan tulis.

Mara: Untuk meringkas, langkah-langkah kami adalah:

1. Membuat artefak build setiap kali kami mengunggah perubahan ke GitHub. Langkah ini terjadi pada tahap Build.
2. Promosikan artefak build ke tahap Dev. Langkah ini terjadi secara otomatis ketika tahap build berhasil dan perubahan ada di cabang rilis.
3. Promosikan artefak build ke tahap Pengujian setiap pagi pada pukul 3 pagi. Kami menggunakan pemicu yang dijadwalkan untuk mempromosikan artefak build secara otomatis.
4. Promosikan artefak build ke Penahapan setelah Amita menguji dan menyetujui build. Kami menggunakan persetujuan rilis untuk mempromosikan artefak build.

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

Amita: Apakah ini akan sulit dilakukan? Sepertinya banyak pekerjaan.

Mara: saya tidak berpikir itu terlalu buruk. Setiap tahap terpisah dari setiap tahap lainnya. Tahapan bersifat diskrit. Setiap tahap memiliki serangkaian tugasnya sendiri. Misalnya, apa yang terjadi pada tahap Test tetap berada dalam tahap Test.

Setiap tahap penyebaran di alur kami juga memiliki lingkungannya sendiri. Misalnya, saat kami menyebarkan aplikasi untuk Dev atau Test, lingkungannya adalah instance App Service.

Akhirnya, kita hanya menguji satu rilis pada satu waktu. Kami tidak pernah mengubah rilis di tengah jalur pengembangan. Kami menggunakan rilis yang sama dalam tahap Dev seperti pada tahap Staging, dan setiap rilis memiliki nomor versinya sendiri. Jika rilis berhenti di salah satu tahap, kami memperbaikinya dan membangunnya lagi dengan nomor versi baru. Rilis baru itu kemudian melewati alur dari awal.

Beberapa kata tentang kualitas

Anda baru saja melihat tim merancang pipeline yang membawa aplikasi mereka dari build hingga penahapan. Tujuan utama dari alur ini bukan hanya untuk mempermudah hidup mereka. 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 mereka selalu gagal setelah Anda menyebarkan ke lingkungan tertentu? Cari pola-pola ini dan lainnya untuk melihat apakah beberapa aspek proses rilis bergantung 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.

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

Menggunakan penghalang kualitas juga merupakan cara yang bagus untuk memeriksa kualitas rilis Anda. Ada banyak gerbang kualitas yang berbeda. Misalnya, gerbang item kerja 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 pelacakan yang memadai?

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 terkini bisa sulit. Anda mungkin ingin mempertimbangkan untuk menggunakan alat, seperti Azure DevOps Release Notes Generator. Generator adalah aplikasi fungsi yang berisi fungsi yang dipicu HTTP. Dengan menggunakan Azure Blob Storage, azure Blob Storage membuat file Markdown setiap kali rilis baru dibuat di Azure DevOps.

Periksa 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 telah ditinjau sejawat?

Pemicu penyelesaian pembangunan

Pemicu CI atau pemicu PR

Pemicu yang dijadwalkan

2.

Apa cara terbaik untuk menjeda alur hingga pemberi persetujuan menandatangani perubahan?

Gunakan persetujuan rilis.

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

Minta pemberi persetujuan Anda untuk melihat perubahan tersebut. Kemudian picu alur secara manual untuk dijalankan.

3.

Anda ingin mengimplementasikan aplikasi web Anda ke lingkungan Uji setiap kali build selesai. Apa cara term mudah untuk menyiapkan prosesnya?

Gunakan pemicu terjadwal.

Periksa email pemberitahuan build dan picu build Anda secara manual ketika build yang lain berhasil diselesaikan.

Gunakan pemicu penyelesaian kompilasi.

Anda harus menjawab semua pertanyaan sebelum memeriksa pekerjaan Anda.