Ledger Live Monorepo Projesi: Bölüm 1 – Sorunlar (Acı Verin) | Defter

Bu blog yazısı dizisinde Ledger Live geliştiricisi Valentin De Almeida, bize Ledger Live kod tabanının yıllar içindeki evrimini anlatıyor. Bu blog yazısında, başlangıçta çoklu depo tabanlı olduğunu, yol boyunca karşılaştığımız sorunları ve neden tek depolu bir mimariye dönüşmesi gerektiğini öğreneceksiniz. Sonraki blog yazılarımızda bu büyük geçiş projesinin nasıl yürütüldüğünü anlatacağız. 

Biraz tarih 

Ledger'ın 2020 ve 2021'deki büyümesi önemliydi. Agresif bir şekilde yeni yetenekleri işe aldık ve ekibimizi sadece bir avuçtan 20'nin üzerinde geliştiriciye genişlettik. Bu, mevcut projelere çok sayıda yeni mühendisin katıldığı anlamına geliyor. Ekibimiz hızla büyüdükçe hızla çözmemiz gereken yeni zorluklarla karşılaştık. Bu yeni zorluklara rağmen hedefimize odaklanmayı sürdürdük ve olağanüstü işler ortaya koymaya devam ettik.

Bir adım geri attık ve giderek daha fazla insanın projeye katılmasıyla ortaya çıkan yeni sorunlara baktık. Bu yeni zorluklar arasında aşağıdaki ihtiyaçları sıralayabiliriz:

• Daha basit akışlar
• Gelen ve dış katkıda bulunanlar için daha iyi yönergeler.
• Birleşik bir araç seti.
• Daha iyi bağımlılık yönetimi.
• Merkezi açık kaynak katkıları.

Son Teknoloji: geçişten önce

Başlangıçta ve geçen yıla kadar Ledger Live, hem mobil hem de masaüstü ön uçlar ve bunun arkasındaki mantık için çoklu veri havuzu mimarisine dayanıyordu. Bu şekilde çalışmak bilinçli bir karar değildi, ancak gerçek bir mimari ipucu olmadan yalnızca genişleyen bir projenin sonucuydu. Ledger Live, Nano kullanıcılarımıza en iyi ve en güvenli uygulamayı sunmak için çeşitli bileşenleri bir araya getiren bir projedir ve kod tabanına da yansımıştır.

Birkaç yıl önce 6 veya 7 geliştirici olmamızdan dolayı, sahip olduğumuz akışlar en iyi ihtimalle düzensizdi. Daha az taraf olduğu için iletişim çok daha kolay oldu ve biz de bundan kurtulduk. Yine de çalışma şeklimizde, özellikle de geliştirici deneyimi ve sürüm süreciyle ilgili bazı sıkıntılı noktalar vardı.

Geliştirici Deneyimi Darboğazları

Bağımlılıklar

Projelerimizin doğası gereği, aralarında bağımlılıklar bulunan birden fazla depo üzerinde aynı anda çalışıyoruz. İşte hızlı bir genel bakış:

Ledger açık kaynak kitaplıkları iş mantığı tarafından kullanılır ve bu daha sonra hem masaüstü hem de mobil uygulamalar tarafından kullanılır. Ancak bu uygulamalar aynı zamanda açık kaynak kitaplıklarını ve aynı kitaplığın iki farklı sürümünü (örneğin @ledgerhq/errors örneğin) uygulamayı bozar.

Sürümü bir kenara koymamız, ardından kitaplıkları yayınlamamız (evet, npm'ye!!!) ve işe yaramazsa yeniden denememiz gerekiyordu. güvenmeye başladık yalc sembolik bağlantı projelerine, ki bu da birkaç bağımlılık katmanına sahip olmadığımız sürece (örneğin, açık kaynak kitaplıklardan iş mantığına ve ardından iş mantığından uygulamalara) çoğunlukla sorun değildi. Geçici olarak birlikte çalışmaya çalıştık yarn link aynı zamanda, ancak React Native ile mahkum olmuş gibi görünüyor.

Test yapmak

Farklı projelerdeki en son kodlarla entegrasyon testleri yapmak neredeyse imkansızdı. Kitaplıkları kayıt defterinde yayınlamamız gerektiğinden, tüm bileşenleri en son güncel kodla test etmek bir kabustu

Ayrıca çoğaltılmış mantıkla birkaç CI'yi sürdürmek zorunda kaldık.

Bağlam Değiştirme

Her zaman birkaç kod düzenleyicinin/projenin/dizin arasında dolaşmak, geliştirme deneyiminin gerçekten zayıf görünmesine neden oldu.

Serbest Bırakma Sürecindeki Darboğazlar

Sürüm

Farklı projelerin versiyonlarını yönetmek, özellikle de birden fazla bağımlılık katmanı olduğunda zordur.

Releasing

Projelerin bölünmüş olması nedeniyle sürüm takibi karmaşıktı ve farklı projelerin sürümlerini yönetmek zorunda kaldık

Yine projelerin farklı havuzlara bölünmüş olması nedeniyle yayın sürecini otomatikleştirmek imkansızdı.

Ve elbette Sürekli Teslimat bu noktada düşünülemezdi.

Olası çözüm ?

İlham almak için etrafa baktığımızda, tek bir depo mimarisinin, kaçırdığımız temel parça olduğu görülüyor. Çok daha iyi bir geliştirme sürecine olanak tanıyacaktır. Eksik parçaları (sürüm, otomasyon, sürüm oluşturma…) gerçekleştirmemize yardımcı olacak, bu mimari etrafında oluşturulmuş araçlar vardır.

Peki mono depo nedir?

Özünde mono depo, diğer tüm ilgili projeleri (uygulamalar, kütüphaneler, araçlar) tek bir klasör / git projesi altında kapsayan bir projedir. Daha iyi bağımlılık yönetimine, araçların tek tipleştirilmesine (kod stilleri ve yazı tipi yapılandırmaları gibi), merkezi Sürekli Entegrasyona, entegrasyon testine, kullanılan paketlerin tek tip sürümüne (örneğin tepki) olanak tanır…

Oldukça agnostik bir sistem olduğu için bazı özellikleri keşfedip uygulamamıza bırakıldı. Umuyoruz ki, sürüm sürecimizde kaçırdığımız şeyleri tamamlayacak sürüm oluşturma, değişiklik günlüğü oluşturma gibi yapılara orkestrasyon eklememize (sıralı yapılar, CI için yararlı) yardımcı olabilecek bazı harika topluluk araçları vardır.

Eksiler

Mono depoları, birkaç geliştiricinin veya bir geliştirici ekibinin aynı anda birden fazla proje üzerinde çalıştığı ve aralarında bağımlılıkların olduğu bir bağlamda anlamlıdır. Ancak kurulum aşamasında bir miktar karmaşıklık katmanı ekler (özellikle 4 yıllık geçmişe ve aktif gelişime sahip halihazırda çalışır durumda olan projelerde). Bahsetmeye değer, proje disk alanı açısından çok daha büyüyor (çok daha büyük). Artık tüm projeler aynı klasör ve tüm bağımlılıklar altındadır. Hangi testler zorunludur? Bunları ne zaman tetiklemeli?

Artılar

Hedeflerimizin süresini, maliyetini ve fizibilitesini değerlendirdikten sonra, bu geçişin beklenen faydalarından bazıları şunlardı:

• Geliştirilmiş bağımlılık yönetimi: Bir monorepo ile, hepsi aynı depoda depolandığından farklı projeler arasındaki bağımlılıkları yönetmek daha kolaydır. Bu, iplik bağlantısı gibi geçici çözümlere olan ihtiyacı azaltabilir veya yalcve tüm projelerin bağımlılıkların doğru sürümlerini kullandığından emin olmayı kolaylaştırın.
• Daha iyi kod organizasyonu: Tüm projeler ve bağımlılıkları tek bir depoda saklandığı için monorepo, kodun organize edilmesini kolaylaştırabilir. Farklı projelerin birbirine nasıl uyduğunu ve birbirlerine nasıl bağımlı olduklarını anlamak daha kolaydır.
• Geliştirilmiş geliştirici deneyimi: Bir monorepo, geliştiricilerin farklı kod tabanları veya depolar arasında geçiş yapması gerekmediği için birden fazla proje üzerinde çalışmasını kolaylaştırabilir. Ayrıca tüm kod aynı depoda saklandığından entegrasyon testlerinin yürütülmesini de kolaylaştırabilir.
• Gelişmiş otomasyon ve sürekli teslimat: Monorepo ile kod oluşturma, test etme ve yayınlama gibi görevleri otomatikleştirmek daha kolaydır. Bu, sürüm sürecini kolaylaştırmaya ve sürekli teslimatın uygulanmasını kolaylaştırmaya yardımcı olabilir.
• Artan geliştirme hızı. Farklı ekipler aynı depoda çalıştığından, sonucu doğrulamak için yayına kadar beklemelerine gerek kalmaz, bu da entegrasyonu hızlandırır.

Sonuç

Genel olarak monorepo yapısının uygulanması, geliştirme sürecinin iyileştirilmesine, sürüm sürecinin kolaylaştırılmasına ve geliştirici deneyiminin geliştirilmesine yardımcı olabilir.

Bu serinin sonraki blog yazılarında, bu büyük geçiş projesinin nasıl yürütüldüğünü, kullandığımız araçları, yaptığımız seçimleri, sonuçları ve daha fazlasını size açıklayacağız. Bölüm 2: Araçlar için bizi izlemeye devam edin!

---

Valentin DE ALMEIDA
Geliştirici Deneyimi ve Temel Teknoloji – Ledger Live

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain