Merencanakan struktur organisasi Anda

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

Gunakan struktur bisnis Anda sebagai panduan untuk jumlah organisasi, proyek, dan tim yang Anda buat di Azure DevOps. Panduan perencanaan komprehensif ini membantu Anda merancang struktur organisasi optimal yang menyelaraskan alur kerja pengembangan dengan tujuan bisnis.

Tips

Anda dapat menggunakan AI untuk membantu tugas ini nanti di artikel ini, atau lihat Mengaktifkan bantuan AI dengan Azure DevOps MCP Server untuk memulai.

Kerangka kerja perencanaan strategis

Gunakan kerangka kerja berikut untuk membuat keputusan utama tentang struktur Azure DevOps Anda di setiap tingkat — organisasi, proyek, tim, dan repositori.

Keputusan struktur utama

Atasi pertanyaan mendasar ini untuk memandu struktur Azure DevOps Anda:

Tingkat organisasi:

Tingkat proyek:

Tingkat tim dan repositori:

Pertimbangan pendukung

  • Manajemen akses: Tentukan siapa yang membutuhkan akses ke informasi dan sumber daya apa.
  • Persyaratan pelaporan: Rencanakan visibilitas lintas tim dan manajemen portofolio.
  • Standardisasi proses: Mempromosikan praktik yang konsisten sambil memungkinkan fleksibilitas tim.
  • Keselarasan budaya: Menumbuhkan pola pikir yang tangkas dan budaya kolaboratif.

Tips

Mulailah dengan struktur yang lebih sederhana dan berkembang seiring pertumbuhan organisasi Anda. Lebih mudah untuk membagi proyek besar daripada menggabungkan organisasi terpisah.

Memahami organisasi Azure DevOps

Organisasi di Azure DevOps berfungsi sebagai kontainer tingkat atas untuk proyek Anda, menyediakan batas penagihan, keamanan, dan administratif. Dengan menggunakan organisasi, Anda dapat:

  • Memusatkan penagihan dan lisensi di seluruh proyek dan tim terkait.
  • Tetapkan batas keamanan dengan kontrol dan kebijakan akses yang berbeda.
  • Berikan isolasi administratif untuk unit bisnis atau persyaratan kepatuhan yang berbeda.
  • Sambungkan ke penyedia identitas seperti ID Microsoft Entra untuk autentikasi terpadu.

Manfaat organisasi dan tingkat gratis

Setiap organisasi menyertakan layanan tingkatan gratis untuk hingga lima pengguna.

Pelayanan Manfaat Tingkat Gratis
Azure Pipeline Satu pekerjaan yang dihost dengan 1.800 menit per bulan untuk CI/CD ditambah satu pekerjaan yang dikelola sendiri
Papan Azure Pelacakan item kerja dan papan Kanban untuk manajemen proyek
Azure Repos Repositori Git privat tanpa batas untuk kontrol sumber
Azure Artefak Manajemen paket untuk dependensi dan hasil build artefak
Akses pemangku kepentingan Pemangku kepentingan tanpa batas untuk melihat dan partisipasi proyek dasar
  • Lima pengguna pertama gratis (Lisensi dasar)
  • Azure Pipelines:
    • Satu CI/CD yang dihosting Microsoft (satu pekerjaan bersamaan, hingga 30 jam per bulan)
    • Satu tugas bersamaan CI/CD yang di-host sendiri
  • Azure Boards: Pelacakan dan papan item kerja
  • Azure Repos: Repositori Git privat tanpa batas
  • Azure Artifacts: Dua GiB gratis per organisasi

Catatan

Layanan pengujian beban berbasis cloud Azure DevOps sudah dihentikan, tetapi Azure Load Testing tetap tersedia. Layanan pengujian beban yang dikelola sepenuhnya ini memungkinkan Anda menghasilkan beban skala tinggi menggunakan skrip Apache JMeter yang ada. Untuk informasi selengkapnya, lihat Apa itu Azure Load Testing? dan Perubahan pada fungsionalitas pengujian beban di Visual Studio dan pengujian beban cloud di Azure DevOps.

Pola organisasi umum:

  • Organisasi tunggal: Gunakan satu organisasi untuk kolaborasi terpadu.
  • Organisasi unit bisnis: Gunakan organisasi terpisah untuk persyaratan kepatuhan atau keamanan yang berbeda.
  • Organisasi geografis: Gunakan pemisahan regional untuk residensi data atau tata kelola lokal.

Berapa banyak organisasi yang Anda butuhkan?

Mulailah dengan satu organisasi dan perluas hanya ketika Anda memiliki persyaratan bisnis tertentu yang menuntut pemisahan.

Kriteria keputusan untuk beberapa organisasi

Buat lebih banyak organisasi saat Anda membutuhkan:

Pemisahan keamanan dan kepatuhan:

  • Persyaratan peraturan yang berbeda, seperti SOX, HIPAA, atau PCI-DSS
  • Persyaratan isolasi data pelanggan yang berbeda
  • Memisahkan jejak audit dan pelaporan kepatuhan

Persyaratan struktur bisnis:

  • Unit bisnis independen dengan tata kelola IT terpisah
  • Persyaratan penagihan dan pusat biaya yang berbeda
  • Koneksi yang berbeda dari penyedia identitas, seperti tenant Microsoft Entra yang berbeda.

Batas administratif:

  • Grup administrator yang berbeda tanpa tumpang tindih
  • Memisahkan kebijakan dan kontrol organisasi
  • Perjanjian tingkat layanan independen

Kerangka evaluasi

Faktor Organisasi Tunggal Beberapa Organisasi
Kolaborasi Visibilitas dan berbagi maksimum Berbagi terbatas dan terisolasi antar organisasi
Administrasi Manajemen terpusat dan lebih sederhana Overhead terdistribusi dan lebih administratif
Pelaporan Dasbor dan analitik terpadu Sistem pelaporan terpisah
Cost Entitas penagihan tunggal Beberapa entitas penagihan
Keamanan Batas bersama, kebijakan terpadu Batas keras, kebijakan independen

Penting

Untuk organisasi Microsoft Entra milik perusahaan, pertimbangkan untuk membatasi pembuatan organisasi untuk melindungi kekayaan intelektual dan mempertahankan tata kelola.

Apa itu tim?

Tim adalah unit yang mendukung banyak alat yang dapat dikonfigurasi tim. Alat-alat ini membantu Anda merencanakan dan mengelola pekerjaan, dan mempermudah kolaborasi.

Membuat tim untuk setiap tim produk atau fitur yang berbeda

Setiap tim memiliki backlog sendiri. Untuk membuat backlog baru, Anda membuat tim baru. Konfigurasikan tim dan backlog ke dalam struktur hierarkis, sehingga pemilik program dapat lebih mudah melacak kemajuan di seluruh tim, mengelola portofolio, dan menghasilkan data rollup. Saat membuat tim, Anda juga membuat grup tim. Anda dapat menggunakan grup ini dalam kueri atau untuk mengatur izin untuk tim Anda.

Memahami proyek

Proyek menyediakan kontainer untuk pekerjaan pengembangan Anda, yang berisi layanan terintegrasi ini:

  • Azure Boards: Perencanaan tangkas dengan backlog, sprint, dan pelacakan item kerja.
  • Azure Pipelines: Integrasi berkelanjutan dan otomatisasi penyebaran.
  • Azure Repos: Repositori Git atau TFVC untuk manajemen kode sumber.
  • Paket Pengujian Azure: Integrasi pengujian manual dan otomatis.
  • Sumber daya bersama: Wiki, dasbor, dan pengaturan tingkat proyek.

Dalam contoh berikut, Contoso Manufacturing menggunakan empat proyek untuk mengatur lini produk yang berbeda:

Diagram organisasi dengan empat proyek.

Manfaat dan pertimbangan proyek

Proyek memungkinkan:

  • Jadwal iterasi dan taksonomi yang dibagikan antar tim.
  • Templat proses yang konsisten dan jenis item kerja.
  • Pelaporan terintegrasi dan manajemen portofolio.
  • Manajemen pengguna dan kontrol akses yang disederhanakan.

Proyek menyediakan batasan untuk:

  • Izin keamanan dan akses.
  • Kustomisasi proses dan pelacakan kerja.
  • Kebijakan dan tata kelola administratif.
  • Alokasi sumber daya dan pelacakan penagihan.

Berapa banyak proyek yang Anda butuhkan?

Memiliki setidaknya satu proyek untuk mulai menggunakan layanan Azure DevOps, seperti Azure Boards, Azure Repos, atau Azure Pipelines. Saat membuat organisasi, Anda membuat proyek default untuk diri Anda sendiri. Dalam proyek default Anda, ada repositori kode untuk mulai bekerja, backlog untuk melacak pekerjaan, dan setidaknya satu alur untuk mulai mengotomatiskan build dan rilis.

Dalam organisasi, Anda dapat menggunakan salah satu pendekatan berikut:

  • Buat satu proyek yang berisi banyak repositori dan tim.
  • Buat banyak proyek, masing-masing dengan kumpulan tim, repositori, build, item kerja, dan elemen lainnya sendiri.

Bahkan jika Anda memiliki banyak tim yang mengerjakan ratusan aplikasi dan proyek perangkat lunak yang berbeda, Anda dapat mengelolanya dalam satu proyek di Azure DevOps. Namun, jika Anda ingin mengelola keamanan yang lebih terperinci antara proyek perangkat lunak Anda dan timnya, pertimbangkan untuk menggunakan banyak proyek. Pada tingkat isolasi tertinggi adalah organisasi, di mana setiap organisasi terhubung ke satu tenant Microsoft Entra. Namun, satu penyewa Microsoft Entra dapat dihubungkan ke banyak organisasi Azure DevOps.

Catatan

Jika Anda mengaktifkan fitur Batasi visibilitas dan kolaborasi pengguna ke pratinjau proyek tertentu untuk organisasi, pengguna yang ditambahkan ke grup PenggunaProject-Scoped tidak dapat mengakses proyek yang tidak ditambahkan. Untuk informasi selengkapnya dan panggilan penting terkait keamanan, lihat Mengelola organisasi Anda, Membatasi visibilitas pengguna untuk proyek, dan lainnya.

Kerangka kerja keputusan proyek

Pilih struktur proyek yang sesuai berdasarkan kebutuhan kolaborasi Anda:

Pendekatan proyek tunggal:

  • Terbaik untuk: Organisasi atau tim yang lebih kecil dengan kolaborasi yang ketat
  • Manfaat: Visibilitas maksimum, sumber daya bersama, pelaporan terpadu
  • Pertimbangkan kapan: Tim mengerjakan produk terkait dengan siklus rilis serupa

Pendekatan beberapa proyek:

  • Terbaik untuk: Tim independen dengan persyaratan yang berbeda
  • Manfaat: Batas keamanan yang lebih baik, proses yang dapat disesuaikan, otonomi tim
  • Pertimbangkan kapan: Kebutuhan kepatuhan yang berbeda atau unit bisnis terpisah

Azure DevOps menyediakan pengalaman lintas proyek untuk mengelola pekerjaan di beberapa proyek.

Pertimbangkan beberapa proyek untuk:

  • Membatasi atau mengelola akses ke informasi tertentu
  • Mendukung proses pelacakan kerja kustom untuk unit bisnis yang berbeda
  • Mendukung unit bisnis terpisah dengan kebijakan administratif independen
  • Menguji kustomisasi atau ekstensi sebelum peluncuran produksi

Penting

Portabilitas repositori Git memudahkan migrasi repositori (termasuk riwayat penuh) antar proyek. Namun, Anda tidak dapat memigrasikan riwayat lain, seperti permintaan push dan pull, di antara proyek.

Saat Anda memetakan proyek ke unit bisnis, perusahaan Anda mendapatkan satu organisasi dan menyiapkan banyak proyek dengan satu atau beberapa proyek yang mewakili unit bisnis. Organisasi ini berisi semua aset Azure DevOps perusahaan dan terletak dalam geografi tertentu (misalnya, Eropa). Pertimbangkan panduan berikut untuk memetakan proyek Anda ke unit bisnis:

