Menyesuaikan dan memperluas alur kerja permintaan pull dengan status permintaan pull

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Permintaan pull adalah alat yang bagus untuk memfasilitasi tinjauan kode dan mengelola pergerakan kode dalam repositori. Kebijakan cabang memberlakukan kualitas kode selama proses permintaan pull dengan menetapkan persyaratan yang harus dilakukan untuk setiap perubahan kode. Kebijakan ini memungkinkan tim untuk menerapkan banyak praktik terbaik yang terkait dengan meninjau kode dan menjalankan build otomatis, tetapi banyak tim memiliki persyaratan dan validasi tambahan untuk dilakukan pada kode. Untuk mencakup kebutuhan individual dan kustom ini, Azure Repos menawarkan status permintaan pull. Status permintaan pull terintegrasi ke dalam alur kerja PR dan memungkinkan layanan eksternal untuk secara terprogram menandatangani perubahan kode dengan mengaitkan informasi jenis keberhasilan/kegagalan sederhana dengan permintaan pull. Secara opsional, permintaan pull dapat diblokir hingga layanan eksternal menyetujui perubahan.

Mengintegrasikan ke dalam alur kerja PR melibatkan beberapa konsep yang berbeda:

• Status permintaan pull - menyediakan cara bagi layanan untuk mengaitkan informasi keberhasilan/kegagalan dengan permintaan pull.
• Kebijakan status - menyediakan mekanisme untuk memblokir penyelesaian permintaan pull hingga status permintaan pull menunjukkan keberhasilan.
• Tindakan kustom - menyediakan cara untuk memperluas menu status menggunakan ekstensi Azure DevOps Services.

Dalam topik ini, Anda akan mempelajari tentang status permintaan pull dan bagaimana mereka dapat digunakan untuk berintegrasi dalam alur kerja PR.

Status permintaan pull

Status permintaan pull menyediakan cara bagi layanan untuk mengaitkan informasi jenis keberhasilan/kegagalan sederhana dengan permintaan pull, menggunakan API Status. Status terdiri dari empat bagian utama data:

• Negara bagian. Salah satu status yang telah ditentukan sebelumnya berikut: succeeded, , failed, pending, notSetnotApplicable, atau error.
• Deskripsi. String yang menjelaskan status kepada pengguna akhir.
• Konteks. Nama untuk status - biasanya menjelaskan entitas yang memposting status.
• URL. Tautan tempat pengguna bisa mendapatkan informasi lebih lanjut khusus untuk status tersebut.

Pada dasarnya, status adalah cara pengguna atau layanan memposting evaluasi mereka tentang permintaan pull dan memberikan jawaban atas pertanyaan seperti:

• Apakah perubahan memenuhi persyaratan?
• Di mana saya dapat mempelajari lebih lanjut tentang apa yang perlu saya lakukan untuk memenuhi persyaratan?

Mari lihat contohnya. Pertimbangkan layanan CI yang diperlukan untuk membangun semua perubahan kode dalam proyek. Ketika layanan tersebut mengevaluasi perubahan permintaan pull, layanan perlu memposting kembali hasil build dan pengujian. Untuk perubahan yang melewati build, status seperti ini mungkin diposting di PR:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Status ini akan ditampilkan kepada pengguna akhir dalam tampilan Detail PR:

• state ditunjukkan kepada pengguna menggunakan ikon (centang hijau untuk succeeded, X merah untuk failed, jam untuk pending, dan merah ! untuk error).
• description ditampilkan di samping ikon, dan context tersedia dalam tipsalat.
• targetUrl Saat diterapkan, deskripsi akan dirender sebagai tautan ke URL.

Memperbarui status

Layanan dapat memperbarui status PR untuk satu PR dengan memposting status tambahan, hanya yang terbaru yang ditampilkan untuk setiap unik context. Memposting beberapa status membantu pengguna mengelola ekspektasi. Misalnya, memposting pending status adalah cara yang baik untuk mengakui kepada pengguna bahwa sistem telah menerima peristiwa dan memulai pekerjaan. Menggunakan informatif description seperti contoh berikut dapat lebih membantu pengguna memahami cara kerja sistem:

• "Bangun antrean"
• "Build sedang berlangsung"
• "Build berhasil"

Status perulangan

Ketika cabang sumber dalam PR berubah, "iterasi" baru dibuat untuk melacak perubahan terbaru. Layanan yang mengevaluasi perubahan kode ingin memposting status baru pada setiap iterasi PR. Memposting status ke iterasi tertentu dari PR menjamin bahwa status hanya berlaku untuk kode yang dievaluasi dan tidak ada pembaruan di masa mendatang.

Catatan

Jika PR yang dibuat berisi lebih dari 100.000 file yang dimodifikasi, maka, untuk alasan performa dan stabilitas, PR tersebut tidak akan mendukung perulangan. Ini berarti setiap perubahan tambahan pada PR tersebut akan disertakan tetapi tidak ada iterasi baru yang akan dibuat untuk perubahan tersebut. Selain itu, setiap upaya untuk membuat status untuk iterasi yang tidak ada akan mengembalikan kesalahan.

Sebaliknya, jika status yang diposting berlaku untuk seluruh PR, terlepas dari kode, memposting ke iterasi mungkin tidak perlu. Misalnya, memeriksa bahwa penulis (properti PR yang tidak dapat diubah) milik grup tertentu hanya perlu dievaluasi sekali, dan status perulangan tidak akan diperlukan.

Saat mengonfigurasi kebijakan status, jika status iterasi digunakan, kondisi Reset harus diatur ke Reset status setiap kali ada perubahan baru. Ini lebih menjamin bahwa PR tidak akan dapat digabungkan sampai iterasi terbaru memiliki status succeeded.

Lihat contoh REST API untuk memposting status pada iterasi dan pada permintaan pull.

Kebijakan status

Menggunakan status saja, detail dari layanan eksternal dapat diberikan kepada pengguna dalam pengalaman PR. Terkadang, berbagi informasi tentang PR adalah semua yang diperlukan, tetapi dalam kasus lain PR harus diblokir dari penggabungan sampai persyaratan terpenuhi. Seperti kebijakan dalam kotak, kebijakan Status menyediakan cara bagi layanan eksternal untuk memblokir penyelesaian PR hingga persyaratan terpenuhi. Jika kebijakan diperlukan, kebijakan harus diteruskan untuk menyelesaikan permintaan pull. Jika kebijakan bersifat opsional, kebijakan tersebut hanya bersifat informasi, dan statusnya succeeded tidak diperlukan untuk menyelesaikan permintaan pull.

Kebijakan status dikonfigurasi sama seperti kebijakan cabang lainnya. Saat menambahkan kebijakan status baru, nama dan genre kebijakan status harus dimasukkan. Jika status telah diposting sebelumnya, Anda dapat memilihnya dari daftar; jika ini adalah kebijakan baru, Anda dapat mengetikkan nama kebijakan dalam nama genre/format.

Ketika kebijakan status ditentukan, ini mengharuskan status succeeded dengan context nama yang cocok dengan yang dipilih ada agar kebijakan ini lolos.

Akun resmi juga dapat dipilih untuk mengharuskan akun tertentu memiliki otoritas untuk memposting status yang akan menyetujui kebijakan.

Penerapan kebijakan

Opsi Penerapan kebijakan menentukan apakah kebijakan ini berlaku segera setelah permintaan pull dibuat, atau apakah kebijakan hanya berlaku setelah status pertama diposting ke permintaan pull.

1. Terapkan secara default - Kebijakan berlaku segera setelah permintaan pull dibuat. Dengan opsi ini, kebijakan tidak lulus setelah pembuatan permintaan pull hingga succeeded status diposting. PR dapat ditandai dikecualikan dari kebijakan dengan memposting status notApplicable, yang akan menghapus persyaratan kebijakan.

2. Kondisional - Kebijakan tidak berlaku sampai status pertama diposting ke permintaan pull.

Bersama-sama, opsi ini dapat digunakan untuk membuat serangkaian kebijakan dinamis. Kebijakan "orkestrasi" tingkat atas dapat diatur untuk diterapkan secara default saat PR sedang dievaluasi untuk kebijakan yang berlaku. Kemudian, karena kebijakan bersyarat tambahan ditentukan untuk diterapkan (mungkin berdasarkan output build tertentu), status dapat diposting untuk membuatnya diperlukan. Kebijakan orkestrasi ini dapat ditandai succeeded ketika selesai mengevaluasi atau dapat ditandai notApplicable untuk menunjukkan kepada PR bahwa kebijakan tidak berlaku.

Tindakan kustom

Selain peristiwa hook layanan yang telah ditentukan sebelumnya yang dapat memicu layanan untuk memperbarui status PR, dimungkinkan untuk memperluas menu status dengan menggunakan ekstensi Azure DevOps Services untuk memberikan tindakan pemicu kepada pengguna akhir. Misalnya, jika status sesuai dengan uji coba yang dapat dimulai ulang oleh pengguna akhir, dimungkinkan untuk memiliki item menu Hidupkan Ulang ke menu status yang akan memicu pengujian untuk dijalankan. Untuk menambahkan menu status, Anda harus menggunakan model kontribusi. Untuk informasi selengkapnya, lihat sampel ekstensi Azure DevOps.

Langkah berikutnya

Pelajari selengkapnya tentang PR Status API dan lihat panduan cara:

• Membuat server status permintaan pull dengan Node.js
• Menggunakan Azure Functions untuk membuat kebijakan cabang kustom
• Mengonfigurasi kebijakan cabang bagi layanan eksternal