Mempercepat kolaborasi dan pengembangan Agile dengan komponenisasi
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Produk Anda berhasil, organisasi Anda berkembang, dan saatnya untuk meningkatkan basis kode Anda agar sesuai dengan keberhasilan ini. Saat Anda menskalakan 2-3 tim yang bekerja dalam satu basis kode pada satu produk, Anda mungkin menemukan diri Anda mengajukan pertanyaan seperti:
Bagaimana tim saya dapat berbagi komponen yang dapat digunakan kembali secara efisien?
Bagaimana cara mengaktifkan tim fitur saya untuk melakukan iterasi dengan cepat tanpa menginjak pekerjaan tim lain?
Bagaimana cara memberi tim saya otonomi untuk melakukan iterasi dengan kecepatan yang tepat untuk mereka?
Tim pada tahap apa pun dapat memperoleh manfaat dari mempertimbangkan pertanyaan-pertanyaan ini. Jika Anda adalah tim yang mapan dengan basis kode warisan, Anda mungkin mengajukan pertanyaan yang sama ini saat diminta untuk memberikan nilai lebih, lebih cepat dari sebelumnya. Terlepas dari situasi Anda, komponenisasi dapat membantu Anda membangun basis kode yang menskalakan ke ukuran tim Anda dan kecepatan pengembangan hari ini.
Dalam artikel ini, kami mengeksplorasi bagaimana komposisi biner melalui Azure Artifacts dapat membantu Anda mengelola dan berbagi dependensi eksternal, perangkat lunak sumber terbuka, dan komponen bersama Anda yang terisolasi.
Komponen dan komposisi
Komponenisasi adalah proses pembagian dan pengorganisasian produk Anda menjadi komponen yang berbeda. Sebagian besar proyek .NET sudah memiliki beberapa gagasan komponen dalam bentuk proyek dalam solusi. Misalnya, situs web dasar dapat terdiri dari komponen front-end, komponen akses data, dan komponen penyimpanan model/data.
Komposisi sumber
Seiring pertumbuhan produk Anda, solusi dan model proyek dapat menjadi tidak efisien. Perubahan membutuhkan waktu lebih lama untuk diintegrasikan dan lebih sulit untuk digabungkan, build menjadi lebih lambat, dan komponen mulai tumbuh dari satu proyek ke beberapa proyek. Umumnya, ini adalah titik di mana tim mulai memecah kumpulan proyek terkait ini menjadi solusi terpisah.
Setelah Anda melampaui satu solusi, bagaimana Anda melakukan komponen menjadi pertanyaan yang menarik. Kami mulai dengan komposisi sumber, di mana setiap komponen dirujuk melalui referensi proyek di Visual Studio. Komposisi sumber dimungkinkan selama sumber Anda hidup dalam satu batas komposisi: satu solusi dalam satu repositori sumber.
Sayangnya, referensi proyek ini mulai memecah ketika beberapa solusi terlibat. Pada titik ini, ketika solusi A tergantung pada solusi B, solusi harus merujuk ke biner bawaan (seperti DLL) yang diproduksi oleh solusi B - ini adalah komposisi biner.
Oleh karena itu, biner ini sekarang perlu dibangun dan tersedia untuk solusi A sebelum dapat berhasil dibangun. Terdapat beberapa cara untuk melakukannya:
Anda dapat memeriksanya ke kontrol sumber. Tergantung pada sistem kontrol sumber Anda, biner dapat dengan cepat balon ukuran repositori Anda, waktu check-out yang lambat, dan performa repositori umum. Jika Anda mulai bekerja di cabang, beberapa tim akhirnya dapat memperkenalkan biner yang sama pada versi yang berbeda, yang menyebabkan konflik penggabungan yang menantang.
Atau, Anda dapat menghostingnya pada berbagi file, meskipun pendekatan ini dilengkapi dengan batasan tertentu. Berbagi file tidak memiliki indeks untuk pencarian cepat, dan tidak memberikan perlindungan terhadap penimpaan versi di masa mendatang.
Komposisi paket
Paket mengatasi banyak tantangan mereferensikan biner. Alih-alih memeriksanya ke sumber, Anda dapat memiliki solusi B menghasilkan binernya sebagai paket NuGet yang kemudian dapat dikonsumsi solusi lain A. Jika solusi A dan solusi B dipertahankan sebagai komponen terpisah, di mana perubahan simultan di A dan B jarang terjadi, komposisi paket adalah cara yang bagus untuk mengelola dependensi A pada B. Komposisi paket memungkinkan B untuk melakukan iterasi pada iramanya sendiri, sementara A bebas untuk mendapatkan pembaruan dari B ketika jadwal A mengizinkan, dan memungkinkan beberapa tim untuk melakukan iterasi dan memperbarui solusi B tanpa memengaruhi solusi A (atau solusi lain C atau D).
Namun, komposisi paket memang datang dengan serangkaian tantangannya sendiri. Sejauh ini, kami telah memeriksa contoh langsung. Komposisi paket penskalaan hingga ukuran basis kode besar (seperti Windows atau Bing) dapat menyebabkan serangkaian tantangan:
Memahami dampak pemecahan perubahan dalam komponen yang rendah dalam grafik dependensi menjadi sangat menantang.
Dependensi berlian dapat menjadi hambatan yang signifikan terhadap kelincahan. Dalam dependensi berlian, komponen B dan C bergantung pada komponen bersama A, sementara komponen D tergantung pada B dan C. Saat komponen A memperkenalkan versi baru dengan perubahan yang melanggar, jika B memperbarui ke versi baru tetapi C tidak, D tidak dapat mengambil pembaruan B tanpa memperkenalkan konflik dependensi. Dalam contoh sederhana ini, percakapan dengan C mungkin semua yang diperlukan untuk menyelesaikan konflik. Namun, dalam grafik yang kompleks, berlian dapat dengan cepat menjadi tidak dapat diselesaikan.
Ketika modifikasi perlu diterapkan pada dua komponen yang terdiri menggunakan paket, siklus iterasi pengembang menjadi jauh lebih lambat. Jika Komponen A diperbarui, komponen perlu membangun kembali, mengemas ulang, dan menerbitkan ulang. Selanjutnya, komponen B harus memperbarui ke versi yang baru-baru ini diterbitkan untuk memvalidasi perubahan yang dilakukan pada komponen A. Menggunakan komposisi sumber, yang memungkinkan pembuatan Komponen A dan B secara bersamaan, akan secara konsisten memberikan siklus iterasi yang lebih cepat bagi pengembang.
Apa yang harus Anda gunakan
Secara umum, kami telah melihat tim besar paling sukses ketika mereka menggunakan campuran strategi komposisi. Untuk membantu menentukan apa yang tepat untuk basis kode Anda, mulailah dengan memetakan grafik dependensi produk Anda, dan mulai mengelompokkan komponen Anda ke dalam set komponen terkait.
Misalnya Anda mungkin memiliki kumpulan komponen yang merupakan kerangka kerja Anda, dan serangkaian komponen lain yang membentuk layanan yang menghadap pengguna Anda. Kemudian, untuk setiap grup komponen terkait, ajukan pertanyaan-pertanyaan berikut:
Dapatkah saya mengantisipasi check-in yang sering di seluruh set yang telah saya tetapkan untuk tim saya?
Apakah satu tim bertanggung jawab atas seluruh set?
Untuk satu set, apakah ada irama rilis bersama?
Dalam pengalaman kami, kami telah menemukan bahwa menggunakan komposisi sumber paling efektif untuk proyek terkait yang ditangani oleh satu tim atau sekelompok tim terkait. Sebaliknya, komposisi biner terbukti menguntungkan untuk perangkat lunak sumber terbuka, dependensi eksternal (komponen dari tim yang jauh atau terisolasi), dan komponen bersama independen.