Merencanakan struktur organisasi Anda
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Gunakan struktur bisnis Anda sebagai panduan untuk jumlah organisasi, proyek, dan tim yang Anda buat di Azure DevOps. Artikel ini membantu Anda merencanakan struktur dan skenario yang berbeda untuk Azure DevOps.
Pertimbangkan struktur berikut untuk pekerjaan bisnis dan kolaboratif Anda di Azure DevOps:
Anda mungkin juga ingin merencanakan skenario berikut:
- Memetakan organisasi dan proyek Anda di Azure DevOps ke perusahaan, unit bisnis, dan struktur tim Anda
- Menyusun repositori Anda (repositori)
- Menyusun tim Anda- dapat membantu atau menghambat tim menjadi Tangkas dan otonom
- Mengelola akses ke data - siapa yang perlu memiliki akses dan siapa yang tidak?
- Kebutuhan pelaporan
- Mempromosikan praktik umum - gunakan elemen dasar untuk menciptakan pola pikir dan budaya yang tangkas
Memiliki setidaknya satu organisasi, yang dapat mewakili perusahaan Anda, kumpulan proyek kode Anda yang lebih besar, atau bahkan beberapa unit bisnis terkait.
Apa itu organisasi?
Organisasi di Azure DevOps adalah mekanisme untuk mengatur dan menghubungkan grup proyek terkait. Contohnya termasuk divisi bisnis, divisi regional, atau struktur perusahaan lainnya. Anda dapat memilih satu organisasi untuk seluruh perusahaan Anda, satu organisasi untuk diri Anda sendiri, atau organisasi terpisah untuk unit bisnis tertentu.
Setiap organisasi mendapatkan tingkat layanan gratisnya sendiri (hingga lima pengguna untuk setiap jenis layanan) sebagai berikut. Anda dapat menggunakan semua layanan, atau memilih hanya apa yang Anda butuhkan untuk melengkapi alur kerja yang ada.
- Azure Pipelines: Satu pekerjaan yang dihosting dengan 1.800 menit per bulan untuk CI/CD dan satu pekerjaan yang dihost sendiri
- Azure Boards: Pelacakan dan papan item kerja
- Azure Repos: Repositori Git privat tanpa batas
- Azure Artifacts: Manajemen paket
- Pemangku Kepentingan Tidak Terbatas
- Lima pengguna pertama gratis (Lisensi dasar)
- Alur Azure
- Satu CI/CD yang dihosting Microsoft (satu pekerjaan bersamaan, hingga 30 jam per bulan)
- Satu pekerjaan bersamaan CI/CD yang dihost 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 tidak digunakan lagi, tetapi Pengujian Beban Azure 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.
Berapa banyak organisasi yang Anda butuhkan?
Mulailah dengan satu organisasi di Azure DevOps. Kemudian, Anda dapat menambahkan lebih banyak organisasi—yang mungkin memerlukan model keamanan yang berbeda—nanti. Satu repositori kode atau proyek hanya memerlukan satu organisasi. Jika Anda memiliki tim terpisah yang perlu mengerjakan kode atau proyek lain dalam isolasi, pertimbangkan untuk membuat organisasi terpisah untuk tim tersebut. Mereka akan memiliki URL yang berbeda. Tambahkan proyek, tim, dan repositori, seperlunya, sebelum Anda menambahkan organisasi lain.
Luangkan waktu untuk meninjau struktur kerja Anda dan berbagai grup bisnis dan peserta yang akan dikelola. Untuk informasi selengkapnya, lihat Memetakan proyek Anda ke unit bisnis dan Pertimbangan struktur.
Tip
Untuk organisasi Microsoft Entra milik perusahaan, pertimbangkan untuk membatasi pengguna membuat organisasi baru sebagai cara untuk melindungi IP Anda. Untuk informasi selengkapnya, lihat Membatasi pembuatan organisasi melalui kebijakan penyewa Microsoft Entra. Pengguna dapat membuat organisasi menggunakan akun MSA atau GitHub mereka tanpa batasan.
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 mereka 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. Grup tim dibuat saat Anda membuat tim. Anda dapat menggunakan grup ini dalam kueri atau untuk mengatur izin untuk tim Anda.
Apa itu proyek?
Proyek di Azure DevOps berisi serangkaian fitur berikut:
- Papan dan backlog untuk perencanaan yang tangkas
- Alur untuk integrasi dan penyebaran berkelanjutan
- Repositori untuk kontrol versi dan manajemen kode sumber dan artefak
- Integrasi pengujian berkelanjutan sepanjang siklus hidup proyek Setiap organisasi berisi satu atau beberapa proyek
Dalam gambar berikut, perusahaan Contoso fiktif memiliki empat proyek dalam organisasi Contoso-Manufacturing mereka.
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 Anda membuat organisasi, proyek default akan dibuat untuk Anda. 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 melakukan salah satu pendekatan berikut:
- Membuat satu proyek yang berisi banyak repositori dan tim
- Membuat 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 penyewa Microsoft Entra. Namun, satu penyewa Microsoft Entra dapat dihubungkan ke banyak organisasi Azure DevOps.
Catatan
Jika fitur Batasi visibilitas dan kolaborasi pengguna ke pratinjau proyek tertentu diaktifkan untuk organisasi, pengguna yang ditambahkan ke grup Pengguna Cakupan Proyek tidak akan dapat mengakses proyek yang belum ditambahkan. Untuk informasi selengkapnya dan panggilan penting terkait keamanan, lihat Mengelola organisasi Anda, Membatasi visibilitas pengguna untuk proyek, dan lainnya.
Proyek tunggal
Satu proyek menempatkan semua pekerjaan pada tingkat "portofolio" yang sama untuk seluruh organisasi. Pekerjaan Anda memiliki serangkaian jalur repositori dan iterasi yang sama. Dengan satu proyek, tim berbagi repositori sumber, definisi build, definisi rilis, laporan, dan umpan paket. Anda mungkin memiliki produk atau layanan besar yang dikelola oleh banyak tim. Tim-tim tersebut memiliki inter-dependensi yang ketat di seluruh siklus hidup produk. Anda membuat proyek dan membagi pekerjaan menggunakan tim dan jalur area. Penyiapan ini memberi tim Anda visibilitas ke dalam pekerjaan satu sama lain, sehingga organisasi tetap selaras. Tim Anda menggunakan taksonomi yang sama untuk pelacakan item kerja, sehingga lebih mudah untuk berkomunikasi dan tetap konsisten.
Tip
Ketika beberapa tim bekerja pada produk yang sama, memiliki semua tim pada jadwal iterasi yang sama membantu menjaga tim Anda tetap selaras dan memberikan nilai pada irama yang sama. Misalnya, organisasi kami di Azure DevOps memiliki lebih dari 40 tim fitur dan 500 pengguna dalam satu proyek - ini berfungsi dengan baik karena kita semua mengerjakan rangkaian produk umum dengan tujuan umum dan jadwal rilis umum.
Kueri dan papan dalam volume tinggi dapat mempermudah menemukan apa yang Anda cari. Tergantung pada arsitektur produk Anda, kesulitan ini dapat berdarah ke area lain seperti build, rilis, dan repos. Pastikan untuk menggunakan konvensi penamaan yang baik dan struktur folder sederhana. Saat Anda menambahkan repositori ke proyek Anda, pertimbangkan strategi Anda dan tentukan apakah repositori tersebut dapat ditempatkan ke dalam proyeknya sendiri.
Banyak proyek
Anda dapat menentukan struktur proyek dengan cara terbaik mengirim produk. Memiliki beberapa proyek menggeser beban administrasi dan memberi tim Anda lebih banyak otonomi untuk mengelola proyek saat tim memutuskan. Ini juga memberikan kontrol keamanan dan akses yang lebih besar ke aset di berbagai proyek. Namun, memiliki kemandirian tim dengan banyak proyek menciptakan beberapa tantangan keselarasan. Jika setiap proyek menggunakan proses atau jadwal iterasi yang berbeda, itu dapat membuat komunikasi dan kolaborasi sulit jika taksonomi tidak sama.
Tip
Jika Anda menggunakan proses dan jadwal iterasi yang sama di semua proyek Anda, kemampuan Anda untuk menggulung data dan laporan di seluruh tim akan meningkat.
Azure DevOps menyediakan pengalaman lintas proyek untuk mengelola pekerjaan.
Anda mungkin ingin menambahkan proyek lain karena skenario berikut:
- Untuk melarang atau mengelola akses ke informasi dalam proyek
- Untuk mendukung proses pelacakan kerja kustom untuk unit bisnis tertentu dalam organisasi Anda
- Untuk mendukung unit bisnis yang sepenuhnya terpisah yang memiliki kebijakan dan administrator administratif mereka sendiri
- Untuk mendukung pengujian aktivitas kustomisasi atau menambahkan ekstensi sebelum meluncurkan perubahan pada proyek kerja
Saat Anda mempertimbangkan banyak proyek, perlu diingat bahwa portabilitas repositori Git memudahkan migrasi repositori (termasuk riwayat penuh) antar proyek. Riwayat lain tidak dapat dimigrasikan antar proyek. Contohnya adalah riwayat permintaan push dan pull.
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. Semua aset Azure DevOps perusahaan terkandung dalam organisasi ini dan terletak di dalam wilayah tertentu (misalnya, Eropa Barat). 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 yang sangat selaras. | Baik ketika upaya yang berbeda membutuhkan proses yang berbeda. | Berguna sebagai bagian dari migrasi warisan TFS dan untuk batas keamanan keras antar organisasi. Digunakan dengan beberapa proyek dan tim dalam setiap organisasi. |
| Sisik | 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 menyesuaikan papan, dasbor, dan sebagainya. | Proses independen untuk setiap proyek. Misalnya, jenis item kerja yang berbeda, bidang kustom, dan sebagainya. | Sama seperti banyak proyek. |
| Kolaborasi | Visibilitas default tertinggi dan penggunaan kembali antara pekerjaan dan aset tim yang berbeda. | 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 untuk menggulung di seluruh tim dan berkoordinasi antar tim. | Pelaporan yang baik mungkin di seluruh proyek. Lebih sulit untuk roll-up lintas proyek dan koordinasi tim. | Tidak ada roll-up atau koordinasi antar organisasi. |
| Keamanan/isolasi | Dapat mengunci aset di tingkat tim, tetapi defaultnya adalah visibilitas dan kolaborasi terbuka. | Kemampuan yang lebih baik untuk mengunci 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. |
| Informasi kelebihan beban | Secara default, semua aset terlihat oleh pengguna yang menggunakan "favorit" dan mekanisme serupa untuk menghindari "informasi kelebihan beban." | Pengurangan risiko informasi kelebihan beban; sebagian besar aset proyek tersembunyi di seluruh 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. Pekerjaan lainnya 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. | Seperti halnya lebih banyak proyek, ada lebih banyak overhead administratif, yang memungkinkan lebih banyak fleksibilitas antara org. |
Repositori struktur dan kontrol versi dalam proyek
Pertimbangkan pekerjaan strategis khusus yang dilingkupkan ke salah satu organisasi yang Anda buat sebelumnya dan siapa 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 dapat diakses di https://dev.azure.com/{organization-name}/{project-name}.
Konfigurasikan proyek Anda di 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.
Mengelola kontrol versi
Dalam proyek tempat layanan Azure Repos diaktifkan, repositori kontrol versi dapat menyimpan dan merevisi kode. Pertimbangkan opsi berikut saat Anda mengonfigurasi repositori.
Kontrol Versi Git vs. Team Foundation (TFVC)
Azure Repos menawarkan sistem kontrol versi berikut untuk dipilih oleh tim:
- Git dan TFVC. Proyek dapat memiliki repositori dari setiap jenis. Secara default, proyek baru memiliki repositori Git kosong. Git memungkinkan sejumlah besar fleksibilitas dalam alur kerja pengembang dan terintegrasi dengan hampir setiap alat yang relevan dalam ekosistem pengembang. Proyek apa pun dapat menggunakan repositori Git. Tidak ada batasan jumlah repositori Git yang dapat ditambahkan ke proyek.
TFVC adalah sistem kontrol versi terpusat yang juga tersedia. Tidak seperti Git, hanya satu repositori TFVC yang diizinkan untuk proyek. Tetapi, dalam repositori, folder, dan cabang tersebut digunakan untuk mengatur kode untuk beberapa produk dan layanan, jika diinginkan. Proyek dapat menggunakan TFVC dan Git, jika sesuai.
Satu vs. banyak repositori
Apakah Anda perlu menyiapkan beberapa repositori dalam satu proyek atau menyiapkan repo per proyek? Panduan berikut berkaitan dengan fungsi perencanaan dan administrasi di seluruh repositori tersebut.
Satu proyek yang berisi beberapa repositori berfungsi dengan baik jika produk/layanan bekerja pada jadwal rilis terkoordinasi. Jika pengembang sering bekerja dengan beberapa repositori, simpan dalam satu proyek untuk memastikan proses tetap dibagikan dan konsisten. Lebih mudah untuk mengelola akses repositori dalam satu proyek, karena kontrol akses dan opsi seperti penegakan kasus dan ukuran file maks diatur di tingkat proyek. Anda dapat mengelola kontrol akses dan pengaturan satu per satu, bahkan jika repositori Anda berada dalam satu proyek.
Jika produk yang disimpan dalam beberapa repositori berfungsi pada jadwal atau proses independen, Anda dapat membaginya menjadi beberapa proyek. Portabilitas repositori Git memudahkan untuk memindahkan repositori antar proyek dan masih menyimpan riwayat penerapan keakuratan penuh. Riwayat lain, seperti permintaan pull atau riwayat build, tidak mudah dimigrasikan.
Dasarkan keputusan Anda untuk satu vs. banyak repositori pada faktor dan tips berikut:
- dependensi dan arsitektur kode
- menempatkan setiap produk atau layanan yang dapat disebarkan secara independen dalam repositorinya sendiri
- jangan pisahkan basis kode ke dalam banyak repositori jika Anda berharap untuk membuat perubahan kode terkoordinasi di seluruh repositori tersebut, karena tidak ada alat yang dapat membantu mengoordinasikan perubahan tersebut
- jika basis kode Anda sudah monolit, simpan dalam satu repositori. Untuk informasi selengkapnya tentang repositori monolitik, lihat Bagaimana Microsoft mengembangkan perangkat lunak modern dengan artikel DevOps
- jika Anda memiliki banyak layanan yang terputus, satu repositori per layanan adalah strategi yang baik
Tip
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 fork
Sebaiknya gunakan repositori bersama dalam organisasi tepercaya. Pengembang menggunakan cabang untuk mempertahankan isolasi perubahan mereka satu dengan yang lain. Dengan strategi percabangan dan rilis yang baik, satu repositori dapat diskalakan untuk 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 dapat berguna saat Anda bekerja dengan tim vendor yang seharusnya tidak memiliki akses langsung untuk memperbarui repositori utama. Fork juga dapat 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. Mungkin ada overhead administratif tambahan, 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.
Selengkapnya tentang struktur organisasi
Pilih jenis akun administrator organisasi Anda
Saat Anda membuat organisasi, kredensial yang Anda masuki dengan menentukan penyedia identitas mana yang digunakan organisasi Anda. Buat organisasi Anda dengan 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 Jika Anda tidak perlu mengautentikasi pengguna untuk organisasi dengan ID Microsoft Entra. Semua pengguna harus masuk ke organisasi Anda dengan akun Microsoft. Jika Anda tidak memilikinya, buat akun Microsoft.
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 dalam perusahaan Anda mendapatkan organisasinya sendiri di Azure DevOps, bersama dengan penyewa Microsoft Entra sendiri. 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 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.
Tip
Anda dapat dengan lebih mudah mempartisi organisasi yang ada dengan proyek, daripada menggabungkan organisasi yang berbeda.