Metodologi pengembangan ketika ratusan pengembang mengerjakan satu solusi tunggal?

Kami adalah organisasi yang terdiri dari sekitar 200 pengembang yang bekerja terus menerus pada satu produk tunggal (menggunakan kontrol revisi Git) yang rencananya akan dirilis pada tanggal tertentu.

Karena banyaknya pengembang, kami mencoba membuat tim "lintas fungsional" dengan sekitar 10 pengembang di setiap tim, menghasilkan sekitar 20 tim pengembang di organisasi.

Karena kami ingin mempertahankan "standar tinggi" yang berkelanjutan (artinya ketika pengembang melakukan tarikan, produk setidaknya harus dapat dikompilasi, dll) dari produk di repositori utama, kami ingin menggunakan beberapa jenis gerbang berkualitas.

Saya agak tidak yakin bagaimana mengutarakan pertanyaan, tetapi saya bertanya-tanya apakah saya bisa mendapatkan saran tentang metodologi pengembangan untuk sekelompok besar pengembang yang mengerjakan satu produk.

Menurut pendapat kami, salah satu ujung spektrum adalah untuk memungkinkan setiap pengembang untuk berkomitmen langsung ke repositori utama, namun kami khawatir bahwa karena jumlah pengembang yang tinggi / berkomitmen bahwa "repositori utama" akan terus berada dalam tahap rusak, karena untuk kita tidak dapat memiliki "gerbang kualitas" yang menuntut untuk setiap komit.

Ujung lain dari spektrum mungkin seperti (kami pikir Linus Torvalds / Linux melakukannya) pohon atau struktur piramida, di mana "repositori utama" hanya memiliki tiga sumber tarikan, ketiganya hanya memiliki beberapa sumber tarikan tepercaya, dll. Namun, kami merasa bahwa dengan struktur seperti itu perubahan memiliki rantai panjang untuk didaki agar masuk ke "gudang utama". Plus bahwa jika terjadi konflik gabungan, masalahnya akan muncul pada pengembang lain daripada "pengembang asli".

Dengan semua informasi latar belakang dan pendapat yang dinyatakan, bagaimana kita bisa belajar dan membaca metodologi pengembangan yang direkomendasikan untuk begitu banyak pengembang? Bagaimana organisasi besar (Microsoft, Facebook, Ubuntu, dll?) Menata pengembangan mereka?

Anda tentu harus mempertimbangkan memecah produk menjadi modul dengan tim antarmuka (s) membawa modul-modul konstituen menjadi satu produk. Ini pada gilirannya akan berarti memisahkan repositori agar sesuai dengan partisi dan hierarki modul. Jika tampaknya Anda tidak dapat melakukan ini, maka proyek mungkin akan terhenti karena banyaknya pengembang yang berkontribusi.

Jika Anda berencana untuk menggunakan Git untuk kontrol versi maka saya akan merekomendasikan menggunakan sistem peninjauan kode (seperti Gerrit ) untuk meningkatkan transparansi dan memastikan kualitas untuk setiap repositori. Dengan begitu semua pekerjaan harus disetujui sebelum digabungkan ke dalam repositori resmi. Dalam skenario ini masuk akal untuk memberikan izin individu tepercaya untuk mendorong dari repo di bawah sistem peninjauan kode ke repositori lain (juga mungkin di bawah sistem peninjauan kode). Jika digunakan dengan benar, ini harus menjadi proses yang cepat dan sangat bermanfaat yang tidak menghambat proses pengembangan.

Mengenai verifikasi bangunan, Anda akan memerlukan server integrasi berkelanjutan (CI) yang tujuannya adalah untuk secara otomatis membuat dan memverifikasi kode. Dengan memverifikasi kode, saya maksudkan bahwa kode berhasil dikompilasi dan tes lulus. Infact Jenkins (CI Server) dapat dihubungkan ke sistem peninjauan kode Gerrit sebagai bagian dari tahap verifikasi Gerrit , yang sepenuhnya mengotomatiskan proses.

Selain alat integrasi ini, penting untuk mengupayakan integrasi yang sering sebagai bagian dari metodologi pengembangan, untuk meminimalkan penggabungan waktu.

Mungkin layak untuk mempertimbangkan proses pengembangan Agile seperti Scrum yang tujuannya adalah untuk memecah produk yang kompleks menjadi potongan kenaikan produk yang dapat dikelola (disebut Sprint). Ini akan memberikan peluang integrasi antar repositori.

Jelas, dengan tim pengembangan 200 orang, Anda harus memiliki semacam struktur hierarkis. Seorang individu atau sekelompok kecil orang sedang membuat keputusan tentang desain produk perangkat lunak. Proses pengembangan Anda harus mencerminkan ini: Anda memerlukan ulasan kode dan pengujian untuk memastikan perangkat lunak yang dibuat benar-benar cocok dengan apa yang ingin Anda buat (serta untuk tujuan kualitas).

Bahkan tim kecil membutuhkan pemimpin untuk memandu tim dan meninjau pekerjaan mereka saat mereka mengembangkan komponen individu. Mereka juga harus menjadi proses kontrol kualitas di tingkat tim.

Jadi, ya, Anda harus mengikuti struktur hierarkis berkenaan dengan repositori. Ini agar sesuai dengan struktur hierarki proyek secara keseluruhan.

Masing-masing komponen harus dibangun dan diuji ke tingkat kecukupan tertentu sebelum Anda berpikir untuk menyatukannya. Mengizinkan 200 orang untuk berkomitmen langsung ke proyek utama akan menjadi kekacauan. Anda harus memiliki area yang terpisah untuk setiap grup tempat individu dapat melakukan perubahan mereka setiap hari, tanpa memengaruhi proyek utama.

Ini adalah hal yang sangat baik jika "perubahan memiliki rantai panjang untuk dipanjat untuk masuk ke gudang utama" karena rantai ini memungkinkan Anda untuk memastikan kualitasnya. Ini mungkin tampak lebih cepat jika semua perubahan segera berlaku untuk repositori utama, tetapi pada kenyataannya ini hanya akan menjadi sakit kepala besar, karena Anda akan memiliki bangunan utama perangkat lunak Anda yang tidak stabil dan tidak dapat digunakan.

Ini juga merupakan hal yang baik bahwa "jika terjadi konflik penggabungan, masalahnya ada pada pengembang lain" - khususnya, pengembang tingkat yang lebih tinggi harus menjadi orang yang memutuskan bagaimana menyelesaikan konflik.

Ketika Anda memiliki sesuatu yang besar dan (sebagai akibatnya) tidak dapat dikelola, jalan keluar adalah membaginya menjadi bagian-bagian yang lebih kecil dan dapat dikelola.

Ada beberapa langkah yang akan membantu Anda mempertahankan tim dan proyek dengan lebih baik:

1. membagi fungsionalitas menjadi beberapa modul. Fungsionalitas harus dibagi menjadi modul maksimal independen menggunakan prinsip kohesi tinggi, kopling rendah dan inversi ketergantungan. Prinsip pertama akan membantu Anda membuat modul yang konsisten secara logis. Yang kedua akan membantu menjaga modul-modul ini sebebas mungkin. Yang ketiga akan membantu mengembangkan modul dependen secara bersamaan (jika modul A tergantung pada modul B, B harus menyediakan antarmuka yang A dapat digunakan bahkan ketika B tidak sepenuhnya siap).

2. memiliki dokumentasi yang jelas. Ketika ada begitu banyak orang yang bekerja bersama, berbagai hal dapat dengan mudah dilupakan atau disalahpahami. Jadi, Anda perlu memberi perhatian khusus pada semua dokumentasi mulai dari persyaratan hingga solusi arsitektur.

3. orang untuk tugas (tidak pernah tugas untuk orang). Setelah membagi fungsi menjadi set yang lebih kecil, buat tim untuk mengerjakan set ini. Membuat tim akan lebih mudah pada tahap ini, karena Anda sudah tahu apa yang harus dikerjakan masing-masing tim. Dan tugas-tugas seperti ulasan kode akan dilakukan di dalam masing-masing tim.

4. sistem tugas yang jelas. Masing-masing dari 200 pengembang harus jelas tahu apa yang harus dikerjakan. Ini akan membantu Anda melacak apa yang sudah dilakukan, apa yang dikerjakan setiap orang dan berapa banyak pekerjaan yang tersisa.

5. kontrol sumber. (Saya pikir ini diuraikan dalam jawaban lain dengan cukup baik)))

Dan akhirnya, coba buat sesederhana mungkin struktur tim dan modul. Anda tidak bisa mendapatkan kompleksitas dengan proyek sebesar ini.

Selain jawaban lain yang menyarankan struktur hierarkis: yang menyiratkan Anda harus menjadwalkan poin 'integrasi' di waktu di mana fokus sepenuhnya pada peningkatan kode dalam hierarki dan 'menyatukan semuanya'. Ini tidak jauh berbeda dari proyek yang lebih kecil dengan fase akhir di mana tidak ada pekerjaan lain yang dilakukan selain pengujian dan perbaikan bug, hanya lebih sering. Karena Anda bekerja dalam kelompok besar yang berjuang untuk standar tinggi, sebagian besar dari itu (kerangka berpikir) mungkin sudah ada di tempatnya.

Selain jawaban hotpotato (yang langsung pada tanda IMHO), saya juga menyarankan menerapkan beberapa gerbang kontrol sumber, seperti yang Anda sarankan. Ketika kami memindahkan tim besar dan basis kode ke git untuk SCM, kami memutuskan untuk menggunakan apa yang disebut metode "diktator baik hati", mirip dengan model yang Anda jelaskan.

Dalam skenario ini ada banyak berbagai cabang basis kode lengkap yang secara teratur diperbarui dari cabang sumber mereka, tetapi tanggung jawab untuk mempromosikan kode ke area yang lebih terlihat / publik terletak pada satu orang (atau sekelompok kecil orang), dan biasanya terkait dengan proses peninjauan kode. Dengan struktur percabangan yang terorganisasi dengan baik, ini dapat bekerja dengan BENAR-BENAR baik. Untuk informasi lebih lanjut, lihat tautan ini .

Saya telah bekerja pada sistem besar yang memiliki beberapa ratus pengembang bekerja secara bersamaan dengan sekitar 150M SLOC. Ini pada mainframe, jadi kita tidak berbicara Visual Studio, tetapi prinsip-prinsipnya masih dapat diadopsi.

Pertama-tama, jika Anda menggunakan Java, saya pasti akan mengatakan menggunakan Maven. Jika Anda menggunakan VS, Anda juga bisa menggunakan Nuget meskipun saya tidak yakin apakah ada di sana dengan Maven (itu juga agak berbeda). Menggunakan sistem seperti ini akan memungkinkan Anda untuk menarik dependensi Anda dan memungkinkan mereka untuk berfungsi secara individual. Anda akan memiliki skrip build yang menarik dependensi yang relevan dan build sebagai batch.

Mengingat Anda tidak secara langsung mengajukan pertanyaan tetapi meminta metodologi, saya akan memberi tahu Anda bagaimana majikan saya sebelumnya menanganinya.

Sistem dipecah menjadi beberapa kelompok . Cluster mewakili area bisnis dan area infrastruktur sistem. Saya tidak akan menyebutkan nama mereka, tetapi untuk bisnis ritel besar Anda dapat memikirkan hal-hal seperti pemasaran, operasi ritel, operasi online, pengadaan, distribusi. Infrastruktur sistem mewakili hal-hal seperti pelanggan dan keamanan. Dalam setiap cluster, ada komponen . Dengan menggunakan analogi sebelumnya, Anda dapat mempertimbangkan komponen keamanan misalnya - sistem masuk tunggal, layanan direktori, audit, pelaporan, dll. Setiap komponen memiliki rutinitas relatifnya yang tersimpan di dalamnya.

Sebagai namespace atau paket, Anda akan memiliki Organisation.Security.DirectoryServices, misalnya. Dengan memuat semua logika ke area yang relevan, tim bekerja cukup mandiri. Jelas proyek-proyek besar yang membutuhkan masukan dari banyak tim terjadi tetapi sebagian besar operasi mereka lancar.

Saya harap ini membantu.