Satu proyek, banyak tim Satu organisasi, banyak proyek, dan tim Banyak organisasi
Panduan umum Terbaik untuk organisasi yang lebih kecil atau organisasi yang lebih besar dengan tim kerja yang sangat terkoordinasi. Baik ketika upaya yang berbeda membutuhkan proses yang berbeda. Berguna sebagai bagian dari migrasi warisan dan untuk batas keamanan keras antar organisasi. Digunakan dengan beberapa proyek dan tim dalam setiap organisasi.
Skala Mendukung puluhan ribu pengguna dan ratusan tim, tetapi yang terbaik dalam skala ini jika semua tim mengerjakan upaya terkait. Sama seperti satu proyek, tetapi banyak proyek mungkin lebih mudah.
Proses Proses yang selaras di seluruh tim; fleksibilitas tim untuk mengustomisasi papan tugas, dasbor, dan sebagainya. Proses independen untuk setiap proyek. Misalnya, jenis item kerja yang berbeda, bidang kustom, dan sebagainya. Seperti banyak proyek lainnya.
Kolaborasi Visibilitas default tertinggi dan pemanfaatan kembali antara pekerjaan dan aset dari berbagai tim. Visibilitas dan penggunaan kembali yang baik dimungkinkan, tetapi lebih mudah untuk menyembunyikan aset di antara proyek apakah disengaja. Visibilitas, kolaborasi, dan penggunaan kembali yang buruk antar organisasi.
Pelaporan roll-up dan manajemen portofolio Kemampuan terbaik dalam berkoordinasi dan menyelaraskan di seluruh tim dan berkoordinasi antar tim. Pelaporan berkualitas dapat dilakukan di seluruh proyek. Lebih sulit untuk roll-up lintas proyek dan koordinasi tim. Tidak ada penggabungan atau koordinasi antar organisasi.
Keamanan/isolasi Dapat mengunci aset di tingkat tim, tetapi defaultnya adalah visibilitas dan kolaborasi terbuka. Kemampuan yang lebih baik untuk membatasi akses antar proyek. Secara default, memberikan visibilitas yang baik dalam proyek dan isolasi yang baik di seluruh proyek. Batasan keras di seluruh organisasi; isolasi yang sangat baik dan kemampuan minimal untuk berbagi di seluruh organisasi.
Pengalihan konteks Paling mudah bagi tim untuk bekerja sama dan bagi pengguna untuk beralih antar upaya. Relatif mudah bagi pengguna untuk bekerja sama dan beralih konteks antar upaya. Lebih sulit bagi pengguna harus bekerja di berbagai organisasi.
Kelebihan informasi Secara default, semua aset terlihat oleh pengguna yang menggunakan "favorit" dan mekanisme serupa untuk menghindari "informasi kelebihan beban." Pengurangan risiko kelebihan informasi; sebagian besar aset proyek tersembunyi melewati batas proyek. Aset di seluruh organisasi terisolasi, mengurangi risiko kelebihan informasi.
Overhead administratif Banyak administrasi didelegasikan ke tim individu. Paling mudah untuk lisensi pengguna dan administrasi tingkat organisasi. Lebih banyak pekerjaan mungkin diperlukan jika penyelarasan diperlukan di antara upaya. Lebih banyak administrasi di tingkat proyek. Lebih banyak overhead, tetapi dapat berguna ketika proyek memiliki kebutuhan administratif yang berbeda. Dengan adanya lebih banyak proyek, ada lebih banyak overhead administratif yang memungkinkan lebih banyak fleksibilitas antara organisasi.

Susun repositori dan kontrol versi dalam proyek

Pertimbangkan pekerjaan strategis yang secara spesifik termasuk dalam ruang lingkup salah satu organisasi yang Anda buat sebelumnya, dan pihak mana yang membutuhkan akses. Gunakan informasi ini untuk memberi nama dan membuat proyek. Proyek ini memiliki URL yang ditentukan di bawah organisasi tempat Anda membuatnya dan Anda dapat mengaksesnya di https://dev.azure.com/{organization-name}/{project-name}.

Konfigurasikan proyek Anda di pengaturan Proyek.

Cuplikan layar memperlihatkan tombol Pengaturan proyek.

Untuk informasi selengkapnya tentang mengelola proyek, lihat Mengelola proyek di Azure DevOps. Anda dapat memindahkan proyek ke organisasi lain dengan memigrasikan data. Untuk informasi selengkapnya tentang memigrasikan proyek Anda, lihat Ringkasan migrasi.

Strategi repositori dan kontrol versi

Konfigurasikan strategi repositori Anda berdasarkan ukuran tim, arsitektur produk, dan persyaratan penyebaran.

Pemilihan sistem kontrol versi

Pilih antara Git dan Team Foundation Version Control (TFVC):

Repositori Git:

  • Pendekatan yang direkomendasikan untuk alur kerja pengembangan modern
  • Repositori tidak terbatas per proyek
  • Kontrol versi terdistribusi dengan pencabangan fleksibel
  • Terintegrasi dengan sebagian besar alat pengembangan dan sistem CI/CD

Kontrol Versi Team Foundation (TFVC):

  • Sistem kontrol versi terpusat
  • Repositori tunggal per proyek dengan organisasi berbasis folder
  • Cocok untuk tim yang lebih suka alur kerja terpusat

Tips

Proyek dapat menggunakan repositori Git dan TFVC jika tim Anda memiliki preferensi alur kerja yang berbeda.

Pola organisasi repositori

Strategi monorepo:

  • Terbaik untuk: Tim kecil membangun momentum dengan layanan terkait
  • Manfaat: Berbagi yang disederhanakan dan perubahan terkoordinasi
  • Tantangan: Kompleksitas pengetahuan meningkat dengan pertumbuhan tim; konpling layanan yang tidak diinginkan; pelacakan perubahan yang sulit

Strategi repositori terpisah:

  • Terbaik untuk: Tim besar dengan layanan independen
  • Manfaat: Batas layanan yang jelas, orientasi yang lebih mudah, siklus rilis independen
  • Pertimbangan: Memerlukan lebih banyak pengaturan awal tetapi menskalakan secara efektif dengan pertumbuhan tim.

Tips

Mulailah dengan monorepo untuk tim kecil dan beralih ke repositori terpisah saat organisasi Anda tumbuh dan kerumitan meningkat.

Strategi perataan repositori dan proyek

Proyek tunggal dengan beberapa repositori:

  • Terbaik untuk: Produk dan layanan dengan jadwal rilis terkoordinasi
  • Manfaat: Proses bersama, kontrol akses yang konsisten, administrasi yang disederhanakan
  • Gunakan saat: Pengembang sering bekerja di beberapa repositori dan memerlukan alat yang konsisten

Beberapa proyek dengan repositori khusus:

  • Terbaik untuk: Produk dengan jadwal independen atau persyaratan yang berbeda
  • Manfaat: Kustomisasi independen, tata kelola terpisah, batas yang jelas

Catatan

Portabilitas repositori Git memungkinkan migrasi yang mudah antara proyek dengan riwayat penerapan penuh.

Faktor keputusan untuk organisasi repositori:

  • Dependensi kode: Menempatkan produk dan layanan yang dapat disebarkan secara independen di repositori terpisah
  • Kebutuhan koordinasi: Jaga basis kode terkait bersama-sama ketika perubahan terkoordinasi diharapkan
  • Arsitektur: Pertahankan monolit yang sudah ada dalam repositori tunggal; pisahkan layanan yang tidak saling terhubung
  • Akses tim: Menerapkan manajemen izin yang tepat untuk mengontrol pembuatan repositori

Tips

Pertimbangkan untuk mengelola izin Anda, sehingga tidak semua orang di organisasi Anda dapat membuat repositori. Jika Anda memiliki terlalu banyak repositori, sulit untuk melacak siapa yang memiliki kode atau konten lain yang disimpan dalam repositori tersebut.

Repositori bersama vs. repositori yang di-fork

Gunakan repositori bersama dalam organisasi tepercaya. Pengembang menggunakan cabang untuk memisahkan perubahan mereka satu dengan yang lain. Dengan strategi percabangan dan rilis yang baik, satu repositori dapat mendukung pengembangan bersamaan untuk lebih dari seribu pengembang. Untuk informasi selengkapnya tentang strategi percabangan dan rilis, lihat Mengadopsi Strategi Percabangan Git dan Alur Rilis: Strategi Pencabangan Kami.

Fork berguna saat Anda bekerja dengan tim vendor yang seharusnya tidak memiliki akses langsung untuk memperbarui repositori utama. Fork juga berguna dalam skenario di mana banyak pengembang jarang berkontribusi, seperti dalam proyek sumber terbuka. Saat bekerja dengan fork, Anda mungkin ingin mempertahankan proyek terpisah untuk mengisolasi repositori fork dari repositori utama. Ada tambahan overhead administratif, tetapi menjaga proyek utama tetap bersih. Untuk informasi selengkapnya, lihat artikel Forks.

Gambar berikut menampilkan sampel bagaimana perusahaan Anda dapat menyusun organisasi, proyek, item kerja, tim, dan repositorinya.

Diagram memperlihatkan struktur organisasi untuk perusahaan.

Mengelola sumber daya sementara dan bersama

Pertimbangkan cara mengelola sumber daya sementara dan bersama secara efektif dengan menggunakan praktik terbaik berikut:

  • Lingkungan sementara: Lingkungan sementara berumur pendek dan digunakan untuk tugas seperti pengujian, pengembangan, atau penahapan. Untuk mengelola lingkungan ini secara efisien:
    • Repositori dan alur terpisah: Setiap lingkungan sementara dan sumber daya terkaitnya, seperti Azure Functions, harus memiliki repositori dan alurnya sendiri. Pemisahan ini berarti Anda dapat menyebarkan dan mengembalikan lingkungan dan sumber dayanya secara bersamaan. Lebih mudah untuk memutar dan membuangnya sesuai kebutuhan.
    • Contoh: Buat repositori dan alur khusus untuk lingkungan pengembangan Anda, termasuk semua sumber daya yang diperlukan seperti Azure Functions, akun penyimpanan, dan layanan lainnya.
  • Sumber daya bersama: Sumber daya bersama biasanya berumur panjang dan digunakan di beberapa lingkungan. Sumber daya ini sering memiliki waktu spin-up yang lebih lama dan biaya yang lebih tinggi. Untuk mengelola sumber daya bersama secara efektif:
    • Repositori dan alur terpisah: Sumber daya bersama, seperti Azure SQL Database, harus memiliki repositori dan alur mereka sendiri. Pemisahan ini memastikan bahwa lingkungan sementara dapat menggunakan sumber daya bersama ini, membuat penyebaran mereka lebih cepat dan lebih hemat biaya.
    • Contoh: Buat repositori dan alur untuk Azure SQL Database Anda, yang dapat digunakan beberapa lingkungan sementara.
  • Sumber daya infrastruktur bersama: Sumber daya infrastruktur bersama, seperti cloud privat virtual (VPC) dan subnet, juga dikenal sebagai zona pendaratan, juga harus memiliki repositori dan alur mereka sendiri. Pendekatan ini memastikan bahwa Anda mengelola infrastruktur secara konsisten dan Anda dapat menggunakannya kembali di berbagai lingkungan.
    • Contoh: Buat repositori dan alur untuk konfigurasi VPC dan subnet Anda, yang dapat direferensikan oleh repositori dan alur lainnya.

Selengkapnya tentang struktur organisasi

Pilih jenis akun administrator organisasi Anda

Saat Anda membuat organisasi, kredensial yang Anda gunakan untuk masuk menentukan penyedia identitas mana yang digunakan organisasi Anda. Buat organisasi Anda dengan menggunakan akun Microsoft atau instans Microsoft Entra. Gunakan kredensial tersebut untuk masuk sebagai administrator ke organisasi baru Anda di https://dev.azure.com/{YourOrganization}.

Menggunakan akun Microsoft Anda

Gunakan akun Microsoft Anda jika Anda tidak perlu mengautentikasi pengguna untuk organisasi dengan menggunakan ID Microsoft Entra. Semua pengguna harus masuk ke organisasi Anda dengan menggunakan akun Microsoft. Jika Anda tidak memilikinya, buat akun Microsoft.

Masukkan kata sandi Anda dan masuk

Jika Anda tidak memiliki instans Microsoft Entra, buat instans secara gratis dari portal Azure atau gunakan akun Microsoft Anda untuk membuat organisasi. Kemudian, Anda dapat menyambungkan organisasi Anda ke ID Microsoft Entra.

Menggunakan akun Microsoft Entra Anda

Anda mungkin sudah memiliki akun Microsoft Entra jika Anda menggunakan Azure atau Microsoft 365. Jika Anda bekerja untuk perusahaan yang menggunakan ID Microsoft Entra untuk mengelola izin pengguna, Anda mungkin memiliki akun Microsoft Entra.

Jika Anda tidak memiliki akun Microsoft Entra, daftar id Microsoft Entra untuk menyambungkan organisasi Anda secara otomatis ke ID Microsoft Entra Anda. Semua pengguna harus menjadi anggota di direktori tersebut untuk mengakses organisasi Anda. Untuk menambahkan pengguna dari organisasi lain, gunakan kolaborasi Microsoft Entra B2B.

Azure DevOps mengautentikasi pengguna melalui ID Microsoft Entra Anda, sehingga hanya pengguna yang merupakan anggota di direktori tersebut yang memiliki akses ke organisasi Anda. Saat Anda menghapus pengguna dari direktori tersebut, mereka tidak dapat lagi mengakses organisasi Anda. Hanya administrator Microsoft Entra tertentu yang mengelola pengguna di direktori Anda, sehingga administrator mengontrol siapa yang mengakses organisasi Anda.

Untuk informasi selengkapnya tentang mengelola pengguna, lihat Mengelola pengguna.

Memetakan organisasi ke unit bisnis

Setiap unit bisnis di dalam perusahaan Anda mendapatkan organisasi sendiri di Azure DevOps, serta tenant Microsoft Entra tersendiri. Anda dapat menyiapkan proyek dalam organisasi individual tersebut, sesuai kebutuhan, berdasarkan tim atau pekerjaan yang sedang berlangsung.

Untuk perusahaan yang lebih besar, Anda dapat membuat beberapa organisasi dengan menggunakan akun pengguna yang berbeda (kemungkinan besar akun Microsoft Entra). Pertimbangkan grup dan pengguna apa yang berbagi strategi dan pekerjaan, dan mengelompokkannya ke dalam organisasi tertentu.

Misalnya, perusahaan Fabrikam fiktif membuat tiga organisasi berikut:

  • Fabrikam-Marketing
  • Fabrikam-Engineering
  • Fabrikam-Sales

Setiap organisasi memiliki URL terpisah, seperti:

  • https://dev.azure.com/Fabrikam-Marketing
  • https://dev.azure.com/Fabrikam-Engineering
  • https://dev.azure.com/Fabrikam-Sales

Organisasi ini untuk perusahaan yang sama, tetapi sebagian besar terisolasi satu sama lain. Anda tidak perlu memisahkan apa pun dengan cara ini. Hanya buat batasan ketika masuk akal untuk bisnis Anda.

Tips

Anda dapat dengan lebih mudah mempartisi organisasi yang ada dengan proyek, daripada menggabungkan organisasi yang berbeda.

Menggunakan AI untuk merencanakan struktur organisasi Anda

Saat mengonfigurasi Azure DevOps MCP Server, Anda dapat menggunakan asisten AI untuk menganalisis dan merencanakan struktur organisasi Anda melalui perintah bahasa alami.

Contoh perintah untuk perencanaan organisasi

Tugas Contoh tanggapan
Meninjau struktur saat ini List all projects and teams in <Contoso> organization
Menganalisis penyiapan tim Show all teams and their members in <Contoso> project
Periksa jalur area List all area paths configured in <Contoso> project
Meninjau perulangan Show the iteration paths and schedule for <Contoso> project
Menilai cakupan proyek Show the number of work items, repos, and pipelines in each project in <Contoso> organization
Menemukan proyek yang tidak digunakan List projects in <Contoso> organization that have no recent commits or work item updates
Membandingkan ukuran tim Show the member count for every team across all projects in <Contoso> organization
Penyebaran jalur-area spot List area paths in <Contoso> project that have no work items assigned
Merencanakan reorganisasi Show which teams own each area path in <Contoso> project, and how many active work items each area has

Konten terkait

  • Last updated on