โครงการ Ledger Live Monorepo: ตอนที่ 1 – ปัญหา (ทำให้เจ็บปวด) | บัญชีแยกประเภท

ในซีรีส์โพสต์บนบล็อกนี้ Valentin De Almeida นักพัฒนา Ledger Live พูดถึงเราผ่านวิวัฒนาการของโค้ดเบส Ledger Live ในช่วงหลายปีที่ผ่านมา ในบล็อกโพสต์นี้ คุณจะได้เรียนรู้ว่าในตอนแรกใช้พื้นที่เก็บข้อมูลหลายพื้นที่ ปัญหาที่เราพบระหว่างทาง และเหตุใดจึงจำเป็นต้องพัฒนาเป็นสถาปัตยกรรมที่เก็บข้อมูลเดี่ยว ในบล็อกโพสต์ถัดไป เราจะอธิบายว่าโครงการย้ายข้อมูลหลักนี้ดำเนินไปอย่างไร 

ประวัติเล็กน้อย 

การเติบโตของ Ledger ในปี 2020 และ 2021 มีความสำคัญ เราคัดเลือกผู้มีความสามารถหน้าใหม่อย่างจริงจัง โดยขยายทีมของเราจากนักพัฒนาเพียงไม่กี่คนเป็นนักพัฒนามากกว่า 20 คน ซึ่งหมายความว่ามีวิศวกรหน้าใหม่จำนวนมากเข้ามาร่วมงานในโครงการที่มีอยู่ เมื่อทีมของเราเติบโตอย่างรวดเร็ว เราก็พบกับความท้าทายใหม่ๆ ที่ต้องแก้ไขอย่างรวดเร็ว แม้จะมีความยากลำบากใหม่ๆ เหล่านี้ แต่เรายังคงมุ่งเน้นไปที่เป้าหมายของเราและยังคงส่งมอบผลงานที่ยอดเยี่ยมอย่างต่อเนื่อง

เราย้อนกลับไปดูปัญหาใหม่ๆ ที่เกิดขึ้นเมื่อมีคนเข้าร่วมโครงการมากขึ้นเรื่อยๆ ท่ามกลางความท้าทายใหม่เหล่านั้น เราสามารถระบุความต้องการดังต่อไปนี้:

• กระแสง่ายขึ้น
• แนวทางที่ดีกว่าสำหรับผู้มีส่วนร่วมทั้งภายในและภายนอก
• ชุดเครื่องมือแบบครบวงจร
• การจัดการการพึ่งพาที่ดีขึ้น
• การมีส่วนร่วมโอเพ่นซอร์สแบบรวมศูนย์

ความทันสมัย: ก่อนการโยกย้าย

ในตอนแรกและจนถึงปีที่แล้ว Ledger Live ใช้สถาปัตยกรรม Poly-Repository สำหรับทั้งส่วนหน้าบนมือถือและเดสก์ท็อป รวมถึงตรรกะทั้งหมดที่อยู่เบื้องหลัง การตัดสินใจทำงานในลักษณะนี้ไม่ใช่การตัดสินใจอย่างมีสติ แต่เป็นเพียงผลลัพธ์ของโครงการที่กำลังขยายตัวโดยไม่มีผู้นำทางสถาปัตยกรรมอย่างแท้จริง Ledger Live เป็นโปรเจ็กต์ที่รวบรวมองค์ประกอบต่างๆ ไว้ในที่เดียวเพื่อมอบแอปที่ดีที่สุดและปลอดภัยที่สุดให้กับผู้ใช้ Nano ของเรา และสะท้อนให้เห็นในโค้ดเบส

กระแสที่เรามีอยู่นั้นไม่สม่ำเสมอ ส่วนใหญ่เป็นเพราะเราเป็นนักพัฒนา 6 หรือ 7 คนเมื่อสองสามปีก่อน เนื่องจากฝ่ายต่างๆ มีส่วนร่วมน้อย การสื่อสารจึงง่ายขึ้นมากและเราก็ผ่านพ้นไปได้ อย่างไรก็ตาม วิธีการทำงานของเรายังมีจุดบกพร่องอยู่บ้าง โดยเฉพาะอย่างยิ่งเกี่ยวกับประสบการณ์ของนักพัฒนาและกระบวนการเผยแพร่

ปัญหาคอขวดของประสบการณ์ Dev

การอ้างอิง

เนื่องจากลักษณะของโครงการของเรา เราจึงทำงานบนที่เก็บข้อมูลหลายแห่งในเวลาเดียวกัน โดยมีการพึ่งพาระหว่างที่เก็บข้อมูลเหล่านั้น นี่คือภาพรวมโดยย่อ:

ไลบรารีโอเพ่นซอร์สของ Ledger ถูกใช้โดยตรรกะทางธุรกิจ ซึ่งจากนั้นจะถูกใช้โดยทั้งแอปเดสก์ท็อปและมือถือ แต่แอปเหล่านั้นยังใช้ไลบรารีโอเพ่นซอร์สด้วย และใช้ไลบรารีเดียวกันสองเวอร์ชันที่แตกต่างกัน (เช่น @ledgerhq/errors เช่น) จะทำให้แอปเสียหาย

เราจำเป็นต้องชนเวอร์ชันในด้านหนึ่ง จากนั้นเผยแพร่ไลบรารี่ (ใช่ ถึง npm!!!) จากนั้นลองอีกครั้งหากไม่ได้ผล เราเริ่มที่จะพึ่งพา yalc ไปยังโครงการ symlink ซึ่งส่วนใหญ่ก็โอเคตราบใดที่เราไม่มีการพึ่งพาหลายชั้น (เช่น จากไลบรารีโอเพ่นซอร์สไปจนถึงตรรกะทางธุรกิจ และจากตรรกะทางธุรกิจไปยังแอป) เราพยายามทำงานด้วยอย่างไม่แน่นอน yarn link เช่นกัน แต่ดูเหมือนว่า React Native จะถึงวาระแล้ว

การทดสอบ

แทบจะเป็นไปไม่ได้เลยที่จะทำการทดสอบบูรณาการกับโค้ดล่าสุดทั้งหมดจากโปรเจ็กต์ต่างๆ เนื่องจากเราจำเป็นต้องเผยแพร่ไลบรารีไปยังรีจิสทรี การทดสอบส่วนประกอบทั้งหมดด้วยโค้ดล่าสุดจึงถือเป็นฝันร้าย

นอกจากนี้เรายังต้องรักษา CI หลายรายการด้วยตรรกะที่ซ้ำกัน

การสลับบริบท

การเคลื่อนย้ายตัวแก้ไขโค้ด / โปรเจ็กต์ / ไดเร็กทอรีหลาย ๆ ตัวอยู่เสมอทำให้ประสบการณ์ dev ดูอ่อนแอมาก

ปล่อยกระบวนการคอขวด

รุ่น

การจัดการการกำหนดเวอร์ชันของโปรเจ็กต์ต่างๆ นั้นทำได้ยาก โดยเฉพาะอย่างยิ่งเมื่อมีการขึ้นต่อกันหลายเลเยอร์

การปล่อย

การติดตามการเผยแพร่มีความซับซ้อนเนื่องจากโปรเจ็กต์ถูกแยกออก และเราต้องจัดการการเผยแพร่ของโปรเจ็กต์ต่างๆ

เป็นไปไม่ได้ที่จะทำให้กระบวนการเผยแพร่เป็นแบบอัตโนมัติอีกครั้ง เนื่องจากโปรเจ็กต์ถูกแบ่งออกเป็นที่เก็บข้อมูลที่แตกต่างกัน

และแน่นอนว่าการส่งมอบอย่างต่อเนื่องเป็นเรื่องที่คิดไม่ถึงในตอนนี้

ทางออกที่เป็นไปได้ ?

เมื่อมองไปรอบ ๆ เพื่อหาแรงบันดาลใจ ดูเหมือนว่าสถาปัตยกรรมพื้นที่เก็บข้อมูลเดี่ยวเป็นส่วนสำคัญที่เราขาดหายไป มันจะช่วยให้กระบวนการพัฒนาดีขึ้นมาก มีเครื่องมือที่สร้างขึ้นรอบสถาปัตยกรรมนี้ที่จะช่วยให้เราบรรลุส่วนที่ขาดหายไป (การเผยแพร่ ระบบอัตโนมัติ การกำหนดเวอร์ชัน…)

แต่ mono repository คืออะไร?

โดยแก่นแท้แล้ว พื้นที่เก็บข้อมูลแบบโมโนคือโปรเจ็กต์ที่รวบรวมโปรเจ็กต์ที่เกี่ยวข้องอื่นๆ ทั้งหมด (แอปพลิเคชัน ไลบรารี เครื่องมือ) ไว้ใต้โฟลเดอร์เดียว / โปรเจ็กต์ git ช่วยให้การจัดการการพึ่งพาที่ดีขึ้น การทำให้เครื่องมือเป็นแบบเดียวกัน (เช่น สไตล์โค้ดและการกำหนดค่า typescript) การรวมแบบต่อเนื่องแบบรวมศูนย์ การทดสอบการรวม เวอร์ชันที่เหมือนกันของแพ็คเกจที่ใช้แล้ว (ตัวอย่างปฏิกิริยา)

เนื่องจากเป็นระบบที่ค่อนข้างไม่เชื่อเรื่องพระเจ้า คุณลักษณะบางอย่างจึงเหลือให้เราค้นพบและนำไปใช้ หวังว่าจะมีเครื่องมือชุมชนที่ยอดเยี่ยมที่สามารถช่วยให้เราเพิ่มการเรียบเรียงให้กับบิวด์ (บิวด์ตามลำดับ มีประโยชน์สำหรับ CI) การกำหนดเวอร์ชัน การสร้างบันทึกการเปลี่ยนแปลง.. ซึ่งจะทำให้สิ่งที่เราขาดหายไปในกระบวนการรีลีสของเราสมบูรณ์

จุดด้อย

พื้นที่เก็บข้อมูลแบบ Mono เหมาะสมในบริบทที่นักพัฒนาหลายคนหรือทีมนักพัฒนาทำงานในหลายโครงการในเวลาเดียวกัน โดยมีการพึ่งพาระหว่างกัน อย่างไรก็ตาม จะเพิ่มความซับซ้อนอีกชั้นในระหว่างขั้นตอนการตั้งค่า (โดยเฉพาะอย่างยิ่งกับโครงการที่ดำเนินการอยู่แล้วซึ่งมีประวัติยาวนานถึง 4 ปีและการพัฒนาที่กระตือรือร้น) คุ้มค่าที่จะกล่าวถึง โปรเจ็กต์นี้มีขนาดใหญ่ขึ้นมาก (เช่น ใหญ่กว่านี้มาก) ในแง่ของพื้นที่ดิสก์ ขณะนี้โครงการทั้งหมดอยู่ภายใต้โฟลเดอร์เดียวกันและการอ้างอิงทั้งหมด การทดสอบใดบ้างที่บังคับ? เมื่อใดที่จะกระตุ้นพวกเขา?

ข้อดี

หลังจากประเมินเวลา ต้นทุน และความเป็นไปได้ตามความทะเยอทะยานของเราแล้ว ต่อไปนี้คือประโยชน์ที่คาดว่าจะได้รับจากการเปลี่ยนแปลงครั้งนี้:

• การจัดการการพึ่งพาที่ได้รับการปรับปรุง: ด้วย monorepo ทำให้ง่ายต่อการจัดการการพึ่งพาระหว่างโปรเจ็กต์ต่างๆ เนื่องจากสิ่งเหล่านั้นทั้งหมดถูกเก็บไว้ในที่เก็บข้อมูลเดียวกัน ซึ่งสามารถลดความจำเป็นในการแก้ปัญหา เช่น การต่อเส้นด้ายหรือ yalcและทำให้ง่ายขึ้นเพื่อให้แน่ใจว่าโปรเจ็กต์ทั้งหมดใช้เวอร์ชันการขึ้นต่อกันที่ถูกต้อง
• การจัดระเบียบโค้ดที่ดีขึ้น: monorepo ช่วยให้การจัดระเบียบโค้ดง่ายขึ้น เนื่องจากโปรเจ็กต์ทั้งหมดและการขึ้นต่อกันของโปรเจ็กต์ทั้งหมดจะถูกจัดเก็บไว้ในที่เก็บข้อมูลเดียว เป็นการง่ายกว่าที่จะเข้าใจว่าโปรเจ็กต์ต่างๆ เข้ากันได้อย่างไรและขึ้นอยู่กับแต่ละโปรเจ็กต์อย่างไร
• ประสบการณ์นักพัฒนาที่ได้รับการปรับปรุง: monorepo ช่วยให้นักพัฒนาทำงานในหลาย ๆ โปรเจ็กต์ได้ง่ายขึ้น เนื่องจากพวกเขาไม่จำเป็นต้องสลับระหว่างโค้ดเบสหรือที่เก็บข้อมูลที่แตกต่างกัน นอกจากนี้ยังช่วยให้รันการทดสอบการรวมระบบได้ง่ายขึ้น เนื่องจากโค้ดทั้งหมดถูกจัดเก็บไว้ในที่เก็บข้อมูลเดียวกัน
• ระบบอัตโนมัติที่ได้รับการปรับปรุงและการส่งมอบอย่างต่อเนื่อง: ด้วย monorepo ทำให้งานอัตโนมัติ เช่น การสร้าง การทดสอบ และการปล่อยโค้ดทำได้ง่ายขึ้น ซึ่งสามารถช่วยปรับปรุงกระบวนการเผยแพร่และทำให้ดำเนินการจัดส่งอย่างต่อเนื่องได้ง่ายขึ้น
• เพิ่มความเร็วในการพัฒนา เนื่องจากทีมต่างๆ ทำงานในพื้นที่เก็บข้อมูลเดียวกัน พวกเขาจึงไม่ต้องรอจนกว่าจะมีการเปิดตัวเพื่อตรวจสอบผลลัพธ์ ซึ่งจะช่วยเร่งการบูรณาการ

สรุป

โดยรวมแล้ว การใช้โครงสร้าง monorepo สามารถช่วยปรับปรุงกระบวนการพัฒนา ปรับปรุงกระบวนการเผยแพร่ และปรับปรุงประสบการณ์ของนักพัฒนาได้

ในบล็อกโพสต์ถัดไปของซีรี่ส์นี้ เราจะอธิบายให้คุณทราบว่าโครงการย้ายข้อมูลที่สำคัญนี้ดำเนินไปอย่างไร เครื่องมือที่เราใช้ ตัวเลือกที่เราทำ ผลลัพธ์ และอื่นๆ อีกมากมาย คอยติดตามส่วนที่ 2: เครื่องมือ!

---

วาเลนติน เด อัลเมดา
ประสบการณ์นักพัฒนาและเทคโนโลยีหลัก – Ledger Live

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
• ที่มา: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain