Terjemahan artikel sing disiapake kanggo siswa kursus "Praktik lan alat DevOps" ing proyek pendidikan OTUS.

Sampeyan kudu milih monorepository amarga prilaku sing dipromosikan ing tim sampeyan yaiku transparansi lan tanggung jawab bareng, utamane nalika tim tuwuh. Apa wae, sampeyan kudu nandur modal ing perkakas, nanging luwih apik yen prilaku standar minangka prilaku sing dikarepake ing prentah sampeyan.

Yagene kita ngomong babagan iki?

Matt Klein nulis artikel kasebut "Monorepos: Mangga aja!"  (cathetan penerjemah: terjemahan ing Habré "Monorepositories: monggo aja"). Aku seneng karo Matt, aku rumangsa pinter lan sampeyan kudu maca sudut pandange. Dheweke asline ngirim polling ing Twitter:

Terjemahan:
Dina Taun Anyar iki, aku arep mbantah babagan monorepositori sing ora lucu. 2019 diwiwiti kanthi sepi. Ing semangat iki, aku menehi sampeyan survey. Sapa sing fanatik gedhe? Panyengkuyung:
- Monorepo
- Rust
- Jajak pendapat sing salah / loro-lorone

Wangsulanku yaiku, "Aku sejatine wong loro kasebut." Tinimbang ngomong babagan carane Rust minangka obat, ayo dipikirake kenapa aku rumangsa salah babagan monorepositori. A sethitik babagan dhewe. Aku CTO saka Chef Software. Kita duwe kira-kira 100 insinyur, basis kode bali babagan 11-12 taun, lan 4 produk utama. Sawetara kode iki ana ing polyrepository (posisi wiwitanku), sawetara ana ing monorepository (posisiku saiki).

Sadurunge miwiti: saben argumen sing dakkandhakake ing kene bakal ditrapake kanggo rong jinis repositori. Ing mratelakake panemume, ora ana alesan teknis apa sampeyan kudu milih siji jinis repositori liyane. Sampeyan bisa nggawe pendekatan apa wae. Aku seneng kanggo pirembagan bab iku, nanging aku ora kasengsem ing alasan technical Ponggawa kok siji luwih unggul liyane.

Aku setuju karo bagean pisanan saka titik Matt:

Amarga ing skala, monorepository bakal ngatasi kabeh masalah sing padha polyrepository solves, nanging ing wektu sing padha meksa sampeyan tightly saperangan kode lan mbutuhake luar biasa efforts kanggo nambah kaukur saka sistem kontrol versi.

Sampeyan kudu ngatasi masalah sing padha preduli saka milih monorepository utawa polyrepository. Kepiye sampeyan ngeculake rilis? Apa pendekatan sampeyan kanggo nganyari? Kompatibilitas mundur? Ketergantungan lintas proyek? Apa gaya arsitektur sing bisa ditampa? Kepiye sampeyan ngatur infrastruktur bangunan lan uji coba? Dhaptar ora telas. Lan sampeyan bakal ngrampungake kabeh nalika sampeyan tuwuh. Ora ana keju gratis.

Aku mikir bantahan Matt padha karo tampilan sing dituduhake dening akeh insinyur (lan manajer) sing aku hormati. Iki kedadeyan saka sudut pandang insinyur sing nggarap komponen utawa tim sing nggarap komponen kasebut. Sampeyan krungu kaya:

• Basis kode akeh banget - aku ora butuh kabeh sampah iki.
• Luwih angel kanggo nyoba amarga aku kudu nyoba kabeh sampah sing ora dibutuhake.
• Luwih angel nggarap dependensi eksternal.
• Aku butuh sistem kontrol versi virtual dhewe.

Mesthine, kabeh poin kasebut dibenerake. Iki kedadeyan ing loro kasus - ing polyrepository aku duwe sampah dhewe, saliyane sing dibutuhake kanggo mbangun ... Aku uga butuh sampah liyane. Dadi aku "mung" nggawe alat sing mriksa kabeh proyek. Utawa aku nggawe monorepository palsu karo submodules. Kita bisa mlaku-mlaku ing saindhenging dina. Nanging aku mikir bantahan Matt ora kejawab alesan utama, sing dakkarepake banget kanggo monorepository:

Iku provokes komunikasi lan nuduhake masalah

Nalika kita misahake repositori, kita nggawe masalah de facto babagan koordinasi lan transparansi. Iki cocog karo cara kita mikir babagan tim (utamane cara anggota individu mikir babagan dheweke): kita tanggung jawab kanggo komponen tartamtu. Kita kerja ing isolasi relatif. Watesan ditemtokake ing timku lan komponen sing lagi ditindakake.

Minangka arsitektur dadi luwih rumit, siji tim ora bisa ngatur maneh piyambak. Sawetara insinyur duwe kabeh sistem ing sirahe. Ayo dadi ngomong sampeyan ngatur komponen sambungan A sing digunakake dening Tim B, C, lan D. Tim A refactoring, nambah API, lan uga ngganti implementasine internal. Akibaté, owah-owahan ora kompatibel mundur. Apa saran sampeyan?

• Golek kabeh panggonan ngendi API lawas digunakake.
• Apa ana papan ing ngendi API anyar ora bisa digunakake?
• Apa sampeyan bisa ndandani lan nyoba komponen liyane kanggo mesthekake yen ora rusak?
• Apa tim iki bisa nyoba owah-owahan sampeyan saiki?

Wigati dimangerteni manawa pitakonan kasebut ora gumantung saka jinis repositori. Sampeyan kudu golek tim B, C lan D. Sampeyan kudu ngomong karo wong-wong mau, golek wektu, ngerti prioritas. Ing paling kita ngarep-arep sampeyan bakal.

Ora ana sing pengin nindakake iki. Iki luwih nyenengake tinimbang mung ndandani API. Iku kabeh manungsa lan kacau. Ing polyrepository, sampeyan mung bisa nggawe owah-owahan, menehi wong sing nggarap komponen kasebut (mbokmenawa ora B, C utawa D) kanggo ditinjau, lan nerusake. Tim B, C lan D mung bisa tetep nganggo versi saiki. Dheweke bakal dianyari yen dheweke ngerti genius sampeyan!

Ing monorepository, tanggung jawab dipindhah kanthi standar. Tim A ngganti komponèn lan, yen ora ati-ati, langsung break B, C lan D. Iki ndadékaké kanggo B, C lan D muncul ing lawang A, pemikiran kok Team A nyuwil perakitan. Iki mulang A sing padha ora bisa skip dhaftar sandi ndhuwur. Dheweke kudu ngomong babagan apa sing bakal ditindakake. Apa B, C lan D bisa pindhah? Apa yen B lan C bisa, nanging D ana hubungane karo efek samping saka prilaku algoritma lawas?

Banjur kita kudu ngomong babagan carane bisa metu saka kahanan iki:

1. Dhukungan kanggo macem-macem API internal, lan bakal menehi tandha algoritma lawas minangka ora digunakake nganti D bisa mandheg nggunakake.
2. Dhukungan kanggo macem-macem versi rilis, siji karo antarmuka lawas, siji karo anyar.
3. Tundha release saka owah-owahan A nganti B, C, lan D bisa bebarengan nampa.

Ayo dadi ngomong kita wis milih 1, sawetara API. Ing kasus iki, kita duwe rong potongan kode. Lawas lan anyar. Cukup trep ing sawetara kahanan. We mriksa kode lawas bali ing, tandhani minangka deprecated, lan setuju jadwal aman karo tim D. Ateges podho rupo kanggo repositori poli lan mono.

Kanggo ngeculake pirang-pirang versi, kita butuh cabang. Saiki kita duwe rong komponen - A1 lan A2. Tim B lan C nggunakake A2 lan D nggunakake A1. Kita mbutuhake saben komponen siap diluncurake amarga nganyari keamanan lan perbaikan bug liyane bisa uga dibutuhake sadurunge D bisa maju. Ing polyrepository, kita bisa ndhelikake iki ing cabang dawa sing dirasakake. Ing monorepository, kita meksa kode digawe ing modul anyar. Tim D isih kudu ngganti komponen "lawas". Saben uwong bisa ndeleng biaya sing kita bayar ing kene - saiki kita duwe kode kaping pindho, lan perbaikan bug sing ditrapake kanggo A1 lan A2 kudu ditrapake kanggo loro-lorone. Kanthi pendekatan cabang ing polyrepository, iki didhelikake ing mburi cherry-pick. Kita nganggep biaya luwih murah amarga ora ana duplikasi. Saka sudut pandang praktis, biayane padha: sampeyan bakal mbangun, ngeculake, lan njaga rong basis kode sing meh padha nganti sampeyan bisa mbusak salah sijine. Bentenipun yaiku kanthi monorepositori nyeri iki langsung lan katon. Iki malah luwih elek, lan sing apik.

Pungkasan, kita entuk titik katelu. Rilis wektu tundha. Bisa uga owah-owahan sing ditindakake dening A bakal nambah urip Tim A. Penting, nanging ora penting. Apa kita mung bisa tundha? Ing polyrepository, kita push iki kanggo pin artefak. Mesthi kita ngandhani Tim D. Mung tetep ing versi lawas nganti sampeyan nyekel! Iki nggawe sampeyan muter pengecut. Tim A terus nggarap komponen, ora nggatekake kasunyatan manawa Tim D nggunakake versi sing saya suwe (iku masalah Tim D, dheweke bodho). Sauntara kuwi, Tim D ngomong kanthi ora becik babagan sikap ceroboh Tim A marang stabilitas kode, yen padha ngomong babagan iki. Sasi liwat. Akhire, Tim D mutusaké dipikir ing kamungkinan nganyari, nanging A mung owah-owahan liyane. Tim A lagi wae ngelingi nalika utawa carane padha nyuwil D. Nganyarke luwih nglarani lan bakal njupuk maneh. Kang ngirim luwih mudhun tumpukan prioritas. Nganti dina kita duwe masalah keamanan ing A sing meksa kita nggawe cabang. Tim A kudu bali ing wektu, golek titik nalika D stabil, ndandani masalah ana, lan nggawe siap kanggo release. Iki minangka pilihan de facto sing ditindakake wong, lan iki minangka sing paling awon. Iku misale jek dadi apik kanggo loro Tim A lan Tim D anggere kita bisa nglirwakake saben liyane.

Ing monorepository, katelu pancen dudu pilihan. Sampeyan dipeksa kanggo ngatasi kahanan ing salah siji saka rong cara. Sampeyan kudu ndeleng biaya duwe rong cabang release. Sinau kanggo nglindhungi dhewe saka nganyari sing ngilangi kompatibilitas mundur. Nanging sing paling penting: sampeyan ora bisa ngindhari obrolan sing angel.

Ing pengalamanku, nalika tim dadi gedhe, ora bisa ngelingi kabeh sistem, lan sing paling penting. Sampeyan kudu nambah visibilitas perselisihan ing sistem. Sampeyan kudu aktif supaya tim katon adoh saka komponen lan ndeleng karya tim lan konsumen liyane.

Ya, sampeyan bisa nggawe alat sing nyoba ngatasi masalah polyrepository. Nanging pengalaman saya mulang pangiriman lan otomatisasi terus-terusan ing perusahaan gedhe ngandhani iki: prilaku standar tanpa nggunakake alat tambahan yaiku prilaku sing dikarepake. Prilaku standar saka polyrepository yaiku isolasi, iku kabeh. Prilaku standar monorepository yaiku tanggung jawab lan transparansi sing dienggo bareng, mula kabeh iki. Ing kasus loro, aku arep nggawe alat sing bakal Gamelan metu sudhut atos. Minangka pimpinan, aku bakal milih monorepository saben wektu amarga alat kasebut kudu nguatake budaya sing dakkarepake, lan budaya asale saka keputusan cilik lan kerja tim saben dinane.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Sapa sing fanatik paling gedhe? Panyengkuyung:

• Monorepo

• Rust

• Jajak pendapat sing salah / loro-lorone

33 pangguna milih. 13 pangguna abstain.

Source: www.habr.com