Proyek Ledger Live Monorepo: Bagian 1 – Masalah (Membuatnya Menyakitkan) | buku besar

Dalam seri postingan blog ini, Valentin De Almeida, pengembang Ledger Live, menjelaskan kepada kita tentang evolusi basis kode Ledger Live selama bertahun-tahun. Dalam postingan blog ini, Anda akan mempelajari bahwa ini pada awalnya berbasis multi-repositori, masalah yang kami temui selama ini, dan mengapa perlu berevolusi menjadi arsitektur mono-repositori. Pada postingan blog berikutnya, kami akan menjelaskan bagaimana proyek migrasi besar ini dilakukan. 

Sedikit sejarah 

Pertumbuhan Ledger pada tahun 2020 dan 2021 cukup signifikan. Kami secara agresif merekrut talenta baru, memperluas tim kami dari hanya segelintir menjadi lebih dari 20 pengembang. Ini berarti banyak insinyur baru yang terlibat dalam proyek yang sudah ada. Seiring pertumbuhan tim kami yang pesat, kami menghadapi tantangan baru yang harus segera kami atasi. Meskipun terdapat kesulitan-kesulitan baru ini, kami tetap fokus pada tujuan kami dan terus memberikan hasil kerja yang luar biasa.

Kami mengambil langkah mundur dan melihat permasalahan baru yang muncul ketika semakin banyak orang yang ikut serta dalam proyek ini. Di antara tantangan-tantangan baru tersebut, kami dapat menyebutkan kebutuhan-kebutuhan berikut:

• Aliran yang lebih sederhana.
• Pedoman yang lebih baik untuk kontributor masuk dan eksternal.
• Seperangkat alat terpadu.
• Manajemen ketergantungan yang lebih baik.
• Kontribusi sumber terbuka terpusat.

Canggih: sebelum migrasi

Awalnya, dan hingga tahun lalu, Ledger Live didasarkan pada arsitektur poli-repositori, baik untuk front-end seluler maupun desktop, serta semua logika di baliknya. Ini bukanlah sebuah keputusan sadar untuk bekerja dengan cara ini, tapi ini hanyalah hasil dari perluasan proyek tanpa petunjuk arsitektur yang nyata. Ledger Live adalah proyek yang mengumpulkan berbagai komponen menjadi satu untuk menghadirkan aplikasi terbaik dan teraman bagi pengguna Nano kami, dan ini tercermin dalam basis kode.

Alur yang kami miliki tidak stabil, sebagian besar disebabkan oleh fakta bahwa kami adalah 6 atau 7 pengembang beberapa tahun yang lalu. Karena lebih sedikit pihak yang terlibat, komunikasi menjadi lebih mudah dan kami lolos begitu saja. Namun, masih ada beberapa kendala dalam cara kami bekerja, terutama seputar pengalaman pengembang dan proses rilis.

Kemacetan Pengalaman Pengembang

Dependensi

Karena sifat proyek kami, kami mengerjakan beberapa repositori secara bersamaan, dengan ketergantungan di antara keduanya. Berikut ini ikhtisar singkatnya:

Pustaka sumber terbuka Ledger digunakan oleh logika bisnis, yang kemudian digunakan oleh aplikasi desktop dan seluler. Namun aplikasi tersebut juga menggunakan pustaka sumber terbuka, dan menggunakan dua versi berbeda dari pustaka yang sama (seperti @ledgerhq/errors misalnya) akan merusak aplikasi.

Kami perlu meningkatkan versinya di satu sisi, lalu menerbitkan perpustakaannya (ya, ke npm!!!), lalu coba lagi jika tidak berhasil. Kami mulai mengandalkan yalc untuk menghubungkan proyek-proyek, yang sebagian besar baik-baik saja selama kita tidak memiliki beberapa lapisan ketergantungan (misalnya, dari perpustakaan sumber terbuka ke logika bisnis, dan kemudian dari logika bisnis ke aplikasi). Kami untuk sementara mencoba bekerja sama yarn link juga, tapi sepertinya sudah hancur dengan React Native.

pengujian

Hampir tidak mungkin melakukan pengujian integrasi dengan semua kode terbaru dari berbagai proyek. Karena kami perlu mempublikasikan perpustakaan ke registri, menguji semua komponen dengan kode terkini adalah mimpi buruk

Kami juga harus memelihara beberapa CI dengan logika duplikat.

Pengalihan Konteks

Selalu berpindah-pindah beberapa editor kode/proyek/direktori membuat pengalaman pengembang terlihat sangat lemah.

Kemacetan Proses Rilis

Versi

Menangani pembuatan versi proyek yang berbeda itu sulit, terutama ketika ada beberapa lapisan ketergantungan.

Melepaskan

Pelacakan rilis menjadi rumit karena fakta bahwa proyek dipecah, dan kami harus mengelola rilis proyek yang berbeda

Tidak mungkin untuk mengotomatiskan proses rilis, sekali lagi karena fakta bahwa proyek dipecah menjadi repositori yang berbeda.

Dan tentu saja, Pengiriman Berkelanjutan tidak terpikirkan pada saat ini.

Solusi yang Mungkin?

Mencari inspirasi, tampaknya arsitektur repositori mono adalah bagian utama yang kami lewatkan. Hal ini akan memungkinkan proses pembangunan yang jauh lebih baik. Ada alat yang dibangun berdasarkan arsitektur ini yang akan membantu kami mencapai bagian yang hilang (rilis, otomatisasi, pembuatan versi…).

Tapi, apa itu repositori mono?

Pada intinya, repositori mono adalah proyek yang merangkum semua proyek terkait lainnya (aplikasi, perpustakaan, alat) dalam satu folder/proyek git. Hal ini memungkinkan manajemen ketergantungan yang lebih baik, penyeragaman alat (seperti gaya kode dan konfigurasi skrip), Integrasi Berkelanjutan terpusat, pengujian integrasi, versi seragam dari paket yang digunakan (bereaksi misalnya)…

Karena ini adalah sistem yang cukup agnostik, beberapa fitur tersisa untuk kami temukan dan terapkan. Mudah-mudahan, ada beberapa alat komunitas hebat yang dapat membantu kami menambahkan orkestrasi ke build (build berurutan, berguna untuk CI), pembuatan versi, pembuatan log perubahan.. yang akan melengkapi apa yang kami lewatkan dalam proses rilis.

Kekurangan

Repositori mono masuk akal dalam konteks di mana beberapa pengembang, atau tim pengembang mengerjakan beberapa proyek secara bersamaan, dengan ketergantungan di antara mereka. Namun, hal ini menambah beberapa lapisan kompleksitas selama fase penyiapan (terutama dengan proyek yang sudah berjalan dan memiliki sejarah 4 tahun dan pengembangan aktif). Perlu disebutkan, proyek ini menjadi jauh lebih besar (seperti jauh lebih besar) dalam hal ruang disk. Semua proyek sekarang berada di bawah folder yang sama dan semua dependensi. Tes apa yang wajib? Kapan harus memicunya?

Pro

Setelah mengevaluasi waktu, biaya, dan kelayakan ambisi kami, berikut beberapa manfaat yang diharapkan dari transisi ini:

• Peningkatan manajemen ketergantungan: Dengan monorepo, lebih mudah untuk mengelola ketergantungan antar proyek yang berbeda, karena semuanya disimpan dalam repositori yang sama. Hal ini dapat mengurangi kebutuhan akan solusi seperti penghubung benang atau yalc, dan mempermudah memastikan bahwa semua proyek menggunakan versi dependensi yang benar.
• Organisasi kode yang lebih baik: Monorepo dapat mempermudah pengorganisasian kode, karena semua proyek dan dependensinya disimpan dalam satu repositori. Lebih mudah untuk memahami bagaimana proyek-proyek yang berbeda cocok satu sama lain dan bagaimana mereka saling bergantung satu sama lain.
• Peningkatan pengalaman pengembang: Monorepo dapat memudahkan pengembang mengerjakan banyak proyek, karena mereka tidak perlu beralih di antara basis kode atau repositori yang berbeda. Ini juga dapat mempermudah menjalankan pengujian integrasi, karena semua kode disimpan dalam repositori yang sama.
• Otomatisasi yang ditingkatkan dan pengiriman berkelanjutan: Dengan monorepo, lebih mudah untuk mengotomatiskan tugas-tugas seperti membuat, menguji, dan merilis kode. Hal ini dapat membantu menyederhanakan proses rilis dan mempermudah penerapan pengiriman berkelanjutan.
• Peningkatan kecepatan pengembangan. Karena tim yang berbeda bekerja di repositori yang sama, mereka tidak perlu menunggu hingga rilis untuk memverifikasi hasilnya, sehingga mempercepat integrasi.

Kesimpulan

Secara keseluruhan, penerapan struktur monorepo dapat membantu meningkatkan proses pengembangan, menyederhanakan proses rilis, dan meningkatkan pengalaman pengembang.

Dalam postingan blog berikutnya dalam seri ini, kami akan memandu Anda tentang bagaimana proyek migrasi besar ini dilaksanakan, alat yang kami gunakan, pilihan yang kami buat, hasilnya, dan banyak lagi. Nantikan Bagian 2: Alatnya!

---

Valentin DE ALMEIDA
Pengalaman Pengembang & Teknologi Inti – Ledger Live

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• Sumber: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain