Bagikan melalui

Kebijakan dan pengaturan cabang

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Kebijakan cabang membantu tim melindungi cabang penting pengembangan mereka. Kebijakan menegakkan standar kualitas kode dan manajemen perubahan tim Anda. Artikel ini menjelaskan cara mengatur dan mengelola kebijakan cabang. Untuk gambaran umum semua kebijakan dan pengaturan repositori dan cabang, lihat Pengaturan dan kebijakan repositori Git.

Cabang dengan kebijakan yang telah dikonfigurasi tidak dapat dihapus dan memerlukan permintaan tarik (PR) untuk semua perubahan.

Prasyarat

  • Untuk menetapkan kebijakan cabang, menjadi anggota grup keamanan Administrator Proyek atau memiliki izin kebijakan Edit tingkat repositori. Untuk informasi selengkapnya, lihat Mengatur izin repositori Git.

Konfigurasi peraturan cabang

Untuk mengelola kebijakan cabang, pilih Repos>Cabang untuk membuka halaman Cabang di portal web.

Cuplikan layar yang menampilkan item menu Cabang.

Anda juga dapat masuk ke pengaturan kebijakan cabang dengan Pengaturan Proyek>Repositori>Kebijakan>Kebijakan Cabang><Nama Cabang>.

Cabang yang memiliki kebijakan menampilkan ikon kebijakan. Anda dapat memilih ikon untuk langsung masuk ke pengaturan kebijakan cabang.

Untuk mengatur kebijakan cabang, temukan cabang yang ingin Anda kelola. Anda dapat menelusuri daftar atau mencari cabang Anda di kotak Nama cabang pencarian di kanan atas.

Pilih ikon Opsi lainnya di samping cabang, lalu pilih Kebijakan cabang dari menu konteks.

Cuplikan layar yang memperlihatkan Buka kebijakan cabang dari menu konteks.

Konfigurasikan kebijakan pada halaman pengaturan cabang. Lihat bagian berikut untuk deskripsi dan instruksi untuk setiap jenis kebijakan.

Memerlukan jumlah minimum peninjau

Tinjauan kode penting untuk proyek pengembangan perangkat lunak. Untuk memastikan bahwa tim meninjau dan menyetujui PR, Anda dapat memerlukan persetujuan dari jumlah peninjau minimum. Kebijakan dasar mengharuskan sejumlah peninjau tertentu menyetujui kode, tanpa penolakan.

Untuk mengatur kebijakan, di bawah Kebijakan Cabang, atur Memerlukan jumlah minimum peninjau ke Aktif. Masukkan jumlah peninjau yang diperlukan, dan pilih salah satu opsi berikut:

Cuplikan layar yang memperlihatkan kebijakan Memerlukan Tinjauan Kode diaktifkan.

  • Pilih Izinkan pemohon menyetujui perubahan mereka sendiri untuk memungkinkan pembuat PR memberikan suara untuk persetujuannya. Namun, pembuat masih dapat memilih Setujui pada PR, tetapi suara pembuat tidak diperhitungkan dalam jumlah minimum peninjau.

  • Pilih Larang pendorong terbaru untuk menyetujui perubahannya sendiri guna menerapkan pemisahan tugas. Secara default, siapa pun dengan izin push pada cabang sumber dapat menambahkan komit dan memberikan persetujuan pada PR. Memilih opsi ini berarti suara pengusul terbaru tidak dihitung, bahkan jika mereka biasanya dapat menyetujui perubahan mereka sendiri.

  • Pilih Izinkan penyelesaian meskipun beberapa peninjau memilih untuk menunggu atau menolak untuk mengizinkan penyelesaian PR meskipun beberapa peninjau memilih menolak persetujuan. Jumlah minimum peninjau masih harus memberikan persetujuan.

  • Di bawah Saat perubahan baru didorong:
    • Pilih Perlu setidaknya satu persetujuan pada setiap perulangan untuk memerlukan setidaknya satu suara persetujuan untuk perubahan cabang sumber terakhir. Persetujuan pengguna tidak dihitung terhadap perulangan yang tidak disetujui sebelumnya yang didorong oleh pengguna tersebut. Akibatnya, persetujuan lain pada iterasi terakhir diperlukan untuk dilakukan oleh pengguna lain. Memerlukan setidaknya satu persetujuan pada setiap iterasi tersedia di Azure DevOps Server 2022.1 dan yang lebih tinggi.
    • Pilih Perlu setidaknya satu persetujuan pada iterasi terakhir untuk memerlukan setidaknya satu suara persetujuan untuk perubahan cabang sumber terakhir.
    • Pilih Reset semua suara persetujuan (tidak mengatur ulang suara untuk menolak atau menunggu) untuk menghapus semua suara persetujuan, tetapi pertahankan suara untuk menolak atau menunggu, setiap kali cabang sumber berubah.
    • Pilih Reset semua suara peninjau kode untuk menghapus semua suara peninjau kode setiap kali cabang sumber berubah, termasuk suara untuk menyetujui, menolak, atau menunggu.

Jika semua kebijakan lainnya disetujui, pencipta dapat menyelesaikan PR ketika jumlah peninjau yang diperlukan telah menyetujuinya.

Periksa item kerja tertaut

Untuk pelacakan manajemen item kerja, Anda dapat memerlukan asosiasi antara PR dan item kerja. Menautkan item kerja menyediakan lebih banyak konteks untuk perubahan, dan memastikan bahwa pembaruan melewati proses pelacakan item kerja Anda.

Untuk mengatur kebijakan, di bawah Kebijakan Cabang, atur Periksa item kerja yang tertaut ke Aktif. Pengaturan ini mengharuskan item kerja ditautkan ke PR sebelum PR dapat digabungkan. Buat pengaturan Opsional untuk memperingatkan ketika tidak ada item kerja tertaut, tetapi izinkan penyelesaian permintaan pull.

Cuplikan layar yang memerlukan item kerja tertaut dalam permintaan pull.

Periksa penyelesaian komentar

Kebijakan Memeriksa penyelesaian komentar memastikan bahwa semua komentar PR telah diselesaikan.

Konfigurasikan kebijakan resolusi komentar untuk cabang Anda dengan mengatur Periksa resolusi komentar ke Aktif. Kemudian pilih apakah akan membuat kebijakan Diperlukan atau Opsional.

Cuplikan layar Periksa resolusi komentar.

Untuk informasi selengkapnya tentang bekerja dengan komentar pada pull request, lihat Tinjau pull request.

Batasi jenis penggabungan

Azure Repos memiliki beberapa strategi penggabungan, dan secara default, semuanya diizinkan. Anda dapat mempertahankan riwayat cabang yang konsisten dengan memberlakukan strategi penggabungan untuk penyelesaian PR.

Atur Batasi jenis penggabungan ke Aktif untuk membatasi jenis penggabungan mana yang akan diizinkan dalam repositori Anda.

Cuplikan layar Batasi jenis penggabungan.

  • Penggabungan dasar (tanpa fast-forward) membuat commit penggabungan di target yang memiliki induk berupa cabang target dan cabang sumber.
  • Penggabungan squash membuat riwayat linier dengan satu komit di cabang target dengan perubahan dari cabang sumber. Pelajari selengkapnya tentang penggabungan squash dan pengaruhnya terhadap riwayat cabang.
  • Rebase dan fast-forward membuat riwayat linier dengan memutar ulang commit dari sumber ke cabang target tanpa commit penggabungan.
  • Rebase dengan commit penggabungan memutar ulang commit sumber ke target dan juga membuat commit penggabungan.

Membuat validasi

Anda dapat mengatur kebijakan yang mengharuskan perubahan PR berhasil dibangun sebelum PR dapat diselesaikan. Kebijakan pembangunan mengurangi gangguan dan menjaga hasil pengujian Anda tetap berhasil. Kebijakan build membantu meskipun Anda menggunakan Continuous Integration (CI) di cabang pengembangan Anda untuk mengidentifikasi masalah sebelumnya.

Kebijakan validasi build mengantrekan build baru saat PR baru dibuat atau perubahan didorong ke PR yang ada yang menargetkan cabang. Kebijakan build mengevaluasi hasil build untuk menentukan apakah PR dapat diselesaikan.

Penting

Sebelum menetapkan kebijakan validasi build, setel dahulu alur build. Jika Anda tidak memiliki alur, lihat Membuat alur build. Pilih jenis build yang cocok dengan jenis proyek Anda.

Untuk menambahkan kebijakan validasi penyusunan

  1. Pilih tombol + di sebelah Validasi build.

    Cuplikan layar yang memperlihatkan tombol Tambahkan di samping Validasi build.

  2. Isi formulir Tetapkan kebijakan build:

    Cuplikan layar pengaturan kebijakan build.

    • Pilih Build pipeline.

    • Atur filter jalur secara opsional. Pelajari selengkapnya tentang filter jalur dalam kebijakan cabang.

    • Di bawah Pemicu, pilih Otomatis (setiap kali cabang sumber diperbarui) atau Manual.

    • Di bawah Persyaratan kebijakan, pilih Diperlukan atau Opsional. Jika Anda memilih Diperlukan, build harus berhasil diselesaikan untuk menyelesaikan PR. Pilih Opsional untuk memberikan pemberitahuan kegagalan build tetapi tetap memungkinkan penyelesaian PR.

    • Atur kedaluwarsa pembentukan untuk memastikan pembaruan ke cabang Anda yang dilindungi tidak mengganggu perubahan pada PR yang terbuka.

      • Segera ketika <nama> cabang diperbarui: Opsi ini mengatur status kebijakan build PR menjadi gagal setiap kali cabang diperbarui, dan mengulang antrean build. Pengaturan ini memastikan bahwa perubahan PR berhasil dikompilasi meskipun cabang yang dilindungi mengalami perubahan.

        Opsi ini terbaik untuk tim yang cabang pentingnya memiliki sedikit perubahan. Tim yang bekerja di cabang pengembangan yang sibuk mungkin merasa terganggu harus menunggu build setiap kali cabang tersebut diperbarui.

      • Setelah <n> jam jika <nama> cabang telah diperbarui: Opsi ini akan mengakhiri status kebijakan saat ini ketika cabang yang dilindungi diperbarui, jika build yang berhasil lebih lama dari ambang batas yang Anda masukkan. Opsi ini merupakan kompromi antara selalu memerlukan build atau tidak pernah memerlukannya ketika cabang dilindungi diperbarui. Pilihan ini mengurangi jumlah build saat cabang anda yang dilindungi memiliki pembaruan yang sering.

      • Tidak Pernah: Pembaruan pada cabang yang dilindungi tidak mengubah status kebijakan. Nilai ini mengurangi jumlah build, tetapi dapat menyebabkan masalah saat menyelesaikan PR yang tidak diperbarui baru-baru ini.

    • Masukkan Nama tampilan opsional untuk kebijakan build ini. Nama ini mengidentifikasi kebijakan pada halaman Kebijakan cabang. Jika Anda tidak menentukan nama tampilan, kebijakan menggunakan nama alur build.

  3. Pilih Simpan.

Ketika pemilik PR mendorong perubahan yang berhasil dibangun, status kebijakan diperbarui.

Jika Anda memiliki kebijakan build Segera setelah <nama cabang> diperbarui atau Setelah <n> jam jika <nama cabang> diperbarui, status kebijakan akan diperbarui saat cabang yang dilindungi diperbarui, jika build sebelumnya tidak lagi valid.

Pengecekan status

Layanan eksternal dapat menggunakan PR Status API untuk memposting status terperinci ke PR Anda. Kebijakan cabang untuk layanan tambahan memungkinkan layanan eksternal tersebut untuk berpartisipasi dalam alur kerja PR dan menetapkan persyaratan kebijakan.

Cuplikan layar Memerlukan layanan eksternal untuk disetujui.

Untuk petunjuk tentang mengonfigurasi kebijakan ini, lihat Mengonfigurasi kebijakan cabang untuk layanan eksternal.

Secara otomatis menyertakan peninjau kode

Anda dapat secara otomatis menambahkan peninjau ke pull request yang mengubah file di direktori atau file tertentu, atau ke semua pull request dalam repo.

  1. Pilih tombol + di samping Peninjau yang Secara Otomatis Disertakan.

    Cuplikan layar yang memperlihatkan Tambahkan peninjau yang diperlukan.

  2. Isi layar Tambahkan kebijakan peninjau baru.

    Cuplikan layar yang memperlihatkan layar Tambahkan kebijakan peninjau baru.

    • Tambahkan orang dan grup ke Peninjau.

    • Pilih Opsional jika Anda ingin menambahkan peninjau secara otomatis, tetapi tidak memerlukan persetujuan mereka untuk menyelesaikan permintaan pull.

      Atau, pilih Diperlukan jika permintaan pull tidak dapat diselesaikan hingga:

      • Setiap individu ditambahkan sebagai peninjau menyetujui perubahan.
      • Setidaknya satu orang di setiap grup yang ditambahkan sebagai peninjau menyetujui perubahan.
      • Jika hanya satu grup yang diperlukan, jumlah minimum anggota yang Anda tentukan menyetujui perubahan.

    • Tentukan file dan folder yang memerlukan peninjau yang disertakan secara otomatis. Biarkan bidang ini kosong untuk mengharuskan peninjau untuk semua permintaan pull di cabang.

    • Pilih Izinkan pemohon untuk menyetujui perubahan mereka sendiri jika pemilik permintaan pull dapat memilih untuk menyetujui permintaan pull mereka sendiri untuk memenuhi kebijakan ini.

    • Anda dapat menentukan pesan Umpan aktivitas yang muncul di permintaan penarikan.

  3. Pilih Simpan.

Mengecualikan kebijakan cabang

Dalam beberapa kasus, Anda mungkin perlu melewati persyaratan kebijakan. Izin bypass memungkinkan Anda mendorong perubahan ke cabang secara langsung, atau menyelesaikan permintaan pull yang tidak memenuhi kebijakan cabang. Anda dapat memberikan izin bypass kepada pengguna atau grup. Anda dapat mengatur izin bypass untuk seluruh proyek, repositori, atau satu cabang.

Dua izin memungkinkan pengguna untuk melewati kebijakan cabang dengan cara yang berbeda:

  • Melewati kebijakan saat menyelesaikan permintaan pull hanya berlaku untuk penyelesaian permintaan pull. Pengguna dengan izin ini dapat menyelesaikan permintaan pull meskipun permintaan pull tidak memenuhi kebijakan.

  • Melewati kebijakan ketika push berlaku untuk push pada repositori lokal dan pengeditan di web. Pengguna dengan izin ini dapat mendorong perubahan langsung ke cabang yang dilindungi tanpa memenuhi persyaratan kebijakan.

Cuplikan layar yang menunjukkan izin untuk melewati penegakan kebijakan.

Untuk informasi selengkapnya tentang mengelola izin ini, lihat Izin Git.

Penting

Berhati-hatilah saat memberikan kemampuan untuk melewati kebijakan, terutama di tingkat repositori dan proyek. Kebijakan adalah landasan manajemen kode sumber yang aman dan sesuai.

Filter jalur

Beberapa kebijakan cabang menyediakan filter jalur. Jika filter jalur diatur, kebijakan hanya berlaku untuk file yang cocok dengan filter jalur. Membiarkan bidang ini kosong berarti bahwa kebijakan berlaku untuk semua file di cabang.

Anda dapat menentukan jalur absolut (jalur harus dimulai dengan / atau karakter pengganti) dan karakter pengganti. Contoh:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Anda dapat menentukan beberapa jalur menggunakan ; sebagai pemisah. Contoh:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Jalur yang diawali dengan ! dikecualikan jika seharusnya disertakan. Contoh:

  • /WebApp/*;!/WebApp/Tests/* menyertakan semua file dalam /WebApp kecuali file di /WebApp/Tests
  • !/WebApp/Tests/* menentukan tidak ada file, karena tidak ada yang disertakan terlebih dahulu

Urutan filter signifikan. Filter diterapkan kiri-ke-kanan.

T&J

Dapatkah saya mendorong perubahan langsung ke cabang yang memiliki kebijakan cabang?

Anda tidak dapat menerapkan perubahan secara langsung pada cabang dengan kebijakan cabang yang wajib kecuali Anda memiliki izin untuk melewati kebijakan cabang. Perubahan pada cabang ini hanya dapat dilakukan melalui pull request. Anda dapat mendorong perubahan langsung ke cabang yang memiliki kebijakan cabang opsional , jika mereka tidak memiliki kebijakan cabang yang diperlukan.

Apa itu pelengkapan otomatis?

Permintaan tarik ke cabang dengan kebijakan cabang yang sudah dikonfigurasi memiliki tombol Atur penyelesaian otomatis. Pilih opsi ini untuk menyelesaikan permintaan pull secara otomatis setelah memenuhi semua kebijakan. Pelengkapan otomatis berguna saat Anda tidak menduga akan ada masalah dengan perubahan.

Kapan dilakukan pemeriksaan terhadap kondisi kebijakan cabang?

Kebijakan cabang dievaluasi ulang di server ketika pemilik permintaan tarik melakukan perubahan dan ketika peninjau memberikan suara. Jika kebijakan memicu build, status build diatur untuk menunggu hingga build selesai.

Dapatkah saya menggunakan definisi build XAML dalam kebijakan cabang?

Tidak, Anda tidak dapat menggunakan definisi build XAML dalam kebijakan cabang.

Karakter wildcard apa yang dapat saya gunakan untuk peninjau kode yang diwajibkan?

Tanda bintang tunggal * dapat mencocokkan sejumlah karakter apa pun, termasuk garis miring ke depan / dan garis miring ke belakang \. Tanda tanya ? cocok dengan satu karakter apa pun.

Contoh:

  • *.sql mencocokkan semua file dengan ekstensi .sql .
  • /ConsoleApplication/* cocok dengan semua file di bawah folder bernama ConsoleApplication.
  • /.gitattributes cocok dengan file.gitattributes* di akar repositori.
  • */.gitignoremencocokkan semua file .gitignore di repositori.

Apakah jalur peninjau kode yang diperlukan peka terhadap huruf besar atau kecil?

Tidak, kebijakan cabang tidak sensitif terhadap huruf besar/kecil.

Bagaimana cara mengonfigurasi beberapa pengguna sebagai peninjau yang diperlukan, tetapi hanya memerlukan salah satu dari mereka untuk menyetujui?

Anda dapat menambahkan pengguna ke grup, lalu menambahkan grup sebagai peninjau. Setiap anggota grup kemudian dapat menyetujui untuk memenuhi persyaratan kebijakan.

Saya memiliki izin untuk mengabaikan kebijakan. Mengapa saya masih melihat kegagalan kebijakan dalam status pull request?

Kebijakan yang telah dikonfigurasi selalu dievaluasi untuk perubahan pada pull request. Untuk pengguna yang memiliki izin untuk melewati kebijakan, status kebijakan yang dilaporkan bersifat saran. Jika pengguna dengan izin bypass menyetujui, status kegagalan tidak memblokir penyelesaian permintaan pull.

Mengapa saya tidak dapat melakukan permintaan pull saya sendiri saat "Izinkan pemohon menyetujui perubahan mereka sendiri diaktifkan"?

Kebijakan Memerlukan Minimum Jumlah Peninjau dan Kebijakan Peninjau yang Disertakan Secara Otomatis memiliki opsi untuk Mengizinkan Pemohon Menyetujui Perubahan Mereka Sendiri. Dalam setiap kebijakan, pengaturan hanya berlaku untuk kebijakan tersebut. Pengaturan tidak memengaruhi kebijakan lain.

Misalnya, permintaan pull Anda memiliki kebijakan berikut yang ditetapkan:

  • Memerlukan jumlah minimum peninjau memerlukan setidaknya satu peninjau.
  • Peninjau yang disertakan secara otomatis memerlukan Anda atau tim Anda sebagai peninjau.
  • Peninjau yang disertakan secara otomatis memiliki fitur Izinkan pemohon menyetujui perubahan mereka sendiri yang diaktifkan.
  • Memerlukan jumlah minimum peninjau tidak mengaktifkan Izinkan pemohon untuk menyetujui perubahan mereka sendiri.

Dalam hal ini, persetujuan Anda memenuhi Peninjau yang ditambahkan secara otomatis, tetapi tidak memenuhi Persyaratan jumlah minimum peninjau, sehingga Anda tidak dapat menyelesaikan permintaan penarikan.

Mungkin juga ada kebijakan lain, seperti Melarang pendorong terbaru menyetujui perubahan mereka sendiri, yang mencegah Anda menyetujui perubahan Anda sendiri bahkan jika Izinkan pemohon untuk menyetujui perubahan mereka sendiri diaktifkan.

Apa yang terjadi ketika jalur pada filter tidak dimulai dengan / atau dengan karakter pengganti?

Jalur dalam filter jalur yang tidak dimulai dengan / atau dengan karakter pengganti tidak memiliki efek, dan filter jalur mengevaluasi seolah-olah jalur tersebut tidak ditentukan. Jalur seperti itu tidak dapat mencocokkan jalur file absolut yang dimulai dengan /.

  • Last updated on