อัปเกรดเวอร์ชันของรายการที่ต้องใช้

การอัปเกรด Dependency ช่วยให้คุณเข้าถึงฟีเจอร์ การแก้ไขข้อบกพร่อง และการปรับปรุงล่าสุดได้ หากต้องการอัปเกรด Dependency คุณจะต้องเข้าใจวิธีที่ Gradle แก้ปัญหาเกี่ยวกับเวอร์ชันที่คุณขอ ความเสี่ยงที่เกี่ยวข้อง และขั้นตอนที่คุณทำได้เพื่อลดความเสี่ยงเหล่านั้น

พิจารณากลยุทธ์การอัปเกรดของคุณ

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

สร้างห้องสมุด

คุณกำลังสร้างแอปพลิเคชันที่ผู้ใช้ดาวน์โหลดและเรียกใช้ในอุปกรณ์ใช่ไหม หรือคุณกำลังสร้างไลบรารีเพื่อช่วยนักพัฒนาซอฟต์แวร์คนอื่นสร้างแอปพลิเคชันของพวกเขา

หากกำลังสร้างแอปพลิเคชัน คุณควรมุ่งเน้นที่การทำให้แอปพลิเคชันเป็นเวอร์ชันล่าสุดและทำงานได้อย่างเสถียร

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

ประการแรก - ลดทรัพยากร Dependency ของไลบรารีให้น้อยที่สุดเท่าที่จะทำได้ ยิ่งคุณมีทรัพยากร Dependency น้อย ก็ยิ่งส่งผลต่อการแก้ไขปัญหาการขึ้นต่อกันของผู้บริโภคน้อยลง

โปรดปฏิบัติตามการกำหนดเวอร์ชันแบบเซมาติกเพื่อช่วยระบุประเภทการเปลี่ยนแปลงที่คุณทำ ตัวอย่างเช่น AndroidX ใช้การแยกเวอร์ชันแบบเป็นความหมายและเพิ่มรูปแบบการแยกเวอร์ชันรุ่นก่อนเผยแพร่ พยายามหลีกเลี่ยงการอัปเกรดเป็นเวอร์ชัน major เพื่อไม่ให้ผู้บริโภคของคุณใช้งานไม่ได้

ลองสร้างคลังรุ่นที่พร้อมเผยแพร่ (RC) เพื่อให้ผู้ใช้ทดสอบได้ตั้งแต่เนิ่นๆ

ดูรายละเอียดเกี่ยวกับการทำให้ Application Binary Interface (ABI) ของไลบรารีเข้ากันได้อยู่เสมอได้ที่หลักเกณฑ์ความเข้ากันได้แบบย้อนหลังสำหรับผู้เขียนไลบรารี ใช้การทดสอบการผสานรวมและเครื่องมือต่างๆ เช่น โปรแกรมตรวจสอบความเข้ากันได้ของไบนารีเพื่อให้แน่ใจว่าการเปลี่ยนแปลง ABI ของคุณตรงกับการเปลี่ยนแปลงเวอร์ชันที่ต้องการ

หากคุณเผยแพร่การแก้ไขในไลบรารีเวอร์ชัน patch หรือต่ำกว่า ผู้บริโภคไม่จําเป็นต้องอัปเกรดไลบรารีเป็นเวอร์ชัน major หรือ minor ถัดไป เว้นแต่ว่าต้องการฟีเจอร์ใหม่ หลีกเลี่ยงการอัปเกรดทรัพยากร transitive ในการอัปเกรดเหล่านี้

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

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

ช่วงปล่อยเพลง

คุณเผยแพร่แอปพลิเคชันหรือไลบรารีบ่อยแค่ไหน

วงจรการพัฒนาและการเผยแพร่ที่สั้นลง

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

วงจรการพัฒนาและการเผยแพร่ที่นานขึ้น

  • มีเวลาสร้างและทดสอบการอัปเกรดมากขึ้น
  • มีการเผยแพร่เวอร์ชันใหม่ของ Dependency ในช่วงรอบของคุณมากกว่า
  • การย้อนกลับการอัปเกรดและการเผยแพร่แอปพลิเคชันหรือไลบรารีจะใช้เวลานานกว่า

ติดตามฟีเจอร์ล่าสุด

คุณต้องการใช้ฟีเจอร์และ API เวอร์ชันล่าสุดที่มี หรือจะอัปเกรดเฉพาะเมื่อต้องการฟีเจอร์หรือการแก้ไขข้อบกพร่อง

พิจารณาข้อดีข้อเสียของการอัปเกรดบ่อยๆ การอัปเกรดในอนาคตจะง่ายขึ้น (มีการเปลี่ยนแปลงน้อยกว่าในการผสานรวม) แต่คุณจะต้องเสี่ยงกับการอัปเกรดบ่อยขึ้น

การทดสอบการอัปเกรดไลบรารีเป็นเวอร์ชันก่อนเผยแพร่ (อัลฟ่า เบต้า และรุ่นที่อาจได้รับการเผยแพร่) จะช่วยเตรียมความพร้อมเมื่อมีรุ่นเสถียรให้ใช้งาน

ทรัพยากร Dependency ใหม่

หากคุณจะเพิ่มการพึ่งพาใหม่ ให้พิจารณาใช้กระบวนการตรวจสอบที่เข้มงวดซึ่งจะตรวจสอบไลบรารีนั้นเพื่อหาเกณฑ์ความเสี่ยงทั้งหมดเพื่อให้มั่นใจว่าได้รับการประเมินอย่างเหมาะสม ไม่อนุญาตให้เพิ่มการพึ่งพาใหม่โดยไม่ผ่านการตรวจสอบ

