Dự án Ledger Live Monorepo: Phần 1 – Vấn đề (Make it Pain) | Sổ cái

Trong loạt bài đăng trên blog này, Valentin De Almeida, một nhà phát triển Ledger Live, nói chuyện với chúng tôi về quá trình phát triển cơ sở mã Ledger Live qua nhiều năm. Trong bài đăng trên blog này, bạn sẽ biết rằng ban đầu nó dựa trên nhiều kho lưu trữ, các vấn đề chúng tôi gặp phải trong quá trình thực hiện và lý do tại sao nó cần phát triển thành kiến ​​trúc một kho lưu trữ. Trong các bài đăng blog tiếp theo, chúng tôi sẽ giải thích cách thực hiện dự án di chuyển lớn này. 

Một chút lịch sử 

Sự tăng trưởng của Ledger trong năm 2020 và 2021 là rất đáng kể. Chúng tôi tích cực tuyển dụng nhân tài mới, mở rộng đội ngũ của mình từ một số ít lên hơn 20 nhà phát triển. Điều này có nghĩa là rất nhiều kỹ sư mới đã được đưa vào các dự án hiện có. Khi nhóm của chúng tôi phát triển nhanh chóng, chúng tôi gặp phải những thách thức mới mà chúng tôi phải nhanh chóng giải quyết. Bất chấp những khó khăn mới này, chúng tôi vẫn tập trung vào mục tiêu của mình và tiếp tục hoàn thành công việc xuất sắc.

Chúng tôi đã lùi lại một bước và xem xét các vấn đề mới phát sinh khi ngày càng có nhiều người tham gia vào dự án. Trong số những thách thức mới đó, chúng ta có thể liệt kê những nhu cầu sau:

• Dòng chảy đơn giản hơn
• Hướng dẫn tốt hơn cho những người đóng góp trong và ngoài nước.
• Một bộ công cụ thống nhất.
• Quản lý phụ thuộc tốt hơn.
• Đóng góp nguồn mở tập trung.

Công nghệ tiên tiến: trước khi di chuyển

Ban đầu và cho đến năm ngoái, Ledger Live dựa trên kiến ​​trúc nhiều kho lưu trữ, dành cho cả giao diện người dùng trên thiết bị di động và máy tính để bàn, cũng như tất cả logic đằng sau nó. Việc làm theo cách này không phải là một quyết định có ý thức mà nó chỉ là kết quả của một dự án mở rộng không có sự chỉ đạo kiến ​​​​trúc thực sự. Ledger Live là một dự án tập hợp nhiều thành phần khác nhau thành một để cung cấp ứng dụng tốt nhất và an toàn nhất cho người dùng Nano của chúng tôi và điều đó đã được phản ánh trong cơ sở mã.

Các quy trình mà chúng tôi hiện có không ổn định nhất, chủ yếu là do thực tế là cách đây vài năm chúng tôi có 6 hoặc 7 nhà phát triển. Vì có ít bên tham gia hơn nên việc giao tiếp trở nên dễ dàng hơn rất nhiều và chúng tôi đã giải quyết được vấn đề đó. Tuy nhiên, vẫn có một số điểm khó khăn trong cách chúng tôi làm việc, đặc biệt là về trải nghiệm của nhà phát triển và quá trình phát hành.

Điểm nghẽn của trải nghiệm Dev

Sự phụ thuộc

Do tính chất của các dự án, chúng tôi làm việc trên nhiều kho lưu trữ cùng lúc với sự phụ thuộc giữa chúng. Dưới đây là một cái nhìn tổng quan nhanh:

Các thư viện nguồn mở Ledger được sử dụng bởi logic nghiệp vụ, sau đó được sử dụng bởi cả ứng dụng dành cho máy tính để bàn và thiết bị di động. Nhưng những ứng dụng đó cũng sử dụng thư viện nguồn mở và sử dụng hai phiên bản khác nhau của cùng một thư viện (như @ledgerhq/errors chẳng hạn) sẽ làm hỏng ứng dụng.

Chúng tôi cần chuyển phiên bản sang một bên, sau đó xuất bản các thư viện (vâng, lên npm!!!), sau đó thử lại nếu nó không hoạt động. Chúng tôi bắt đầu dựa vào yalc đến các dự án liên kết tượng trưng, ​​điều này hầu như ổn miễn là chúng tôi không có nhiều lớp phụ thuộc (ví dụ: từ thư viện nguồn mở đến logic nghiệp vụ, sau đó từ logic nghiệp vụ đến ứng dụng). Chúng tôi đã thử làm việc với yarn link cũng vậy, nhưng có vẻ như nó đã thất bại với React Native.

Kiểm tra

Gần như không thể thực hiện kiểm tra tích hợp với tất cả mã mới nhất từ ​​các dự án khác nhau. Vì chúng tôi cần xuất bản các thư viện lên cơ quan đăng ký nên việc kiểm tra tất cả các thành phần với mã cập nhật mới nhất là một cơn ác mộng

Chúng tôi cũng phải duy trì một số CI có logic trùng lặp.

Chuyển đổi ngữ cảnh

Luôn phải di chuyển xung quanh một số trình soạn thảo/dự án/thư mục mã khiến trải nghiệm của nhà phát triển trông thực sự yếu kém.

Tắc nghẽn quy trình phát hành

Phiên bản

Việc xử lý phiên bản của các dự án khác nhau là điều khó khăn, đặc biệt khi có nhiều lớp phụ thuộc.

Phát hành

Việc theo dõi phát hành rất phức tạp do các dự án bị chia tách và chúng tôi phải quản lý việc phát hành của các dự án khác nhau

Không thể tự động hóa quá trình phát hành, một lần nữa do các dự án được chia thành các kho lưu trữ khác nhau.

Và tất nhiên, việc Giao hàng liên tục là điều không thể tưởng tượng được vào thời điểm này.

Giải pháp khả thi?

Nhìn xung quanh để tìm cảm hứng, có vẻ như kiến ​​trúc kho lưu trữ đơn sắc là phần trung tâm mà chúng tôi đang thiếu. Nó sẽ cho phép một quá trình phát triển tốt hơn nhiều. Có những công cụ được xây dựng xung quanh kiến ​​trúc này sẽ giúp chúng tôi đạt được những phần còn thiếu (phát hành, tự động hóa, lập phiên bản…).

Tuy nhiên, kho lưu trữ đơn là gì?

Về cốt lõi, kho lưu trữ đơn là một dự án đóng gói tất cả các dự án liên quan khác (ứng dụng, thư viện, công cụ) trong một thư mục/dự án git. Nó cho phép quản lý phụ thuộc tốt hơn, đồng nhất hóa các công cụ (như kiểu mã và cấu hình bản thảo), Tích hợp liên tục tập trung, kiểm tra tích hợp, phiên bản thống nhất của gói đã sử dụng (ví dụ: phản ứng)…

Vì đây là một hệ thống khá bất khả tri nên một số tính năng được để lại cho chúng tôi khám phá và triển khai. Hy vọng rằng có một số công cụ cộng đồng tuyệt vời có thể giúp chúng tôi thêm khả năng phối hợp vào các bản dựng (bản dựng tuần tự, hữu ích cho CI), tạo phiên bản, tạo nhật ký thay đổi.. sẽ hoàn thành những gì chúng tôi còn thiếu trong quá trình phát hành.

Nhược điểm

Kho lưu trữ đơn có ý nghĩa trong bối cảnh trong đó một số nhà phát triển hoặc một nhóm nhà phát triển làm việc trên nhiều dự án cùng lúc với sự phụ thuộc giữa chúng. Tuy nhiên, nó tạo thêm một số lớp phức tạp trong giai đoạn thiết lập (đặc biệt với các dự án đã và đang chạy có 4 năm lịch sử và phát triển tích cực). Điều đáng nói là dự án sẽ lớn hơn nhiều (như lớn hơn rất nhiều) về dung lượng ổ đĩa. Tất cả các dự án hiện nằm trong cùng một thư mục và tất cả các dự án phụ thuộc. Những bài kiểm tra nào là bắt buộc? Khi nào nên kích hoạt chúng?

Ưu điểm

Sau khi đánh giá thời gian, chi phí và tính khả thi của những tham vọng của chúng tôi, đây là một số lợi ích dự kiến ​​của quá trình chuyển đổi này:

• Cải thiện quản lý phần phụ thuộc: Với monorepo, việc quản lý phần phụ thuộc giữa các dự án khác nhau sẽ dễ dàng hơn vì tất cả chúng đều được lưu trữ trong cùng một kho lưu trữ. Điều này có thể làm giảm nhu cầu về các giải pháp thay thế như liên kết sợi hoặc yalcvà giúp dễ dàng hơn trong việc đảm bảo rằng tất cả các dự án đang sử dụng đúng phiên bản phụ thuộc.
• Tổ chức mã tốt hơn: Monorepo có thể giúp tổ chức mã dễ dàng hơn vì tất cả các dự án và phần phụ thuộc của chúng đều được lưu trữ trong một kho lưu trữ duy nhất. Sẽ dễ dàng hơn để hiểu các dự án khác nhau phù hợp với nhau như thế nào và chúng phụ thuộc lẫn nhau như thế nào.
• Cải thiện trải nghiệm của nhà phát triển: Monorepo có thể giúp các nhà phát triển làm việc trên nhiều dự án dễ dàng hơn vì họ không cần phải chuyển đổi giữa các cơ sở mã hoặc kho lưu trữ khác nhau. Nó cũng có thể giúp việc chạy thử nghiệm tích hợp dễ dàng hơn vì tất cả mã được lưu trữ trong cùng một kho lưu trữ.
• Tự động hóa nâng cao và phân phối liên tục: Với monorepo, việc tự động hóa các tác vụ như xây dựng, thử nghiệm và phát hành mã sẽ dễ dàng hơn. Điều này có thể giúp hợp lý hóa quy trình phát hành và giúp triển khai phân phối liên tục dễ dàng hơn.
• Tăng tốc độ phát triển. Vì các nhóm khác nhau làm việc trong cùng một kho lưu trữ nên họ không cần đợi đến khi phát hành để xác minh kết quả, từ đó đẩy nhanh quá trình tích hợp.

Kết luận

Nhìn chung, việc triển khai cấu trúc monorepo có thể giúp cải thiện quá trình phát triển, hợp lý hóa quy trình phát hành và nâng cao trải nghiệm của nhà phát triển.

Trong các bài đăng blog tiếp theo của loạt bài này, chúng tôi sẽ hướng dẫn bạn cách thực hiện dự án di chuyển lớn này, các công cụ chúng tôi đã sử dụng, những lựa chọn chúng tôi đã thực hiện, kết quả, v.v. Hãy theo dõi Phần 2: Các công cụ!

---

Valentin DE ALMEIDA
Trải nghiệm của nhà phát triển & Công nghệ cốt lõi – Ledger Live

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoData.Network Vertical Generative Ai. Trao quyền cho chính mình. Truy cập Tại đây.
• PlatoAiStream. Thông minh Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Trung tâmESG. Than đá, công nghệ sạch, Năng lượng, Môi trường Hệ mặt trời, Quản lý chất thải. Truy cập Tại đây.
• PlatoSức khỏe. Tình báo thử nghiệm lâm sàng và công nghệ sinh học. Truy cập Tại đây.
• nguồn: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain