Pelacakan kerja, proses, dan batas proyek
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Artikel ini menentukan batas operasional dan objek yang ditempatkan pada operasi pelacakan kerja dan kustomisasi pelacakan kerja. Selain batas keras yang ditentukan pada objek tertentu, beberapa batas praktis berlaku. Saat Anda menyesuaikan jenis item kerja (WIT), pertimbangkan batas yang ditempatkan pada objek.
Item dan kueri kerja
Saat Anda menentukan item kerja atau menjalankan kueri, ingatlah batas operasional berikut:
| Objek | Batas |
|---|---|
| Lampiran ditambahkan ke item kerja | 100 |
| Ukuran lampiran | 60 MB |
| Bidang teks panjang | Karakter 1-M |
| Waktu eksekusi kueri | 30 detik |
| Hasil kueri | 20.000 item |
| Panjang kueri | 32.000 karakter |
| Kueri bersama di bawah folder | 999 kueri |
| Tautan item kerja yang ditetapkan ke item kerja | 1,000 |
| Tag item kerja yang ditetapkan ke item kerja | 100 |
| Revisi item kerja (REST API) | 10,000 |
| Kueri favorit per proyek | 200 kueri |
REST API untuk Layanan Azure DevOps memberlakukan batas revisi item kerja 10.000 pembaruan. Batas ini membatasi pembaruan yang dilakukan melalui REST API, tetapi pembaruan dari portal web tidak terpengaruh.
| Objek | Batas |
|---|---|
| Bidang teks panjang | Karakter 1-M |
| Tag item kerja yang ditetapkan ke item kerja | 100 |
| Tautan item kerja yang ditetapkan ke item kerja | 1,000 |
| Lampiran ditambahkan ke item kerja | 100 |
| Ukuran lampiran | 4 MB hingga 2 GB |
| Waktu eksekusi kueri | 6 menit |
| Hasil kueri | 20.000 item |
| Panjang kueri | 32.000 karakter |
| Kueri bersama di bawah folder | 999 kueri |
| Kueri favorit per proyek | 200 kueri |
Ukuran lampiran maksimum default adalah 4 MB. Anda dapat mengubah ukuran maksimum hingga 2 GB.
Untuk meningkatkan performa kueri, lihat Menentukan kueri/Praktik terbaik.
Backlog, papan, dasbor, dan tim
Saat Anda bekerja dengan tim, tag item kerja, backlog, dan papan, tampilan operasional dan batas objek berikut berlaku.
| Antarmuka pengguna | Batas |
|---|---|
| Backlogs | 10.000 item kerja |
| Boards | 1.000 kartu (tidak termasuk kartu tersebut dalam kategori status alur kerja yang Diusulkan dan Selesai) |
| Papan tugas | 1.000 tugas |
| Jalur Area | 10.000 per proyek |
| Kedalaman Jalur Area | 14 |
| Jalur Area per tim | 300 |
| Jalur Perulangan | 10.000 per proyek |
| Kedalaman Jalur Perulangan | 14 |
| Jalur Perulangan per tim | 300 |
| Dasbor Proyek | 500 per proyek. Dapat diakses di tingkat proyek dan siapa pun yang memiliki akses ke proyek dapat menggunakannya. |
| Dasbor Tim | 500 per tim. Khusus untuk tim dan digunakan untuk melacak metrik dan data khusus tim. |
| Teams | 5.000 per proyek |
| Tag item kerja | 150.000 definisi tag per organisasi atau koleksi |
| Paket pengiriman per proyek | 1,000 |
| Templat per jenis item kerja | 100 |
Setiap backlog dapat menampilkan hingga 10.000 item kerja. Batas ini berlaku untuk apa yang dapat ditampilkan backlog, bukan untuk jumlah item kerja yang dapat Anda tentukan, karena tidak ada batas tertentu. Jika backlog Anda melebihi batas ini, pertimbangkan untuk menambahkan tim dan memindahkan beberapa item kerja ke backlog tim baru.
Tip
Jika Anda mendekati batas dasbor, lihat langkah-langkah berikut untuk mengelola dan membersihkan dasbor Anda:
- Tinjau penggunaan: Mengidentifikasi dasbor yang tidak lagi digunakan atau merupakan duplikat. Anda dapat melakukan ini dengan memeriksa tanggal terakhir yang diakses atau dengan berkonsultasi dengan anggota tim.
- Mengonsolidasikan dasbor: Gabungkan dasbor serupa untuk mengurangi jumlah total. Ini dapat dilakukan dengan menambahkan beberapa widget ke satu dasbor.
- Mengarsipkan dasbor lama: Jika dasbor tertentu tidak lagi diperlukan tetapi Anda ingin menyimpan data, pertimbangkan untuk mengekspor data dan mengarsipkan dasbor.
- Gunakan fitur Pelacak Batas Objek: Menyediakan visibilitas real-time ke dalam penggunaan sumber daya, termasuk dasbor. Fitur ini dapat membantu Anda mengelola batas secara proaktif dan menghindari potensi masalah.
Catatan lainnya:
- Item kerja yang selesai atau tertutup tidak ditampilkan di backlog dan papan setelah Tanggal Diubah lebih lama dari setahun. Anda masih bisa mencantumkan item ini menggunakan kueri. Untuk membuatnya muncul di backlog atau papan, buat perubahan kecil untuk mengatur ulang jam tampilan.
- Hindari menumpuk item backlog dengan jenis yang sama. Untuk informasi selengkapnya, lihat Memperbaiki masalah menyusun ulang dan berlapis.
- Hindari menetapkan jalur area yang sama ke lebih dari satu tim. Untuk informasi selengkapnya, lihat Batasan tampilan papan multi-tim.
- Secara default, batas item kerja mungkin diatur ke nilai yang lebih rendah pada awalnya.
Saat Anda bekerja dengan tim, tag item kerja, backlog, dan papan, batas operasional berikut berlaku. Batas default dan maksimum.
| Antarmuka pengguna | Batas |
|---|---|
| Backlogs | 999 item kerja |
| Boards | 400 kartu |
| Dasbor per proyek | 500 |
| Papan tugas | 800 item kerja |
| Teams | 5.000 per proyek |
| Tag item kerja | 150.000 definisi tag per proyek |
| Templat per jenis item kerja | 100 |
Setiap backlog dapat menampilkan hingga 999 item kerja. Jika backlog Anda melebihi batas ini, pertimbangkan untuk membuat tim dan memindahkan beberapa item kerja ke backlog tim baru.
Catatan lainnya:
- Hindari menumpuk item backlog dengan jenis yang sama. Untuk informasi selengkapnya, lihat Memperbaiki masalah menyusun ulang dan berlapis.
- Hindari menetapkan jalur area yang sama ke beberapa tim. Untuk informasi selengkapnya, lihat Batasan tampilan papan multi-tim.
Untuk model proses XML lokal, Anda dapat mengubah batas backlog dan Taskboard dengan mengedit ProcessConfiguration.xml file. Untuk detailnya, lihat Referensi elemen XML konfigurasi proses.
Proyek
Layanan Azure DevOps membatasi setiap organisasi hingga 1.000 proyek per organisasi, peningkatan melebihi batas sebelumnya 300 proyek.
Catatan
Di atas 300 proyek, pengalaman tertentu, seperti menyambungkan ke proyek dari Visual Studio, mungkin mengalami penurunan. Untuk Azure DevOps Server lokal, tidak ada batasan keras, tetapi masalah performa mungkin muncul karena jumlah proyek mendekati 300. Saat bermigrasi ke Azure DevOps Services, amati batas maksimum 1.000 proyek. Jika koleksi Anda melebihi batas ini, pisahkan koleksi atau hapus proyek lama.
Untuk informasi selengkapnya, lihat Memigrasikan data dari Azure DevOps Server ke Azure DevOps Services.
Kustomisasi proses
Banyak batasan yang diberlakukan pada jumlah objek yang dapat Anda tentukan untuk proses. Untuk informasi selengkapnya, lihat Menyesuaikan pengalaman pelacakan kerja Anda.
Tabel berikut mencantumkan jumlah maksimum objek yang dapat Anda tentukan untuk model proses Warisan dan XML yang Dihosting. Meskipun batas ini adalah batas keras, batas praktis mungkin juga berlaku.
| Objek | Warisan | XML yang dihosting |
|---|---|---|
| Jumlah proses yang dapat Anda miliki di organisasi | 128 | 64 |
| Jenis item kerja yang ditentukan untuk proses | 64 | 64 |
| Bidang yang ditentukan untuk organisasi | 8192 | 8192 |
| Bidang yang ditentukan untuk proses | 1024 | 1024 |
| Bidang yang ditentukan untuk jenis item kerja | 1024 | 1024 |
| Daftar pilihan yang ditentukan untuk organisasi atau koleksi | 2048 | - |
| Item daftar pilihan yang ditentukan untuk daftar | 2048 | 2048 |
| Panjang karakter item daftar pilihan | 256 | - |
| Status alur kerja ditentukan untuk tipe item kerja | 32 | 16 |
| Aturan yang ditentukan untuk jenis item kerja | 1024 | 1024 |
| Tindakan yang ditentukan untuk jenis item kerja | 1024 | 1024 |
| Tindakan yang ditentukan untuk aturan | 10 | 10 |
| Tingkat backlog portofolio yang ditentukan untuk sebuah proses | 5 | 5 |
| Kategori yang ditentukan untuk proses | - | 32 |
| Daftar global yang ditentukan untuk proses | - | 256 |
| Mencantumkan item yang ditentukan dalam daftar global | - | 1024 |
| Ukuran lampiran item kerja | 60 MB | 60 MB |
Untuk batasan dan persyaratan kesesuaian model proses XML yang dihosting, lihat Mengkustomisasi proses saat menggunakan XML yang Dihosting.
Catatan
Untuk model proses XML yang dihosting, Anda dapat menentukan sekitar 10.000 item di semua daftar global yang ditentukan di semua ASET.
Tabel berikut mencantumkan jumlah maksimum objek yang bisa Anda tentukan untuk model proses Warisan dan XML lokal. Meskipun batas ini adalah batas keras, batas praktis mungkin juga berlaku.
| Objek | Warisan | XML lokal |
|---|---|---|
| Jumlah proses yang dapat Anda miliki di organisasi | 64 | 64 |
| Jenis item kerja yang ditentukan untuk proses | 64 | 64 |
| Bidang yang ditentukan untuk koleksi | 8192 | 1024 |
| Bidang yang ditentukan untuk proses | 1024 | 1024 |
| Bidang yang ditentukan untuk jenis item kerja | 1024 | 1024 |
| Daftar pilihan yang ditentukan untuk koleksi | 1024 | T/A |
| Item daftar pilihan yang ditentukan untuk daftar | 2048 | 2048 |
| Panjang karakter item daftar pilihan | 256 | T/A |
| Status alur kerja ditentukan untuk tipe item kerja | 32 | 16 |
| Aturan yang ditentukan untuk jenis item kerja | 1024 | 1024 |
| Tingkat backlog portofolio yang ditentukan untuk sebuah proses | 5 | 5 |
| Kategori yang ditentukan untuk proses | T/A | 32 |
| Daftar global yang ditentukan untuk proses | T/A | 256 |
| Mencantumkan item yang ditentukan dalam daftar global | T/A | 1024 |
Catatan
Untuk model proses XML lokal, Anda dapat menentukan perkiraan total item 10K untuk semua daftar global yang ditentukan di semua ASET.
Batas praktis
Untuk meminimalkan masalah performa, sebaiknya ikuti panduan ini:
- Batasi jumlah bidang kustom yang Anda tentukan. Semua bidang kustom berkontribusi pada total yang diizinkan untuk proses, koleksi, atau organisasi. Anda dapat menentukan perilaku yang berbeda, seperti aturan dan daftar pilih, untuk bidang yang sama di WIT yang berbeda.
- Batasi jumlah aturan yang Anda tentukan untuk WIT. Meskipun Anda dapat membuat beberapa aturan untuk WIT, aturan lain dapat berdampak negatif pada performa saat pengguna menambahkan atau memodifikasi item kerja. Saat pengguna menyimpan item kerja, sistem memvalidasi semua aturan yang terkait dengan bidang untuk jenis item kerja tersebut. Dalam beberapa kasus, ekspresi validasi aturan mungkin terlalu kompleks bagi SQL untuk dievaluasi secara efisien.
- Batasi jumlah WIT kustom yang Anda tentukan.
- Batasi jumlah bidang kustom yang Anda tentukan. Semua bidang kustom berkontribusi pada total yang diizinkan untuk proses, koleksi, atau organisasi. Anda dapat menentukan perilaku yang berbeda, seperti aturan dan daftar pilih, untuk bidang yang sama di WIT yang berbeda.
- Batasi jumlah aturan yang Anda tentukan untuk WIT. Meskipun Anda dapat membuat beberapa aturan untuk WIT, aturan lain dapat berdampak negatif pada performa saat pengguna menambahkan atau memodifikasi item kerja. Saat pengguna menyimpan item kerja, sistem memvalidasi semua aturan yang terkait dengan bidang untuk jenis item kerja tersebut. Dalam beberapa kasus, ekspresi validasi aturan mungkin terlalu kompleks bagi SQL untuk dievaluasi secara efisien.
- Batasi jumlah WIT kustom yang Anda tentukan.
- Batasi jumlah bidang yang dapat dilaporkan yang Anda tentukan. Bidang yang dapat dilaporkan dapat memengaruhi performa gudang data Anda.
Catatan
Validasi Aturan Item Kerja Melebihi Batas SQL: Ekspresi SQL tunggal ditentukan per proyek untuk memvalidasi item kerja setiap kali dibuat atau diperbarui. Ekspresi ini bertambah dengan jumlah aturan yang ditentukan untuk semua jenis item kerja dalam proyek. Setiap kualifikasi perilaku untuk bidang meningkatkan jumlah sub-ekspresi. Aturan berlapis, aturan yang hanya berlaku pada transisi, atau aturan yang dikondisikan pada nilai bidang lain menambahkan lebih banyak kondisi ke pernyataan IF. Setelah ekspresi mencapai ukuran atau kompleksitas tertentu, SQL tidak dapat lagi mengevaluasinya dan menghasilkan kesalahan. Untuk mengatasi kesalahan ini, hapus beberapa WIT atau hilangkan beberapa aturan.
Batas tarif
Untuk mengurangi biaya dan meningkatkan skalabilitas dan performa, Azure DevOps Services, seperti banyak solusi Software-as-a-Service, menggunakan multi-penyewaan. Untuk memastikan performa yang baik dan meminimalkan risiko pemadaman, Azure DevOps Services membatasi sumber daya yang dapat dikonsumsi individu dan jumlah permintaan yang dapat mereka buat ke perintah tertentu. Ketika batas ini terlampaui, permintaan berikutnya mungkin tertunda atau diblokir.
Sebagian besar batas tarif dicapai melalui panggilan REST API atau kueri yang tidak optimal. Untuk informasi selengkapnya, lihat Batas tarif dan Praktik terbaik (untuk menghindari mencapai batas laju).
Batas migrasi dan impor
Saat bermigrasi dari lokal ke Azure DevOps Services, Anda mungkin mengalami beberapa batas ukuran, termasuk:
- Ukuran database melebihi ukuran yang direkomendasikan
- Ukuran tabel terbesar melebihi ukuran yang direkomendasikan
- Ukuran metadata database melebihi ukuran yang didukung
Untuk informasi selengkapnya, lihat Memigrasikan data dari Azure DevOps Server ke Azure DevOps Services dan Memecahkan masalah kesalahan impor dan migrasi.