ทีมเฉพาะ

คุณมีทีมสร้างโดยเฉพาะไหม วิศวกรซอฟต์แวร์ดูแลรักษาบิลด์ไหม ทีมเฉพาะทางมักจะมีเวลาวิเคราะห์ความเสี่ยงในการอัปเกรดและทดสอบเวอร์ชันใหม่เพื่อให้แน่ใจว่าบิลด์ทํางานได้อย่างถูกต้องก่อนที่วิศวกรจะใช้เวอร์ชันใหม่

ประเภทการอัปเกรด

การอัปเกรดบางอย่างสำคัญกว่าการอัปเกรดอื่นๆ ลองนึกถึงสิ่งที่สำคัญที่สุดสำหรับคุณ

การอัปเกรดเครื่องมือสร้าง เช่น Gradle และปลั๊กอิน Gradle มักส่งผลกระทบต่อผู้ใช้น้อยลง และความเสี่ยงส่วนใหญ่จะอยู่ในบิลด์ของคุณ บิลด์เองจะช่วยตรวจสอบการเปลี่ยนแปลงเหล่านี้ การอัปเกรดไลบรารีและ SDK นั้นตรวจสอบได้ยากกว่าและมีความเสี่ยงต่อผู้ใช้มากกว่า

ปลั๊กอิน Android Gradle (AGP) — เครื่องมือที่ใช้สร้างแอปพลิเคชันหรือไลบรารี Android การอัปเกรดนี้เป็นอัปเกรดที่สำคัญที่สุดที่คุณทำได้ เนื่องจากมักจะมีการปรับปรุงประสิทธิภาพ การแก้ไขข้อบกพร่อง กฎใหม่ของ Lint และการรองรับแพลตฟอร์ม Android เวอร์ชันใหม่

Gradle - คุณมักจะต้องอัปเกรด Gradle เมื่ออัปเกรด AGP หรือปลั๊กอิน Gradle อื่น

ปลั๊กอิน Gradle อื่นๆ — บางครั้ง API ปลั๊กอินของ Gradle มีการเปลี่ยนแปลง เมื่ออัปเกรด Gradle ให้ตรวจสอบการอัปเกรดปลั๊กอินที่คุณใช้

Kotlin และ Java - ไลบรารีและปลั๊กอินบางอย่างต้องใช้ Kotlin หรือ Java เวอร์ชันขั้นต่ำ หรือต้องการใช้ประโยชน์จากฟีเจอร์ภาษาใหม่ๆ, API หรือการปรับปรุงประสิทธิภาพ

แพลตฟอร์ม Android — Play Store กำหนดให้อัปเกรด Android SDK เป็นเวอร์ชันล่าสุดเป็นประจำ คุณควรทดสอบ Android SDK เวอร์ชันใหม่โดยเร็วที่สุด การอัปเกรด SDK บางรายการต้องมีการเปลี่ยนแปลงแอปพลิเคชัน เช่น สิทธิ์ใหม่หรือการใช้ API ใหม่

คลัง — คุณต้องการจัดลําดับความสําคัญของคลังตามความใกล้เคียงกับสถาปัตยกรรมโดยรวมไหม

  • ไลบรารีที่เกี่ยวข้องกับแพลตฟอร์มและสถาปัตยกรรม เช่น AndroidX มักมีการเปลี่ยนแปลงเพื่อใช้ประโยชน์จากฟีเจอร์ใหม่ๆ และช่วยทำการเปลี่ยนแปลงในแพลตฟอร์ม อัปเกรดไลบรารีเหล่านี้อย่างน้อยทุกครั้งที่คุณอัปเกรดแพลตฟอร์ม Android หรือไลบรารีอื่นๆ ที่เกี่ยวข้องกับสถาปัตยกรรม
  • การอัปเกรดไลบรารีอื่นๆ อาจมีการกระจายหรือเลื่อนออกไป เว้นแต่คุณต้องการฟีเจอร์ใหม่หรือการแก้ไขข้อบกพร่องที่เฉพาะเจาะจง

Android Studio — การอัปเดต Android Studio เป็นเวอร์ชันล่าสุดอยู่เสมอจะช่วยให้คุณเข้าถึงฟีเจอร์และการแก้ไขข้อบกพร่องล่าสุดในแพลตฟอร์มและเครื่องมือ IntelliJ IDEA ที่เกี่ยวข้องเพื่อใช้งานกับ Android SDK เวอร์ชันล่าสุด

เครื่องมือที่ใช้ได้

มีเครื่องมือและปลั๊กอินมากมายที่จะช่วยคุณในการอัปเกรด เครื่องมืออย่าง Dependabot และ Renovate จะอัปเกรดเวอร์ชันไลบรารีในบิลด์โดยอัตโนมัติ แต่อย่าลืมวิเคราะห์ผลลัพธ์เพื่อตรวจสอบความเสี่ยง

กลยุทธ์สำหรับการอัปเกรดบางประเภท

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

ความสัมพันธ์และการพึ่งพาของบิลด์
รูปที่ 1 สร้างความสัมพันธ์

เมื่ออัปเกรดคอมโพเนนต์แต่ละประเภท ให้พิจารณาว่าการอัปเกรดจะส่งผลต่อคอมโพเนนต์อื่นๆ ในบิลด์อย่างไร

ปลั๊กอิน Android Gradle (AGP)

Android Studio มีผู้ช่วยอัปเกรด AGP ที่สามารถช่วยเหลือในงานเหล่านี้ได้

หากคุณใช้ผู้ช่วยหรืออัปเกรดด้วยตนเอง โปรดพิจารณาสิ่งต่อไปนี้

ดูที่บันทึกประจำรุ่นของ AGP

อัปเกรด Gradle เป็นเวอร์ชันที่ระบุเป็นอย่างน้อย

อัปเกรด Android Studio เป็นเวอร์ชันที่รองรับเวอร์ชัน AGP ที่เลือก

ใช้ Android Studio และ AGP เวอร์ชันที่รองรับ Android SDK ที่ต้องการใช้

ตรวจสอบความเข้ากันได้กับเครื่องมือสร้าง SDK, NDK และ JDK

หากคุณพัฒนาปลั๊กอิน Gradle (สำหรับใช้ภายในหรือสาธารณะ) ที่ขยายหรือใช้ข้อมูลจาก AGP ให้ตรวจสอบว่าจำเป็นต้องอัปเกรดปลั๊กอินหรือไม่ บางครั้ง AGP จะเลิกใช้งานและนํา API ออกในภายหลัง ซึ่งทําให้ใช้งานร่วมกับปลั๊กอินก่อนหน้าไม่ได้

คอมไพเลอร์ ภาษา และรันไทม์ของ Kotlin

โปรดดูปัญหาที่ทราบและฟังก์ชันที่ทำงานร่วมกับ Kotlin ไม่ได้ในบันทึกประจำรุ่นของ Kotlin

หากใช้ Jetpack Compose ให้ทำดังนี้

หากคุณใช้การประมวลผลสัญลักษณ์ Kotlin (KSP) โปรดดูเริ่มต้นใช้งาน KSP อย่างรวดเร็วสำหรับการตั้งค่าและรุ่น KSP สำหรับเวอร์ชันที่ใช้ได้ โปรดทราบว่าคุณต้องใช้ KSP เวอร์ชันที่ตรงกับเวอร์ชัน Kotlin เช่น หากคุณใช้ Kotlin 2.0.21 คุณจะใช้ปลั๊กอิน KSP เวอร์ชันใดก็ได้ที่ขึ้นต้นด้วย 2.0.21 เช่น 2.0.21-1.0.25 โดยปกติแล้วคุณไม่จำเป็นต้องอัปเกรดตัวประมวลผล KSP (เช่น คอมไพเลอร์ Room ซึ่งปรากฏเป็น ksp ที่ต้องพึ่งพาในไฟล์บิลด์) เนื่องจากปลั๊กอิน KSP จะแยก API คอมไพเลอร์ส่วนใหญ่ออก และ KSP API ที่ใช้โดยตัวประมวลผลจะเสถียร

อัปเกรดปลั๊กอิน Kotlin Compiler อื่นๆ ทั้งหมดที่คุณใช้อยู่ Kotlin Compiler Plugin API มีการเปลี่ยนแปลงบ่อยครั้งระหว่างรุ่นต่างๆ และปลั๊กอินต้องใช้ API ที่เข้ากันได้ หากปลั๊กอินแสดงอยู่ในปลั๊กอินคอมไพเลอร์ คุณต้องใช้เวอร์ชันเดียวกับคอมไพเลอร์ Kotlin สําหรับปลั๊กอินการคอมไพล์อื่นๆ โปรดดูการแมปที่เหมาะสมในเอกสารประกอบ

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

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

ปลั๊กอินคอมไพเลอร์ Kotlin

หากต้องการอัปเกรดปลั๊กอินคอมไพเลอร์ Kotlin ให้อัปเกรดเป็น Kotlin เวอร์ชันที่ใช้อยู่

ปลั๊กอินคอมไพเลอร์ Kotlin ส่วนใหญ่จะใช้เวอร์ชันเดียวกับคอมไพเลอร์ Kotlin หรือเริ่มต้นด้วยคอมไพเลอร์ Kotlin เวอร์ชันที่จำเป็น เช่น หากเวอร์ชันของปลั๊กอินคือ 2.0.21-1.0.25 คุณต้องใช้คอมไพเลอร์ Kotlin เวอร์ชัน 2.0.21

บางครั้งการเปลี่ยนเวอร์ชันคอมไพเลอร์ Kotlin จะต้องมีการเปลี่ยนแปลงอื่นๆ

ห้องสมุด

ไลบรารีเป็นทรัพยากรที่ต้องอัปเกรดบ่อยที่สุดในบิลด์ คุณจะเห็นการอัปเกรดที่ใช้ได้ในเครื่องมือแก้ไขของ Android Studio หรือเมื่อใช้เครื่องมือและปลั๊กอินที่ต้องพึ่งพาบางรายการ

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

ไลบรารีบางแห่งยังระบุเวอร์ชัน Kotlin ขั้นต่ำสำหรับการใช้งานด้วย อัปเดตเวอร์ชัน Kotlin ในไฟล์บิลด์เป็นเวอร์ชันที่ระบุไว้เป็นอย่างน้อย

Gradle

บางครั้ง Gradle เวอร์ชันใหม่จะเลิกใช้งาน API ที่มีอยู่และนำ API เหล่านั้นออกในรุ่นถัดไป หากคุณพัฒนาปลั๊กอิน Gradle ให้อัปเกรดปลั๊กอินโดยเร็วที่สุด โดยเฉพาะหากปลั๊กอินนั้นเป็นแบบสาธารณะ

การอัปเกรด Gradle บางรายการกำหนดให้ต้องค้นหาปลั๊กอินเวอร์ชันใหม่ที่คุณใช้ โปรดทราบว่าปลั๊กอินเหล่านี้อาจล้าสมัยในการพัฒนาเนื่องจากมีการอัปเกรดปลั๊กอินให้ตรงกับ API ของปลั๊กอิน Gradle เวอร์ชันล่าสุด

วิธีอัปเกรด Gradle

  • อ่านบันทึกประจำรุ่นของเวอร์ชันที่คุณต้องการใช้
  • อัปเกรดเวอร์ชัน Gradle ใน gradle/wrapper/gradle-wrapper.properties
  • อัปเกรดไฟล์ jar และสคริปต์ของ Gradle Wrapper โดยเรียกใช้ ./gradlew wrapper --gradle-version latest
  • อัปเกรดปลั๊กอิน Gradle
  • อัปเกรด JDK ที่ใช้เรียกใช้ Gradle

ปลั๊กอิน Gradle

ในบางครั้ง ปลั๊กอิน Gradle ที่อัปเกรดแล้วจะใช้ Gradle API ใหม่หรือที่เปลี่ยนแปลงไป ซึ่งทำให้ต้องอัปเกรด Gradle หรืออาจต้องเปลี่ยนแปลงการกำหนดค่าในไฟล์บิลด์ ไม่ว่าในกรณีใด คุณจะเห็นคำเตือนหรือข้อผิดพลาดเกี่ยวกับบิลด์เพื่อบ่งบอกถึงความเข้ากันไม่ได้

อัปเกรด Gradle ทุกครั้งที่อัปเกรดปลั๊กอิน

Android SDK

Android Studio มีผู้ช่วยอัปเกรด Android SDK ที่ช่วยทำงานเหล่านี้ได้

หากคุณใช้ผู้ช่วยหรืออัปเกรดด้วยตนเอง โปรดพิจารณาสิ่งต่อไปนี้

SDK ของ Android แต่ละรุ่นมีฟีเจอร์และ API ใหม่ การแก้ไขข้อบกพร่อง และการเปลี่ยนแปลงลักษณะการทํางาน Play Store กำหนดให้อัปเดต targetSdk แต่ให้พิจารณาอัปเดต targetSdk ก่อนกำหนดเวลาเพื่อให้มีเวลาทำการเปลี่ยนแปลงที่จำเป็นมากขึ้น

โปรดอ่านบันทึกประจำรุ่นอย่างละเอียดก่อนอัปเกรด Android SDK โปรดดูที่ส่วนการเปลี่ยนแปลงลักษณะการทำงาน ซึ่งมีรายละเอียดดังนี้

  • สิทธิ์ใหม่ที่คุณจะต้องขอเมื่อติดตั้งหรือรันไทม์
  • API ที่เลิกใช้งานแล้วและการเปลี่ยนแทน
  • ทำลายการเปลี่ยนแปลงของ API หรือลักษณะการทำงาน
  • API ใหม่ของ Kotlin หรือ Java ซึ่งอาจส่งผลต่อโค้ดของคุณ

ส่วนการเปลี่ยนแปลงลักษณะการทํางานอาจยาวมาก แต่โปรดอ่านอย่างละเอียดเนื่องจากส่วนนี้มักจะมีการเปลี่ยนแปลงที่สําคัญซึ่งคุณต้องทํากับแอปพลิเคชัน

คุณต้องอัปเกรด targetSdk ให้เป็นไปตามข้อกำหนดของ Play Store การอัปเกรด compileSdk เป็นการดำเนินการที่ไม่บังคับ ซึ่งจะช่วยให้คุณเข้าถึง API ใหม่ๆ ได้ โปรดทราบว่าไลบรารีบางรายการ เช่น AndroidX มีข้อกำหนดขั้นต่ำ compileSdk

หากต้องการใช้ประโยชน์จากฟีเจอร์ใหม่ของ SDK ในระหว่างการพัฒนาและตรวจสอบความเข้ากันได้ระหว่างการสร้าง ให้อัปเกรดปลั๊กอิน Android Gradle (AGP) และ Android Studio ซึ่งรวมถึงเครื่องมือใหม่และเครื่องมือที่ได้รับการปรับปรุงสำหรับ SDK ใหม่ ดูเวอร์ชันขั้นต่ำของเครื่องมือสำหรับระดับ API ของ Android

เมื่ออัปเกรด Android SDK ให้อัปเกรดไลบรารี AndroidX ที่คุณใช้ด้วย AndroidX มักใช้ API ใหม่และที่อัปเดตแล้วเพื่อให้ใช้งานร่วมกันได้และมีประสิทธิภาพมากขึ้นใน Android SDK แต่ละเวอร์ชัน

Android Studio

โดยทั่วไปแล้ว คุณจะอัปเกรด Android Studio ได้ทุกเมื่อ คุณอาจเห็นข้อความแจ้งให้อัปเกรด AGP หรืออัปเกรด Android SDK ขอแนะนำอย่างยิ่งให้ใช้การอัปเกรดเหล่านี้ แต่ก็ไม่บังคับ

หากต้องการใช้ Android Studio เพื่ออัปเกรด AGP หรือ Android SDK ในภายหลัง ก็ค้นหาตัวเลือกเหล่านี้ได้ในเมนูเครื่องมือ

Java

หากคุณมีซอร์สโค้ดของ Java ในแอปพลิเคชัน Android คุณอาจต้องใช้ประโยชน์จาก Java API รุ่นใหม่

Android SDK แต่ละเวอร์ชันรองรับชุดย่อยของ Java API และฟีเจอร์ภาษา AGP รองรับการใช้งานร่วมกับ Android SDK เวอร์ชันที่ต่ำกว่าโดยใช้กระบวนการที่เรียกว่า desugaring

บันทึกประจำรุ่นของ Android SDK ระบุระดับของ Java ที่รองรับและปัญหาที่อาจเกิดขึ้น ปัญหาเหล่านี้บางส่วนอาจส่งผลต่อซอร์สโค้ดของ Kotlin ด้วยเช่นกัน เนื่องจาก Kotlin มีสิทธิ์เข้าถึง Java API เดียวกัน โปรดอ่านส่วน JDK API ที่ปรากฏในส่วนการเปลี่ยนแปลงด้านลักษณะการทํางานของบันทึกประจำรุ่นอย่างละเอียด แม้ว่าคุณจะไม่มีซอร์สโค้ด Java ก็ตาม

การใช้งาน JDK จะระบุไว้ในหลายตำแหน่งในสคริปต์บิลด์ ดูข้อมูลเพิ่มเติมได้ที่เวอร์ชัน Java ในบิลด์ Android

การวิเคราะห์การอัปเกรด

การอัปเกรดทรัพยากร Dependency อาจทำให้เกิดความเสี่ยงในรูปแบบ API และการเปลี่ยนแปลงลักษณะการทำงาน ข้อกำหนดใหม่ในการใช้งาน ปัญหาด้านความปลอดภัยใหม่ๆ หรือแม้แต่การเปลี่ยนแปลงใบอนุญาต เช่น คุณต้องดำเนินการต่อไปนี้หรือไม่

  • เปลี่ยนโค้ดสำหรับการเปลี่ยนแปลง API ไหม
  • เพิ่มการตรวจสอบสิทธิ์ใหม่ไหม
  • สร้างการทดสอบเพิ่มเติมหรือแก้ไขการทดสอบที่มีอยู่เพื่อดูการเปลี่ยนแปลงลักษณะการทำงาน

พิจารณาว่าทรัพยากร Dependency ที่คุณอัปเกรดได้อัปเกรดการขึ้นต่อกันเวอร์ชัน แล้วหรือไม่ ซึ่งอาจทําให้เกิดการเปลี่ยนแปลงจํานวนมากได้อย่างรวดเร็ว

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

กุญแจสำคัญในการอัปเกรดที่ประสบความสำเร็จคือการวิเคราะห์การอัปเกรด

  1. ระบุความแตกต่างของรายการที่ต้องพึ่งพาก่อนและหลังการอัปเกรด
  2. ตรวจสอบการเปลี่ยนแปลงแต่ละรายการและระบุความเสี่ยงที่เกี่ยวข้อง
  3. ลดความเสี่ยง หรือยอมรับหรือปฏิเสธการเปลี่ยนแปลง

ระบุความแตกต่างของทรัพยากร Dependency

ขั้นตอนแรกในการวิเคราะห์การอัปเกรดคือการพิจารณาการเปลี่ยนแปลงของข้อกําหนด ใช้ประโยชน์จากการควบคุมเวอร์ชัน (VCS เช่น Git) และปลั๊กอิน Dependency Guard เพื่อดูการเปลี่ยนแปลงได้อย่างรวดเร็ว เป้าหมายของคุณคือสร้างภาพสแนปชอตก่อนและหลัง แล้วเปรียบเทียบภาพเหล่านั้น

ตั้งค่าและสร้างเส้นฐานแรก

ก่อนเริ่มการอัปเกรด ให้ตรวจสอบว่าโปรเจ็กต์ของคุณสร้างสําเร็จ

วิธีที่ดีที่สุดคือการแก้ไขคําเตือนให้ได้มากที่สุด หรือสร้างเส้นฐานเพื่อติดตามคําเตือนที่คุณเคยเห็น

  • Lint: ตรวจสอบคำเตือน Lint ที่มีอยู่และสร้างฐานบรรทัดฐาน Lint ของ Android
  • คอมไพเลอร์ Kotlin
  • เครื่องมืออื่นๆ: หากคุณใช้เครื่องมือวิเคราะห์แบบคงที่อื่นๆ (เช่น Detekt) ที่รองรับการติดตามเส้นฐาน ให้ตั้งค่าเส้นฐานของเครื่องมือเหล่านั้น

เกณฑ์พื้นฐานคำเตือนเหล่านี้ช่วยให้เห็นคำเตือนใหม่ได้ง่ายขึ้นเมื่ออัปเกรดทรัพยากร Dependency

สร้างเส้นฐานของ Dependency โดยการตั้งค่าและเรียกใช้ Dependency Guard ในแคตตาล็อกเวอร์ชัน gradle/libs.versions.toml ให้เพิ่มข้อมูลต่อไปนี้

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

และเพิ่มโค้ดต่อไปนี้ลงในไฟล์บิลด์ของแอป

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

การกําหนดค่า releaseRuntimeClasspath น่าจะเป็นเป้าหมาย แต่หากต้องการใช้การกําหนดค่าอื่น ให้เรียกใช้ ./gradlew dependencyGuard โดยไม่ระบุการกําหนดค่าที่แสดงในไฟล์บิลด์เพื่อดูการกําหนดค่าที่ใช้ได้ทั้งหมด

หลังจากตั้งค่าแล้ว ให้เรียกใช้ ./gradlew dependencyGuard เพื่อสร้างรายงานใน app/dependencies/releaseRuntimeClasspath.txt นี่คือรายงานพื้นฐาน คอมมิตข้อมูลนี้ลงในระบบควบคุมเวอร์ชัน (VCS) เพื่อบันทึก

โปรดทราบว่า Dependency Guard จะบันทึกเฉพาะรายการไลบรารีที่ต้องใช้ ยังมีทรัพยากร Dependency อื่นๆ ในไฟล์บิลด์ เช่น เวอร์ชัน Android SDK และ JDK การทำคอมมิตใน VCS ก่อนที่คุณจะเปลี่ยนแปลงทรัพยากร จะช่วยให้ VCS diff ไฮไลต์การเปลี่ยนแปลงเหล่านั้นด้วย

อัปเกรดและเปรียบเทียบกับเกณฑ์พื้นฐาน

เมื่อคุณมีข้อมูลพื้นฐานแล้ว ให้อัปเกรด Dependency และการเปลี่ยนแปลงอื่นๆ ของบิลด์ที่ต้องการทดสอบ อย่าอัปเกรดซอร์สโค้ดหรือทรัพยากรในตอนนี้

เรียกใช้ ./gradlew lint เพื่อดูคำเตือนหรือข้อผิดพลาดใหม่ของ Lint แก้ไขปัญหาสำคัญแล้วอัปเดตเกณฑ์พื้นฐานของคำเตือนโดยเรียกใช้ ./gradlew lint -Dlint.baselines.continue=true หากคุณใช้เครื่องมืออื่นๆ เพื่อบันทึกพื้นฐานคำเตือน เช่น พื้นฐานคำเตือน Kotlin หรือเครื่องมือสร้างพื้นฐานคำเตือน Kotlin ให้แก้ไขคำเตือนใหม่และอัปเดตพื้นฐานด้วย

เรียกใช้ ./gradlew dependencyGuard เพื่ออัปเดตรายงานพื้นฐาน จากนั้นเรียกใช้ diff VCS เพื่อดูการเปลี่ยนแปลงที่ไม่ใช่ไลบรารี เป็นไปได้ว่าจะมีการอัปเกรด ไลบรารีมากกว่าที่คุณคิด

วิเคราะห์ความเสี่ยง

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

สิ่งที่ควรพิจารณามีดังนี้

การยกตัวขึ้นของเวอร์ชันหลัก

หมายเลขเวอร์ชันหลักมีการเปลี่ยนแปลงหรือไม่

ในการกำหนดเวอร์ชันแบบเป็นความหมาย ตัวเลขแรกเรียกว่าเวอร์ชันหลัก เช่น หากเวอร์ชันของไลบรารีอัปเกรดจาก 1.2.3 เป็น 2.0.1 แสดงว่าเวอร์ชันหลักมีการเปลี่ยนแปลง โดยทั่วไปแล้ว ข้อความนี้บ่งชี้ว่านักพัฒนาไลบรารีได้ทําการเปลี่ยนแปลงที่ไม่เข้ากันระหว่างเวอร์ชันต่างๆ เช่น นําออกหรือเปลี่ยนแปลงบางส่วนของ API

เมื่อเห็นข้อความนี้ ให้ตรวจสอบคลังภาพที่ได้รับผลกระทบอย่างละเอียดเมื่อพิจารณาข้อควรพิจารณาต่อไปนี้

หากโค้ดของคุณใช้ API เวอร์ชันทดลอง (ซึ่งมักจะกำหนดให้คุณเลือกใช้โดยใช้คำอธิบายประกอบหรือข้อกำหนดของไฟล์บิลด์) การเปลี่ยนแปลงเวอร์ชันย่อยหรือแพตช์ เช่น การอัปเกรดจาก 1.2.3 เป็น 1.3.1 หรือ 1.2.3 เป็น 1.2.5 อาจก่อให้เกิดความเสี่ยงเพิ่มเติม

API ที่ไม่เสถียร

ไลบรารีบางรุ่นอาจมี API ที่ไม่เสถียร ซึ่งมักจะเป็น API ที่อยู่ระหว่างดำเนินการหรือขึ้นอยู่กับ API อื่นที่ไม่เสถียร

แม้ว่าโดยทั่วไปแล้ว จะจำกัดให้แสดงเฉพาะตัวอย่าง เช่น เวอร์ชันอัลฟ่า เวอร์ชันที่กำลังพัฒนา หรือเวอร์ชันทดลอง แต่ไลบรารีบางส่วนจะมี API ที่ระบุว่าเป็นเวอร์ชันทดลองหรือไม่เสถียร

โปรดหลีกเลี่ยง API ดังกล่าว หากเป็นไปได้ หากคุณจำเป็นต้องใช้ โปรดอย่าลืมบันทึกการใช้งานและคอยดูการเปลี่ยนแปลงหรือการนำออกในรุ่นต่อๆ ไป

ลักษณะการทำงานแบบไดนามิก

ไลบรารีบางรายการจะทำงานแตกต่างกันไปตามปัจจัยภายนอก เช่น ไลบรารีที่สื่อสารกับเซิร์ฟเวอร์จะขึ้นอยู่กับการเปลี่ยนแปลงในเซิร์ฟเวอร์นั้น

  • ไลบรารีต้องตรงกับเวอร์ชันเซิร์ฟเวอร์ที่เฉพาะเจาะจงไหม
  • ไลบรารีเชื่อมต่อกับเซิร์ฟเวอร์เวอร์ชันต่างๆ ได้ไหม
  • ปัจจัยภายนอกอื่นๆ ส่งผลต่อลักษณะการทํางานที่เหมาะสมของไลบรารีไหม

การรวมไฟล์ Manifest

ไลบรารีที่เผยแพร่เป็นไฟล์เก็บถาวร Android (AAR) อาจมีทรัพยากรและไฟล์ Manifest ที่ผสานเข้ากับแอปพลิเคชัน ซึ่งสามารถเพิ่มสิทธิ์และคอมโพเนนต์ Android ใหม่ เช่น กิจกรรมหรือ Broadcast Receiver ที่ทำงานโดยอ้อม

