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

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

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

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

สร้างคลัง

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

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

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

ประการแรก - ลดทรัพยากร Dependency ของไลบรารีให้น้อยที่สุดเท่าที่จะทำได้ ยิ่งมีทรัพยากร 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 อื่นๆ ทั้งหมดที่คุณใช้อยู่ 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 Upgrade Assistant ที่ช่วยทำงานเหล่านี้ได้

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

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

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

  • สิทธิ์ใหม่ที่คุณจะต้องขอเมื่อติดตั้งหรือรันไทม์
  • API ที่เลิกใช้งานแล้วและ 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

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

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

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

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

หากคุณใช้เครื่องมืออย่าง 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 ใหม่ เช่น กิจกรรมหรือตัวรับการออกอากาศที่ทำงานแบบอ้อม

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

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

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

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

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

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

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

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

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

README

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

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

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

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

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

เวอร์ชันขัดแย้งกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android Lint สามารถตรวจหาปัญหามากมายในแอปพลิเคชันของคุณ ซึ่งรวมถึงปัญหาบางอย่างที่เกิดจากการเปลี่ยนแปลงเวอร์ชันของไลบรารีที่ใช้ร่วมกันหรือ 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 ใหม่ ซึ่งส่งผลให้มีรายงานใหม่เมื่อคุณสร้าง

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

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

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

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

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

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

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

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

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