Bagaimana cara mencapai transisi yang mulus dari model organisasi “satu-satunya repositori VCS besar untuk semua produk” ke model “banyak repositori VCS kecil”?

Ini adalah skenario umum bahwa basis kode dari suatu produk yang dipegang oleh repositori di beberapa sistem VCS berevolusi ke titik di mana basis kode itu dapat dilihat sebagai mengandung beberapa produk. Memisahkan basis kode di beberapa repositori VCS, masing-masing didedikasikan untuk satu produk, dapat memanfaatkan beberapa manfaat (lihat Manfaat memiliki produk per repositori VCS atas model repositori mengasapi di bawah). Di sisi teknis, pemisahan basis kode adalah langkah yang agak mudah karena kebanyakan VCS mendukung operasi ini. Namun pemisahan ini dapat menimbulkan masalah teknis terkait dengan pengujian otomatis, pengiriman berkelanjutan, integrasi atau pemantauan layanan (lihat Masalah yang diangkat oleh pemisahan tersebut.) Organisasi yang berencana melakukan pemisahan seperti itu perlu tahu bagaimana melakukan transisi ini semulus mungkin, yaitu, tanpa mengganggu pengiriman dan pemantauan pipa mereka. Langkah pertama ini mungkin untuk lebih memahami gagasan proyek dan bagaimana menggambarkan pemisahan dalam basis kode monolitik.

Dalam jawaban atas pertanyaan ini, saya ingin melihat:

1. Upaya untuk memberikan definisi yang berfungsi tentang apa produk itu, yang memberikan kriteria praktis untuk benar-benar menggambarkan produk dalam basis kode yang ada.

2. Menurut definisi kerja ini, uraikan rencana yang benar-benar melakukan pemisahan. Kita dapat membuat asumsi penyederhanaan bahwa basis kode diproses oleh sdlc sepenuhnya otomatis yang menerapkan integrasi berkelanjutan dan pengiriman kontinu . Yaitu, setiap cabang divalidasi oleh suatu testuite otomatis yang diimplementasikan dalam basis kode saat ini dan masing-masing bergabung ke beberapa cabang "ajaib" menghasilkan artefak produk yang diuji dan digunakan. ( Artefak Produk yang misalnya tarball sumber, dokumentasi, paket perangkat lunak biner, Docker gambar, Amis, unikernels.)

3. Rencana seperti itu memuaskan jika menjelaskan cara untuk menghindari

Masalah yang diangkat oleh perpecahan

1. Bagaimana prosedur pengujian otomatis berhubungan dengan repositori monolitik yang sudah ada sebelumnya dan repositori split?

2. Bagaimana prosedur penyebaran otomatis terkait dengan repositori monolitik yang sudah ada sebelumnya dan repositori split?

3. Di mana disimpan kode untuk prosedur penyebaran otomatis sendiri?

4. Di mana infrastruktur tersimpan , pemantauan , dan strategi ketersediaan tinggi ?

5. Bagaimana memastikan bahwa pengembang hanya membutuhkan satu basis kode pada satu waktu (tetapi mungkin menggunakan artefak dari basis kode lain).

6. Bagaimana alat seperti git-membagi dua

Catatan marjinal: Manfaat memiliki produk per repositori VCS atas model repositori mengasapi

Memiliki beberapa repositori kecil yang memegang basis kode untuk produk tertentu memiliki keuntungan sebagai berikut atas pendekatan "repositori bloat":

1. Dengan repositori mengasapi sulit untuk memutar kembali rilis ketika suatu produk tidak stabil, karena sejarah dicampur dengan riwayat produk lainnya.

2. Dengan repositori mengasapi, sulit untuk meninjau riwayat proyek atau penarikan, dengan repositori kecil, kami lebih cenderung membaca informasi ini. (Ini mungkin khusus untuk VCS seperti git, di mana tidak seperti svn, kami tidak dapat checkout subtrees!)

3. Dengan repositori mengasapi, kita harus melakukan lebih banyak tarian cabang ketika kita berkembang. Jika kita memiliki repositori N, kita dapat bekerja secara paralel pada cabang N, jika kita hanya memiliki 1 repositori, kita hanya dapat bekerja pada satu cabang, atau memiliki banyak copy pekerjaan yang juga sulit untuk ditangani.

4. Dengan beberapa repositori kecil, log memberikan peta panas proyek. Mereka bahkan dapat digunakan sebagai proksi difusi pengetahuan dalam tim pengembang: jika saya tidak melakukan dalam repo X sejak 3 bulan, mungkin lebih baik untuk menugaskan saya dalam tim yang mengerjakan repo X sehingga saya tetap mengetahui perkembangannya. dalam komponen itu.

5. Dengan repositori kecil, lebih mudah mendapatkan gambaran umum yang jelas tentang suatu komponen. Jika semuanya berjalan dalam satu repositori besar, tidak ada artefak nyata yang menggambarkan setiap komponen, dan basis kode dapat dengan mudah melayang ke arah bola lumpur yang besar .

6. Gudang kecil memaksa kita untuk bekerja pada antarmuka antar komponen. Tetapi karena kita ingin memiliki kapsul yang baik, ini adalah pekerjaan yang harus kita lakukan, jadi saya akan menghitung ini sebagai keuntungan untuk repositori kecil.

7. Dengan beberapa repositori kecil, lebih mudah memiliki beberapa pemilik produk.

8. Dengan beberapa repositori kecil, lebih mudah untuk memiliki standar kode sederhana yang berkaitan dengan repositori penuh dan yang dapat diverifikasi secara otomatis.

Ini adalah pertanyaan yang menarik yang jawaban sebenarnya mungkin tidak ada; Saya menghargai bahwa ketika Anda mencoba untuk menjaga pertanyaan dikontekstualisasikan pada VCS, itu secara alami ditingkatkan dengan sendirinya hingga desain infrastruktur dan perencanaan implementasi.

Meskipun, tampaknya banyak dari kita yang bekerja dalam transisi semacam ini, yang bisa mengasyikkan, tetapi pada saat yang sama sangat membuat frustrasi dan menyakitkan; dan saya ingin berbagi pengalaman dan pandangan saya, berusaha untuk tidak menjadi orang yang bertele-tele, dan hanya karena saya mungkin bukan insinyur yang baik, juga tidak membosankan.

Rancangan

Infrastruktur dan arsitektur harus berjalan bersama untuk menulis perangkat lunak modern. Digabungkan erat, jika Anda mau. Mungkin kedengarannya aneh menggunakan kata-kata itu, tetapi kita tidak tentu berbicara tentang kode itu sendiri di sini: Maksud saya mereka harus menjadi bagian dari cetak biru yang sama. Ketika awan datang, dan orang-orang mulai menulis perangkat lunak untuk mereka, berapa banyak orang kemudian menyadari bahwa dengan menempatkan bola-bola lumpur di sana, mereka hanya akan menjadi bola-bola lumpur yang sama di tempat yang berbeda (?) Mungkin beberapa orang yang berpikir ke depan dapat meramalkan itu, dan mereka kemungkinan bekerja di devops hari ini. Karena para devops hanyalah sebuah kata kunci dengan begitu banyak makna yang berbeda untuk orang-orang yang berbeda, saya telah melihat tempat-tempat di mana tim devops akan duduk di setiap pertemuan arsitektur; tempat-tempat lain di mana hanya otomasi. Untuk mencapai transformasi semacam ini, kita harus berjuang untuk duduk di sana.

Kepercayaan

Transisi harus tetap terisolasi, dalam arti bahwa potongan sejarah yang konsisten harus ada, yang menyediakan transisi itu sendiri dan dirinya sendiri saja, tanpa perubahan lain (setelah beberapa bulan persiapan). Dengan keyakinan apa orang akan menyetujuinya dan menekan tombol merah?

Maksud saya basis kode harus berubah untuk mengakomodasi struktur VCS baru, dan akan sangat sulit untuk tetap digabung selama pengembangan. (untuk masalah ini mungkin ada strategi fasilitasi, saya akan berbicara tentang yang umum nanti, yang dapat membantu menyejajarkan pembangunan sedikit).

Yah aku bertaruh satu-satunya cara adalah dengan pengujian perilaku, dan serangkaian tes perilaku yang sama harus diluncurkan untuk memverifikasi yang lama dengan basis kode baru. Kami tidak memverifikasi aplikasi berperilaku seperti yang diharapkan di sini, tetapi transisi tidak mengubah perilaku. Memiliki tes yang gagal mungkin merupakan hal yang baik! Jika mereka terus gagal!

Kenyataannya sangat jarang bola lumpur diuji dengan baik; biasanya kode ini sangat erat digabungkan, dan kemungkinan, untuk sebagian besar kode warisan, itu tidak dikembangkan dengan pendekatan uji coba, bahkan tidak tes unit.

Jika kode pengujian tersebut tidak ada, kode ini harus ditulis terlebih dahulu.

Strategi

Ya, transisi harus tetap terisolasi; tetapi pada saat yang sama terintegrasi. Saya tahu saya mungkin terdengar gila di sini, tetapi saya tidak akan menemukan kata-kata lain untuk menggambarkan bagaimana kepercayaan diri dapat mengikuti perkembangan bisnis. Sangat sedikit, jika tidak ada sama sekali, perusahaan ingin menghentikan pengembangan untuk basis kode monolitik besar, untuk memberikan ruang bagi transisi ini, dan kami tidak mewujudkannya hanya dalam lemparan koin. Mungkin ratusan pengembang mungkin terus berkontribusi pada basis kode (saya akan menggunakan kata gangguan di sini, dari POV kami). Sementara pekerjaan kita harus membahas snapshot khusus untuk memberikan kepercayaan diri, kita harus menjaga diri kita tetap tegar (tidak dalam arti git di sini), untuk menghindari tertinggal selamanya.

Strategi implementasi di sini dapat memberikan pengalaman yang berbeda. Garis umum pengembangan adalah untuk membungkus / mengadaptasi (memperlihatkan titik akhir dengan skema yang diatur ulang secara opsional) cabang implementasi yang lebih baru (well, tinggal di repositori lain dalam kasus ini), ketika mereka perlu berinteraksi dengan inti. Transisi dengan strategi seperti ini, bersama dengan refactoring, dapat sekaligus menawarkan skenario POC untuk transisi VCS, dan kemudian pada pendekatan langkah demi langkah. Lihat itu seperti memahat bola lumpur. Ya, hidup menawarkan begitu banyak hal lucu.

Utang Teknis

Lingkup manajemen bisnis mulai memahami utang teknis dan mempertimbangkannya. Tidak, goreskan itu, tidak benar. Meskipun semakin umum untuk mengumpulkan data pengukuran dan kualitas, dalam hal analisis kode statis, tinjauan kode, hasil tes perilaku, dan kinerja, dan menghasilkan laporan yang bagus dan semuanya ... masih tetap sangat sulit untuk membuat bisnis menerima kontinu pendekatan refactoring. Nilai bisnisnya . "Kami sedang mengikuti proses yang gesit, dan ini tidak akan membawa peningkatan pada fitur, bukan?" . Pada dasarnya, dengan melakukan itu mereka meniadakan keberadaan hutang teknis. Saya melihat ini sebagai langkah umum yang hilang yang diperlukan untuk dapat memulai transisi dari monolith ke arsitektur layanan mikro.

Reagregasi

Setelah semua ini, Anda mungkin masih ingin memberikan tampilan seperti repositori di mana Anda dapat membangun lebih dari satu produk. Untuk alasan apa pun, mis. Arus / rilis berikutnya, multibrand, build pelanggan. Alat seperti google repo dapat membantu dalam kasus ini. Tidak pernah menggunakannya sendiri, tetapi saya tahu saya perlu satu hari.

Tes integrasi

Dengan layanan microser, pengujian integrasi mengasumsikan konteks yang berbeda, "pengujian API sendiri". Lapisan pengujian yang lebih tinggi, fungsional atau kinerja, dapat dan akan ada, tetapi apakah mereka sangat berarti tanpa pengujian integrasi yang tepat? Ini akan seperti memiliki pengujian integrasi tanpa pengujian unit. Tentu saja tidak. Itu sebabnya, jika Anda perlu git membagi dua, Anda akan menjalankannya di cabang repositori microservice, lupakan tentang menjalankannya di repositori mudball.

PS. ini konsep, bahasa Inggris saya buruk dan saya akan memperbaikinya suatu hari