การอัปเดตรันไทม์

ไลบรารีบางรายการใช้ฟีเจอร์ที่อัปเดตได้นอกเหนือการควบคุมของแอปพลิเคชัน ไลบรารีอาจใช้บริการ Google Play ซึ่งได้รับการอัปเกรดแยกจาก Android SDK ไลบรารีอื่นๆ อาจเชื่อมโยงกับบริการในแอปพลิเคชันภายนอกที่อัปเดตแยกต่างหาก (มักใช้ AIDL)

คุณจะข้ามกี่เวอร์ชัน

ยิ่งคุณรออัปเกรดคลังนานเท่าใด ความเสี่ยงก็ยิ่งมีมากขึ้นเท่านั้น หากคุณเห็นการเปลี่ยนแปลงเวอร์ชันอย่างมาก เช่น 1.2.3 เป็น 1.34.5 ให้ตรวจสอบคลังนี้เป็นพิเศษ

คำแนะนำในการย้ายข้อมูล

ตรวจสอบว่าคลังมีคำแนะนำในการย้ายข้อมูลหรือไม่ ซึ่งจะช่วยลดการวิเคราะห์ความเสี่ยงและการวางแผนการบรรเทาความเสี่ยงได้อย่างมาก

โปรดทราบว่าการมีคู่มือดังกล่าวเป็นตัวบ่งชี้ที่ดีว่านักพัฒนาแอปมุ่งเน้นที่ความเข้ากันได้และพิจารณาการลดผลกระทบของการอัปเกรด

บันทึกประจำรุ่น

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

README

ไฟล์ README บางไฟล์สำหรับไลบรารีจะระบุถึงความเสี่ยงที่อาจเกิดขึ้น โดยเฉพาะในกรณีที่ไลบรารีไม่มีหมายเหตุเกี่ยวกับรุ่น มองหา_ปัญหาที่ทราบ_ โดยเฉพาะข้อกังวลด้านความปลอดภัยที่ทราบ

ตรวจสอบช่องโหว่ที่ทราบ

ดัชนี SDK ของ Play จะติดตามช่องโหว่ของ SDK ยอดนิยมหลายรายการ Play Console จะรายงานว่าคุณใช้ SDK รายการใดรายการหนึ่งที่ระบุไว้ซึ่งมีช่องโหว่ที่ทราบหรือไม่ เมื่อแก้ไขไฟล์บิลด์ใน Android Studio IDE จะตรวจสอบดัชนี SDK และแจ้งการใช้ไลบรารีเวอร์ชันที่มีช่องโหว่

สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) ดูแลฐานข้อมูลช่องโหว่แห่งชาติ (NVD) ขนาดใหญ่ ปลั๊กอิน Gradle แบบ Dependency Check จะตรวจสอบทรัพยากร Dependency ที่ใช้เทียบกับ NVD

หากต้องการใช้การตรวจสอบการขึ้นต่อกัน ให้ขอคีย์ NVD API ตั้งค่าปลั๊กอิน Gradle และเรียกใช้ ./gradlew dependencyCheckAnalyze โปรดทราบว่าขั้นตอนนี้อาจใช้เวลานาน

ความขัดแย้งของเวอร์ชัน

เวอร์ชันได้รับการแก้ไขตามที่คาดไว้ไหม มองหาข้อขัดแย้ง โดยเฉพาะความแตกต่างของเวอร์ชันหลัก ดูรายละเอียดเกี่ยวกับวิธีค้นหาข้อขัดแย้งได้ที่การแก้ไขการพึ่งพา Gradle โดยเฉพาะอย่างยิ่ง ให้ค้นหา -> ในรายงาน ./gradlew app:dependencies

หากเป็นไปได้ ให้ทํางานร่วมกับผู้เขียนผู้พึ่งพิงเพื่อแยกการขึ้นต่อกันของผู้ใช้รายนั้นออก หากบริษัทอนุญาต คุณสามารถมีส่วนร่วมในการเปลี่ยนแปลงของไลบรารี (การส่งต่อข้อมูล) เพื่อช่วยปรับปรุงความเข้ากันได้ของไลบรารี

ตรวจสอบใบอนุญาต

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

ความเสี่ยงด้านการบำรุงรักษาและ
คุณภาพ

สำหรับคลังที่มีที่เก็บข้อมูลสาธารณะ ให้ทำดังนี้

  • มีผู้ร่วมให้คำบรรยายกี่คนที่รักษาห้องสมุดไว้
  • มีการอัปเกรดครั้งล่าสุดเมื่อใด และไลบรารีมีการเปลี่ยนแปลงบ่อยแค่ไหน
  • ปัญหาที่รอดำเนินการ (หากมี) มีลักษณะอย่างไร อ่านคร่าวๆ เพื่อดูปัญหาที่อาจเกิดขึ้นและหนี้ทางเทคนิคของไลบรารี
  • การทดสอบ 1 หน่วยครอบคลุมไลบรารีได้ดีเพียงใด
  • มีรูปแบบที่ไม่ดีซึ่งทราบอยู่แล้วในโค้ดเบสไหม
  • ไลบรารีมีเอกสารประกอบที่ชัดเจนไหม
  • โค้ดฐานมีความคิดเห็น _fixme_ จำนวนมากหรือไม่

โอเพนซอร์สกับโคลสซอร์ส

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

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

เรียกใช้บิลด์

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

หากเห็นคำเตือนการลดค่าใหม่ ให้เพิ่มคำเตือนเหล่านั้นเป็นความเสี่ยงที่เฉพาะเจาะจงสำหรับคลังที่สร้างคำเตือน ซึ่งจะนําออกได้ในรุ่นต่อๆ ไป หากต้องการใช้ไลบรารีนั้นต่อไป โปรดสละเวลาในการแปลงจากการใช้ API ที่เลิกใช้งานแล้วในการเปลี่ยนทดแทน หรือจดบันทึกการเลิกใช้งานเพื่อคอยสังเกตการทำงานเหล่านั้นและดูว่าจะมีการนำ API เหล่านั้นออกในภายหลังหรือไม่

ใช้ Lint เพื่อตรวจหาปัญหาเกี่ยวกับ API

Android Lint อาจตรวจพบปัญหามากมายในแอปพลิเคชันของคุณ รวมถึงปัญหาบางอย่างที่เกิดจากการเปลี่ยนเวอร์ชันทรัพยากร Dependency หรือ Android SDK เช่น หากคุณอัปเกรด compileSdk และใช้ API ใหม่ของ compileSdk นั้น Lint จะรายงาน API ที่ไม่มีใน SDK เวอร์ชันก่อนหน้า

Lint จะทำงานในเครื่องมือแก้ไขของ Android Studio โดยจะรายงานปัญหาขณะที่คุณทําการเปลี่ยนแปลง แต่โดยทั่วไปจะไม่ทํางานเป็นส่วนหนึ่งของบิลด์ใน Studio หรือเมื่อคุณเรียกใช้บิลด์บรรทัดคําสั่ง เว้นแต่คุณจะใช้เป้าหมาย build หรือ lint

หากคุณใช้การรวมอย่างต่อเนื่อง (CI) ให้เรียกใช้ gradlew build หรือ gradlew lint ในระหว่างการสร้าง CI (หรืออย่างน้อยก็ในบิลด์รายวัน) เพื่อตรวจหาข้อผิดพลาดประเภทเหล่านี้

หากคุณไม่ได้ใช้ CI โปรดเรียกใช้ gradlew lint เป็นครั้งคราวเป็นอย่างน้อย

โปรดตรวจสอบข้อผิดพลาดและคำเตือนเกี่ยวกับโปรแกรมตรวจไวยากรณ์เป็นพิเศษ ไลบรารีบางแห่งจัดส่งด้วยการตรวจสอบ Lint ของตนเองเพื่อให้มั่นใจว่าใช้ API ได้อย่างเหมาะสม ไลบรารีบางเวอร์ชันใหม่มีคำเตือนและข้อผิดพลาดเกี่ยวกับ Lint ใหม่ ซึ่งส่งผลให้มีรายงานใหม่เมื่อคุณสร้าง

ลดความเสี่ยง

หลังจากพิจารณาความเสี่ยงของการอัปเกรดแล้ว ให้ตัดสินใจว่าคุณต้องการลดความเสี่ยงเหล่านั้นอย่างไร ดังนี้

  • ยอมรับความเสี่ยงตามที่เป็นอยู่ ความเสี่ยงบางอย่างก็ต่ำพอที่จะยอมรับได้ โดยเฉพาะเมื่อเวลาและทรัพยากรในการอัปเกรดมีจำกัด
  • ปฏิเสธความเสี่ยงบางรายการโดยสิ้นเชิง การอัปเกรดบางอย่างอาจดูมีความเสี่ยงสูงเกินไป โดยเฉพาะในกรณีที่คุณมีเวลาหรือทรัพยากรจํากัดในการลดความเสี่ยง หากต้องการคัดแยก ให้เน้นการอัปเกรดที่จำเป็นสำหรับข้อบกพร่องที่พบหรือฟีเจอร์ใหม่ที่ต้องการ
  • ลดความเสี่ยงที่เหลือ
    • ลองจัดกลุ่มการอัปเกรดเป็นชุดการเปลี่ยนแปลงขนาดเล็กๆ ที่ไม่เกี่ยวข้องกัน วิธีนี้ช่วยลดความเสี่ยงโดยรวมและอนุญาตให้เปลี่ยนกลับบางส่วนได้
    • ตรวจสอบการเปลี่ยนแปลงโดยละเอียด
    • ทดสอบแอปเพื่อตรวจหาการเปลี่ยนแปลงที่ไม่คาดคิด เพิ่มการทดสอบใหม่เมื่อจําเป็นเพื่อสร้างความสําคัญในการอัปเกรด
    • ดูแหล่งที่มา (หากมี) เมื่อพบสิ่งที่น่าสงสัย
    • ทำการเปลี่ยนแปลงที่จำเป็นในแหล่งที่มาหรือบิลด์

บันทึกการตัดสินใจของคุณ หากความเสี่ยงจากการอัปเกรดกลายเป็นปัญหาเมื่อเรียกใช้แอปพลิเคชัน เอกสารประกอบการวิเคราะห์ความเสี่ยงจะช่วยลดความจําเป็นในการวิเคราะห์ข้อผิดพลาดได้

ตรวจสอบใบอนุญาต

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

ใบอนุญาตอาจมีการเปลี่ยนแปลงในทุกรุ่น เมื่อใดก็ตามที่คุณอัปเกรด คุณควรตรวจสอบว่าไลบรารีที่ใช้อยู่ได้รับอนุญาตในลักษณะที่เข้ากันได้กับแอปพลิเคชันหรือไลบรารีของคุณ

หากใบอนุญาตใช้ร่วมกันไม่ได้ (หรือมีการเปลี่ยนแปลงให้ใช้ร่วมกันไม่ได้อีกต่อไป) คุณจะไม่สามารถใช้คลังเวอร์ชันนั้นได้ ดังนี้

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