שדרוג הגרסאות של יחסי התלות

שדרוג של יחסי התלות מספק גישה לתכונות העדכניות, לתיקוני הבאגים ולשיפורים האחרונים. כדי לשדרג את יחסי התלות, חשוב להבין איך Gradle מטפל בגרסאות שמבקשים, מה הסיכונים הכרוכים בכך ומה אפשר לעשות כדי למזער את הסיכונים האלה.

הערה: בדיקות אפליקציה טובות הן המפתח להבטיח שהשדרוגים לא יגרמו לשיבושים בלתי צפויים בגרסה המאוחדת או באפליקציה.

שדרוג האסטרטגיה

השלב החשוב ביותר בכל שדרוג הוא ניתוח סיכונים. כדאי להחליט איך אתם מרגישים לגבי כל יחסי התלות שאתם משדרגים. יש הרבה שיקולים שכדאי להביא בחשבון כשמגדירים את אסטרטגיית השדרוג, כולל:

יצירת ספרייה	האם אתם מפתחים אפליקציה שהמשתמשים מורידים ומפעילים במכשיר? או שאתם בונים ספרייה כדי לסייע למפתחים אחרים לבנות את האפליקציות שלהם? אם אתם בונים אפליקציה, עליכם להתמקד בשמירה על האפליקציה מעודכנת ויציבה. אם אתם מפתחים ספרייה, כדאי להתמקד באפליקציות של מפתחים אחרים. השדרוגים משפיעים על הצרכנים שלכם. אם משדרגים את אחת מהתלות, הגרסה הזו הופכת למועמדת לפתרון התלות ב-Gradle, ויכול להיות שהשימוש של האפליקציה בתלות הזו ייפגע. קודם כול, כדאי לצמצם את יחסי התלות של הספרייה ככל האפשר. ככל שיש לכם פחות יחסי תלות, כך ההשפעה על רזולוציית התלות של הצרכן נמוכה יותר. חשוב לפעול בהתאם לשיטת ניהול הגרסאות הסמנטית כדי לציין את סוגי השינויים שאתם מבצעים. לדוגמה, מערכת AndroidX פועלת לפי ניהול גרסאות סמנטי ומוסיפה סכמת גרסאות טרום-השקה. כדאי להימנע משדרוגים של הגרסאות של major כדי למנוע פגיעה בצרכנים. כדאי ליצור גרסה מועמדת להשקה (RC) של הספרייה כדי שהמשתמשים יוכלו לבדוק אותה בשלב מוקדם. בהנחיות בנושא תאימות לאחור לכותבי ספריות מוסבר איך לשמור על תאימות של ממשק ה-Application Binary Interface ‏ (ABI) של הספרייה. השתמשו בבדיקות שילוב ובכלים כמו Binary Compliance validator כדי לוודא שהשינויים ב-ABI תואמים לשינוי הגרסה המיועד. אם פורסמו תיקונים ב-patch לגרסאות נמוכות יותר של הספרייה שלך, הצרכנים לא צריכים לשדרג את הספרייה לגרסה הבאה של major או minor, אלא אם הם רוצים תכונות חדשות. מומלץ להימנע משדרוג של יחסי תלות טרנזיטיביים בשדרוגים האלה. אם שדרוג הספרייה מחייב שינויי תוכנה שעלולים לגרום לכאבי משתמשים בעיקר עבור הצרכנים, מומלץ להשיק אותם כארטיפקט חדש. כך תוכלו לעבור בין הגרסה הישנה לגרסה החדשה, ולאפשר השקה הדרגתית. הערה: אם שדרוג של אחד מיחסי התלות כולל שינוי משמעותי ב-API, כדאי לשדרג אותו בגרסה major או minor ולבצע את השינויים הנדרשים. אם לא תעשו זאת, משתמשים בספרייה שלכם עשויים לעשות זאת, וכתוצאה מכך יהיו אי-תאימות בין הספרייה לבין הספרייה התלויה. הכללים האלה עשויים לחול גם אם לא בוצע שינוי בספרייה. אפשר לפרסם גרסה חדשה רק כדי לשדרג את התלות הזאת.
מחזור הפצה	באיזו תדירות אתם משחררים את האפליקציה או הספרייה? מחזורי פיתוח והשקה קצרים יותר נותר פחות זמן לשדרוג. אתם יכולים להיעזר בהם כדי לא להתעכב. שדרוגים קטנים תכופים יכולים להקל על עומס העבודה. אם שדרוג הספרייה הופך לבעייתי, אפשר להחזיר את השדרוג לגרסה קודמת מהר יותר. כלים כמו Dependabot ו-Renovate מפחיתים את עומס העבודה, אבל חשוב לנתח את התוצאות כדי לבדוק אם יש סיכונים. מחזורי פיתוח והשקה ארוכים יותר יש זמן נוסף לבצע שדרוגים ולבדוק אותם. יש סיכוי גבוה יותר שגרסאות חדשות יותר של יחסי תלות יושקו במהלך המחזור החודשי. החזרה לאחור של שדרוגים והשקה מחדש של האפליקציה או הספרייה נמשכים זמן רב יותר.
איך להתעדכן בתכונות החדשות	האם אתם מעדיפים להשתמש בתכונות ובממשקי ה-API העדכניים ביותר, או לשדרג רק כשאתם צריכים תכונה או תיקון באג? כדאי לשקול את היתרונות והחסרונות של שדרוגים תכופים. שדרוגים עתידיים יהיו קלים יותר (פחות שינויים שצריך לשלב), אבל תצטרכו להסתכן בשדרוגים בתדירות גבוהה יותר. בדיקת שדרוגים לגרסאות טרום-השקה (אלפא, בטא, גרסה מועמדת להשקה) של ספריות יכולה לעזור בהכנה לקראת זמינות של גרסאות יציבות.
תלות חדשה	אם מוסיפים יחסי תלות חדשים, מומלץ להשתמש בתהליך בדיקה יסודי שבודק את הספרייה בכל קריטריוני הסיכון כדי לוודא שהם הוערכו כראוי. לא לאפשר הוספה של יחסי תלות חדשים ללא בדיקה.
צוות ייעודי	יש לך צוות build ייעודי? האם מהנדסי התוכנה שלך מנהלים את ה-build? לרוב, צוות ייעודי יכול להקדיש יותר זמן לניתוח סיכוני השדרוג ולבדיקת הגרסאות החדשות כדי לוודא שה-build פועל כמו שצריך לפני שהמהנדסים משתמשים בגרסאות החדשות.
סוג השדרוג	חלק מהשדרוגים חשובים יותר מאחרים. כדאי לחשוב אילו תכונות הכי חשובות לכם. בדרך כלל, לשדרוגים של כלי build, כמו Gradle ופלאגינים של Gradle, יש השפעה פחותה על המשתמשים, ורוב הסיכון הוא פנימי ל-build. ה-build עצמו עוזר לאמת את השינויים האלה. קשה יותר לאמת שדרוגים של ספריות ו-SDK, והם נמצאים בסיכון גבוה יותר למשתמשים. Android Gradle Plugin‏ (AGP) – כלי העבודה המשמשים ליצירת האפליקציה או הספרייה של Android. זהו השדרוג החשוב ביותר שאפשר לבצע, כי לרוב הוא כולל או מאפשר שיפורי ביצועים, תיקוני באגים, כללי איתור שגיאות חדשים ותמיכה בגרסאות חדשות של פלטפורמת Android. Gradle — לרוב צריך לשדרג את Gradle כשמשדרגים ל-AGP או פלאגין אחר של Gradle. יישומי פלאגין אחרים של Gradle – לפעמים ה-API של הפלאגין של Gradle משתנה. כשמעדכנים את Gradle, כדאי לבדוק אם יש עדכונים לפלאגינים שבהם אתם משתמשים. Kotlin ו-Java – בספריות ובפלאגינים מסוימים נדרשות גרסאות מינימום של Kotlin או Java, או שאתם רוצים לנצל את התכונות החדשות של השפה, ממשקי ה-API או שיפורי הביצועים. פלטפורמת Android — לחנות Play נדרשים שדרוגים קבועים של Android SDK. מומלץ לבדוק גרסאות חדשות של Android SDK בהקדם האפשרי. שדרוגים מסוימים של SDK מחייב שינויים באפליקציה, כמו הרשאות חדשות או שימוש בממשקי API חדשים. ספריות – האם ברצונך לתת עדיפות לספריות על סמך הקרבה שלהן לארכיטקטורה הכוללת? ספריות שקשורות לפלטפורמה ולארכיטקטורה, כמו AndroidX, משתנות לעיתים קרובות כדי לנצל תכונות חדשות או לעזור בשינויים מופשטים בפלטפורמה. צריך לשדרג את הספריות האלה לפחות בכל פעם שמשדרגים את פלטפורמת Android או ספריות אחרות שקשורות לארכיטקטורה. שדרוגים אחרים של ספריות אפשר לפזר או לדחות, אלא אם אתם זקוקים לתכונה חדשה או לתיקוני באגים ספציפיים. Android Studio – עדכון Android Studio מאפשר לכם לגשת לתכונות ולתיקוני הבאגים האחרונים בפלטפורמה ובכלים הבסיסיים של IntelliJ IDEA, ולעבוד עם ערכות ה-SDK העדכניות ביותר של Android.
כלים זמינים	יש הרבה כלים ויישומי פלאגין שיעזרו לכם לבצע את השדרוגים. כלים כמו Dependabot ו-Renovate משדרגים באופן אוטומטי את גרסאות הספריות ב-build, אבל חשוב לנתח את התוצאות כדי לבדוק אם יש סיכונים.

אסטרטגיות לסוגים ספציפיים של שדרוגים

שדרוג של סוגים מסוימים של יחסי תלות עשוי להשפיע על יחסי תלות אחרים, ולחייב שדרוג שלהם. אנחנו מדברים על היחסים בין רכיבי ה-build בקטע יחסי תלות בין כלים וספריות.

איור 1. לפתח קשרים.

כשמשדרגים כל סוג של רכיב, צריך לחשוב איך השדרוג ישפיע על רכיבים אחרים ב-build.

Android Gradle Plugin‏ (AGP)	Android Studio כולל עוזר שדרוג של APG שיכול לעזור לכם לבצע את המשימות האלה. אם אתם משתמשים ב-Assistant או מבצעים את השדרוג באופן ידני, כדאי לשקול את הדברים הבאים: הערות הגרסה של APG משדרגים את Gradle לפחות לגרסה שמופיעה ברשימה. משדרגים את Android Studio לגרסה שתומכת בגרסה שנבחרה של AGP. משתמשים בגרסאות של Android Studio ו-AGP שתומכות ב-Android SDK שבו רוצים להשתמש. בדיקת התאימות ל-SDK Build Tools, NDK ו-JDK. אם אתם מפתחים פלאגין של Gradle (לשימוש פנימי או ציבורי) שמרחיב את AGP או משתמש בנתונים ממנו, כדאי לבדוק אם אתם צריכים לשדרג את הפלאגין. לפעמים AGP מפסיקה את השימוש בממשקי API ומסירה אותם מאוחר יותר, מה שגורם לאי-תאימות עם יישומי פלאגין קודמים.
השפה, המהדר והזמן הריצה של Kotlin	כדאי לעיין בנתוני הגרסה של Kootlin כדי למצוא בעיות ידועות וחוסר תאימות. אם אתם משתמשים ב-Jetpack פיתוח נייטיב: אם גרסת Kotlin החדשה נמוכה מ-2.0.0: מאתרים את הפלאגין התואם של Compose compiler. משדרגים את kotlinCompilerExtensionVersion ב-build.gradle.kts של כל המודולים שבהם הוא מופיע. אם גרסת Kotin החדשה היא 2.0.0 ואילך: מגדירים את Compose Compiler Gradle Plugin באותה הגרסה של המהדר (compiler) ב-Kotlin. אם אתם משתמשים ב-Kotlin Symbol Processing‏ (KSP), תוכלו לעיין במדריך למתחילים בנושא KSP כדי לקבל מידע על ההגדרה, ובגרסאות KSP כדי לקבל מידע על הגרסאות הזמינות. חשוב לזכור שצריך להשתמש בגרסה של KSP שתואמת לגרסה של Kotlin. לדוגמה, אם אתם משתמשים ב-Kotlin 2.0.21, תוכלו להשתמש בכל גרסה של הפלאגין KSP שמתחילה ב-2.0.21, למשל 2.0.21-1.0.25. בדרך כלל אין צורך לשדרג את מעבדי ה-KSP (למשל, מהדר החדר, שמופיע כתלות ב-ksp בקובצי ה-build שלכם); הפלאגין KSP מפשט את רוב ה-API של המהדר (compiler API), ו-KSP API שבו משתמשים המעבדים הוא יציב. שדרוג כל יישומי הפלאגין האחרים של Kotlin Compiler שבהם אתם משתמשים. ממשק ה-API של פלאגין קומפילר Kotlin משתנה לעיתים קרובות בין גרסאות, והפלאגינים חייבים להשתמש ב-API תואם. אם הפלאגין מופיע בקטע Compiler plugins, צריך להשתמש באותה גרסה כמו של קומפילר Kotlin. לגבי כל פלאגין אחר ל-compile, צריך לבדוק את המסמכים שלו כדי למצוא את המיפוי המתאים. חשוב לשים לב: לרוב, יישומי פלאגין של מהדר (compiler) לא מתוחזקים לצד המהדר (compiler) Kotlin , חווים בדרך כלל עיכובים בהפצה בזמן שהם ממתינים להתייצבות ה-API של פלאגין המהדר. לפני שמשדרגים את Kotlin, צריך לבדוק אם יש שדרוגים תואמים לכל הפלאגינים של המהדר שבהם אתם משתמשים. לבסוף, במקרים מסוימים השפה של Kotlin משתנה, וצריך לעדכן את הקוד. לרוב זה קורה כשמנסים תכונות ניסיוניות. אם הקוד לא נוצר כראוי אחרי שדרוג המהדר של Kotlin, כדאי לבדוק אם יש שינויים בשפה או שגיאות בספרייה בסביבת זמן הריצה בהערות המוצר של Kotlin.
פלאגינים של קומפילר Kotlin	אם אתם צריכים לשדרג פלאגין של קומפילטור Kotlin, עליכם לשדרג לגרסה התואמת של Kotlin שבה אתם משתמשים. רוב הפלאגינים של מהדר Kotlin משתמשים באותה גרסה כמו מהדר Kotlin, או שהם מתחילים בגרסה הנדרשת של מהדר Kotlin. לדוגמה, אם גרסת הפלאגין היא 2.0.21-1.0.25, צריך להשתמש בגרסה 2.0.21 של קומפילטור Kotlin. לפעמים שינוי גרסת המהדר של Kotlin מחייב שינויים אחרים.
ספריות	ספריות הן יחסי התלות הנפוצים ביותר שצריך לשדרג ב-build. השדרוגים הזמינים יוצגו בעורך Android Studio, או אם משתמשים בכלים ויישומי פלאגין מסוימים. בספריות מסוימות מצוין compileSdk או minSdk מינימלי שנדרש כדי להשתמש בספרייה. אם לא משתמשים לפחות ב-compileSdk שצוין, תהליכי ה-build נכשלים. עם זאת, הערך של minSdk באפליקציה מוגדר באופן אוטומטי לערך המקסימלי של כל ערכי minSdk שצוינו בקבצי ה-build וביחסי התלות בספריות. בחלק מהספריות מצוין גם גרסת Kotlin מינימלית לשימוש. מעדכנים את הגרסה של Kotlin בקובצי ה-build כך שתהיה לפחות הגרסה שצוינה.
Gradle	לפעמים גרסאות חדשות של Gradle מבטלות את התמיכה בממשקי API קיימים, ומסירות אותם בגרסה עתידית. אם אתם מפתחים פלאגין של Gradle, כדאי לשדרג את הפלאגין בהקדם האפשרי, במיוחד אם הפלאגין הזה הוא ציבורי. חלק מהשדרוגים של Gradle דורשים לאתר גרסאות חדשות של הפלאגינים שבהם אתם משתמשים. חשוב לזכור שהפלאגינים האלה עשויים להתעכב בפיתוח שלהם בזמן שהם משדרגים את הפלאגינים כך שיתאימו לממשקי ה-API העדכניים ביותר של הפלאגינים של Gradle. כדי לשדרג את Gradle: חשוב לקרוא את נתוני הגרסה של הגרסה שבה רוצים להשתמש. כדאי לשדרג את גרסת Gradle ב-gradle/wrapper/gradle-wrapper.properties. מריצים את הפקודה ./gradlew wrapper --gradle-version latest כדי לשדרג את קובץ ה-jar ואת הסקריפטים של Gradle wrapper. משדרגים את הפלאגינים של Gradle. שדרוג JDK שמשמש להפעלת Gradle.
פלאגינים של Gradle	לפעמים, פלאגינים משודרגים של Gradle משתמשים ב-API חדש או שונה של Gradle, וכתוצאה מכך נדרשת שדרוג של Gradle או אולי שינויים בתצורה שלהם בקובצי ה-build. בכל מקרה, יוצגו אזהרות או שגיאות בנוגע ל-build שמצביעות על אי-תאימות. בכל פעם שמשדרגים יישומי פלאגין, כדאי לשדרג את Gradle.
Android SDK	Android Studio כולל עוזר דיגיטלי לשדרוג SDK של Android שיכול לעזור במשימות האלה. אם אתם משתמשים במאמן או מבצעים את השדרוג באופן ידני, כדאי לשקול את הנושאים הבאים: כל גרסה של Android SDK כוללת תכונות וממשקי API חדשים, תיקוני באגים ושינויים בהתנהגות. חובה לעדכן את targetSdk בחנות Play, אבל מומלץ לעדכן את targetSdk לפני המועדים הסופיים כדי שיהיה לכם מספיק זמן לבצע את השינויים הנדרשים. לפני שמשדרגים את Android SDK, מומלץ לקרוא בעיון את נתוני הגרסה. חשוב לשים לב לקטע 'שינויים בהתנהגות', שכולל את הפרטים הבאים: הרשאות חדשות שתצטרכו לבקש בזמן ההתקנה או בזמן הריצה. ממשקי API שהוצאו משימוש והחלופות שלהם. שינויים קיצוניים בממשקי API או בהתנהגות. ממשקי API חדשים של Kotlin או Java, שעשויים להשפיע על הקוד. הקטע 'שינויים בהתנהגות' יכול להיות ארוך למדי, אבל כדאי לשים לב במיוחד כי הוא מכיל לעיתים קרובות שינויים קריטיים שצריך לבצע באפליקציה. כדי לעמוד בדרישות של חנות Play, צריך לשדרג את targetSdk. השדרוג של compileSdk הוא אופציונלי, והוא מעניק גישה לממשקי API חדשים. חשוב לזכור שספריות מסוימות, כמו AndroidX, כוללות דרישת compileSdk מינימלית. כדי ליהנות מהפיצ'רים החדשים של ה-SDK במהלך הפיתוח ולהבטיח תאימות במהלך ה-build, צריך לשדרג את הפלאגין של 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 בשלב מאוחר יותר, תוכלו למצוא את האפשרויות האלה בתפריט Tools: כלי לשדרוג של APG… הכלי לשדרוג SDK של Android...
Java	אם יש לכם קוד מקור של Java באפליקציית Android, כדאי לכם להשתמש בממשקי API חדשים יותר של Java. כל גרסה של Android SDK תומכת בקבוצת משנה של ממשקי API של Java ובתכונות שפה. AGP מספק תאימות לגרסאות ישנות יותר של Android SDK באמצעות תהליך שנקרא desugaring. הערות המוצר של Android SDK מציינות את רמת Java הנתמכת ובעיות פוטנציאליות. חלק מהבעיות האלה עשויות להשפיע גם על קוד המקור של Kotlin, כי ל-Kotlin יש גישה לאותם ממשקי Java API. חשוב לשים לב במיוחד לקטעים של JDK API שמופיעים בקטע 'שינויים התנהגותיים' בנתוני הגרסה, גם אם אין קוד מקור של Java. השימוש ב-JDK מצוין בכמה מקומות בסקריפטים של ה-build. למידע נוסף, אפשר לעיין במאמר גרסאות Java ב-build של Android.

ניתוח שדרוגים

שדרוג של יחסי תלות עלול להוביל לסיכונים כמו שינויים ב-API ובהתנהגות, דרישות חדשות לשימוש, בעיות אבטחה חדשות או אפילו שינויים ברישיון. לדוגמה, האם אתם צריכים:

• לשנות את הקוד לשינויים ב-API?
• להוסיף בדיקות הרשאות חדשות?
• ליצור בדיקות נוספות או לשנות בדיקות קיימות כדי לזהות שינויים בהתנהגות?

חשוב לזכור שהגרסאות של יחסי התלות של החבילה שדרגתם שודרגו. הדבר עלול להוביל במהירות לקבוצה גדולה של שינויים.

אם אתם משתמשים בכלי כמו Renovate או Dependabot כדי לבצע שדרוגים באופן אוטומטי, חשוב לדעת שהם לא מבצעים ניתוח בשבילכם. הם מבצעים שדרוג לגרסאות הספריות העדכניות ביותר. אל תניחו שכל מה שצריך יפעל כמו שצריך אחרי שדרוגים אוטומטיים מהסוג הזה.

המפתח לשדרוגים מוצלחים הוא ניתוח השדרוג:

1. לבדוק את ההבדלים ביחסי התלות לפני ואחרי השדרוגים.
2. יש לבדוק כל שינוי ולקבוע את הסיכונים הכרוכים בו.
3. לצמצם את הסיכונים, לאשר או לדחות שינויים.

זיהוי הבדלים ביחסי התלות

השלב הראשון בניתוח השדרוג הוא לקבוע איך יחול שינוי ביחסי התלות. כדאי להשתמש בניהול גרסאות (VCS, כמו Git) ובפלאגין Dependency Guard כדי לראות שינויים במהירות. המטרה היא ליצור קובץ snapshot לפני ואחרי השינוי ולהשוות ביניהם.

הגדרה ויצירה של קו הבסיס הראשון

לפני שמתחילים בשדרוג, חשוב לוודא שהפרויקט נבנה בהצלחה.

באופן אידיאלי, צריך לפתור כמה שיותר אזהרות, או ליצור ערכי בסיס כדי לעקוב אחרי האזהרות שכבר ראית.

• Lint: בודקים את האזהרות הקיימות של Lint ויוצרים בסיס ל-lint של Android.
• קומפילטור Kotlin:
  • מפעילים את -Werror כדי להתייחס לכל האזהרות כשגיאות. איך מגדירים אפשרויות
  • כדאי להשתמש בפלאגינים כמו Kotlin Warning Baseline או Kotlin Warnings Baseline Generator.
• כלים אחרים: אם אתם משתמשים בכלים אחרים לניתוח סטטי (כמו Detekt) שתומכים במעקב בסיסי, הגדירו את ערכי הבסיס שלהם.

ערכי הבסיס של האזהרות האלה יאפשרו לכם לראות בקלות אזהרות חדשות בזמן שמשדרגים את יחסי התלות.

יוצרים בסיס ליחסי התלות על ידי הגדרה והפעלה של Dependency Guard. בקטלוג הגרסאות gradle/libs.versions.toml, מוסיפים את הפרטים הבאים:

[versions]
dependencyGuard = "0.5.0"

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

מוסיפים את הטקסט הבא לקובץ ה-build של האפליקציה:

Kotlin

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

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

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

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

ההגדרות האישיות של releaseRuntimeClasspath הן כנראה יעד, אבל אם רוצים להשתמש בהגדרות אחרות, מריצים את ./gradlew dependencyGuard בלי ההגדרות האישיות ברשימה בקובץ ה-build כדי לראות את כל ההגדרות האישיות הזמינות.

אחרי ההגדרה, מריצים את הפקודה ./gradlew dependencyGuard כדי ליצור דוח ב-app/dependencies/releaseRuntimeClasspath.txt. זהו הדוח הבסיסי. כדי לשמור את השינויים, מבצעים השמה (commit) במערכת בקרת הגרסאות (VCS).

חשוב לזכור שמגן התלות מתעד רק את רשימת יחסי התלות של הספרייה. יש יחסי תלות אחרים בקובצי ה-build, כמו גרסאות Android SDK ו-JDK. התחייבות ל-VCS לפני שינויים בתלות תאפשר להבדלים ב-VCS להדגיש גם את השינויים האלה.

שדרוג והשוואה לערך הבסיס

אחרי שתיצרו את קו הבסיס, תוכלו לשדרג את יחסי התלות ואת שינויי ה-build האחרים שרציתם לבדוק. בשלב הזה, אל תבצעו שדרוג של קוד המקור או המשאבים.

מריצים את הפקודה ./gradlew lint כדי לראות אזהרות או שגיאות חדשות של שגיאות בקוד. פותרים את הבעיות החשובות ומריצים את הפקודה ./gradlew lint -Dlint.baselines.continue=true כדי לעדכן את ערך הבסיס של ההתראות. אם השתמשתם בכלים אחרים כדי לתעד את ערכי הבסיס של האזהרות, כמו Kotlin Warning Baseline או Kotlin Warnings Baseline Generator, עליכם לטפל באזהרות חדשות ולעדכן גם את ערכי הבסיס שלהן.

מריצים את הפקודה ./gradlew dependencyGuard כדי לעדכן את דוח הבסיס. לאחר מכן מריצים את ההבדלים ב-VCS כדי לראות שינויים שלא קשורים לספרייה. סביר להניח שהיא תכלול הרבה יותר שדרוגים של הספרייה ממה שחשבתם.

ניתוח הסיכונים

אחרי שתדעו מה השתנה, תוכלו להעריך את הסיכונים האפשריים בכל ספרייה ששודרגה. כך תוכלו למקד את הבדיקה או לחקור לעומק את השינויים. כדי להבטיח ניתוח עקבי, כדאי להגדיר קבוצה של סיכונים לניתוח בפרויקט.

כמה שיקולים:

שדרוגים של גרסאות ראשיות	האם המספר של הגרסה הראשית השתנה? בניהול גרסאות סמנטיות, המספר הראשון נקרא הגרסה הראשית. לדוגמה, אם הגרסה של ספרייה שודרגה מ-1.2.3 ל-2.0.1, הגרסה הראשית השתנתה. בדרך כלל, המשמעות היא שמפתח הספרייה ביצע שינויים לא תואמים בין הגרסאות, כמו הסרה או שינוי של חלקים ב-API. אם מופיעה ההודעה הזו, חשוב לשים לב במיוחד לספריות שהושפעו כשבודקים את השיקולים הבאים. אם הקוד שלכם משתמש בממשקי API ניסיוניים (שדרושה הסכמה לשימוש בהם באמצעות הערות או מפרטי קובץ build), גם שינויים קלים בגרסה או תיקון של גרסה, כמו שדרוג מ-1.2.3 ל-1.3.1 או מ-1.2.3 ל-1.2.5, עלולים להוות סיכונים נוספים.
ממשק API לא יציב	חלק מהגרסאות של הספריות עשויות לכלול ממשקי API לא יציבים. בדרך כלל מדובר בממשקי API שנמצאים בתהליך פיתוח או תלויים בממשק API לא יציב אחר. בדרך כלל, ספריות כאלה מוגבלות לגרסאות מקדימות, כמו גרסאות אלפא, גרסאות פיתוח או גרסאות ניסיוניות, אבל יש ספריות שכוללות ממשקי API שמסומנים כניסיוניים או לא יציבים. אם אפשר, כדאי להימנע מממשקי API כאלה. אם אתם צריכים להשתמש בהם, הקפידו לתעד את השימוש שלכם ולבדוק אם יש שינויים או הסרות במהדורות מאוחרות יותר.
התנהגות דינמית	ספריות מסוימות פועלות בצורה שונה בהתאם לגורמים חיצוניים. לדוגמה, ספרייה שמתקשרת עם שרת תלויה בשינויים בשרת הזה. האם הספרייה צריכה להתאים לגרסת שרת מסוימת? האם הספרייה יכולה להתחבר לגרסאות שונות של שרת? האם גורם חיצוני אחר משפיע על ההתנהגות הנכונה של הספרייה?
מיזוג מניפסטים	ספריות שמתפרסמות כארכיונים של Android (AAR) יכולות להכיל משאבים ומניפסטים שמוזגו עם האפליקציה שלך. רכיבים כאלה יכולים להוסיף הרשאות חדשות ורכיבי Android, כמו פעילויות או מקלטי שידורים, שפועלים באופן עקיף.
עדכונים בזמן ריצה	בחלק מהספריות נעשה שימוש בתכונות שאפשר לעדכן מחוץ לאפליקציה. הספרייה יכולה להשתמש ב-Play Services, שמשודרגים בנפרד מ-Android SDK. ספריות אחרות עשויות לקשר לשירותים באפליקציות חיצוניות שמתעדכנות בנפרד (לרוב באמצעות AIDL).
כמה גרסאות אתם מדלגים עליהן?	ככל שממתינים יותר זמן לשדרוג הספרייה, מגדילים את הסיכונים הפוטנציאליים. אם אתם רואים שינוי משמעותי בגרסה, למשל מ-1.2.3 ל-1.34.5, כדאי לשים לב במיוחד לספרייה הזו.
מדריכים להעברת נתונים (מיגרציה)	בודקים אם הספרייה כוללת מדריך להעברת נתונים (מיגרציה). כך תוכלו לצמצם באופן משמעותי את ניתוח הסיכונים ואת תכנון הפחתת הסיכון. שימו לב שמדריך כזה הוא מדד טוב לכך שהמפתח התמקד בתאימות והביא בחשבון את ההקלות בשדרוג.
נתוני גרסה	קוראים את נתוני הגרסה (אם הם זמינים) של כל ספרייה שעברה שינוי. מחפשים סימנים לשינויים שעשויים לגרום לשיבושים או לדרישות חדשות, כמו הרשאות שנוספו.
קובצי README	בחלק מקובצי ה-README של ספריות מפורטים סיכונים פוטנציאליים, במיוחד אם בספרייה לא מוצגים תיאורי גרסאות. מחפשים _בעיות ידועות_, במיוחד בעיות אבטחה ידועות.
בדיקת נקודות חולשה ידועות	ב-Play SDK Index מתבצע מעקב אחרי נקודות חולשה בערכות SDK פופולריות רבות. מערכת Play Console מדווחת אם אתם משתמשים באחת מערכות ה-SDK הרשומים עם נקודות חולשה ידועות. כשעורכים קובצי build ב-Android Studio, סביבת הפיתוח המשולבת (IDE) בודקת את אינדקס ה-SDK ומסמנת את השימוש בגרסאות של ספריות שחשופות לפגיעה. המכון הלאומי לתקנים וטכנולוגיה (NIST) מנהל מסד נתונים לאומי של נקודות חולשה (NVD). הפלאגין Dependency Check ל-Gradle בודק את יחסי התלות שבהם אתם משתמשים מול NVD. כדי להשתמש ב-Dependency Check, מבקשים מפתח API של NVD, מגדירים את הפלאגין של Gradle ומריצים את ./gradlew dependencyCheckAnalyze. לתשומת ליבכם, הפעולה הזו עשויה להימשך זמן רב.
התנגשויות בין גרסאות	האם הגרסאות מגיבות כמצופה? כדאי לבדוק אם יש סתירות, במיוחד הבדלים משמעותיים בין הגרסאות. במאמר פתרון יחסי התלות ב-Gradle מוסבר איך לחפש התנגשויות. באופן ספציפי, צריך לחפש את הערך -> בדוח ./gradlew app:dependencies. כשהדבר אפשרי, כדאי לעבוד עם מחברי יחסי התלות כדי לפתור את הבעיות. אם החברה מאפשרת זאת, אפשר לתרום שינויים לספרייה (העלאה ל-upstream) כדי לשפר את התאימות שלה.
בדיקת הרישיונות	כשמשדרגים ספרייה, חשוב לבדוק אם יש שינויים ברישיונות. יכול להיות שהספרייה עצמה תשתנה לרישיון שלא תואם יותר לאפליקציה או לספרייה שלכם. יחסי תלות טרנזיטיביים חדשים עלולים גם להציג רישיונות לא תואמים. במאמר אימות רישיונות מוסבר איך בודקים את קבוצת הרישיונות הנוכחית בכל יחסי התלות.
סיכוני תחזוקה ואיכות	בספריות עם מאגרים ציבוריים: כמה שותפים מנהלים את הספרייה? מתי בוצע השדרוג האחרון, ותדירות השינוי בספרייה? איך נראה עומס הבקשות הפתוחות (אם יש כזה)? כדאי לקרוא אותו בעיון כדי לקבל מושג על בעיות פוטנציאליות ועל החוב הטכני של הספרייה. עד כמה בדיקות היחידה מכסות את הספרייה? האם יש אנטי-דפוסים ידועים ב-codebase? האם הספרייה מתועדת היטב? האם יש הרבה תגובות _fixme_ ב-codebase?
קוד פתוח לעומת קוד סגור	אם הספרייה היא קוד פתוח, קל יותר לנפות באגים בהשוואה לקוד סגור, בין שהבעיות נמצאות בקוד שלכם ובין שהן נמצאות בקוד הספרייה. מצמצמים את התלות של מקורות סגורים ומיישמים בחינה נוספת במהלך ההערכה שלהם. האם יש חלופות טובות שמתאימות לתרחיש לדוגמה שלכם? אילו הסכמי רמת שירות זמינים לספריות עם קוד סגור? אם בוחרים להשתמש בספרייה של קוד פתוח, צריך להיות מוכנים לכתוב תרחישי בדיקה נוספים כדי לצמצם את הסיכונים.

הרצת build

מריצים את הפרויקט. מחפשים שגיאות או אזהרות חדשות. אם אתם מצליחים לזהות איזו ספרייה גורמת לבעיות, ציינו זאת כסיכון לשדרוג הספרייה הזו.

אם מופיעות אזהרות חדשות לגבי ירידת ערך, מוסיפים אותן כסיכונים ספציפיים לספרייה שמפיקה אותן. אפשר להסיר אותם בגרסאות עתידיות. אם אתם רוצים להמשיך להשתמש בספרייה הזו, כדאי להקדיש זמן כדי להמיר את השימוש בממשקי ה-API הישנים לממשקי ה-API החלופיים, או לרשום את ההוצאות משימוש כדי לעקוב אחרי הפונקציות האלה ולבדוק אם הן יוסרו בהמשך.

שימוש ב-lint לזיהוי בעיות ב-API

איתור שגיאות בקוד ב-Android יכול לאתר בעיות רבות באפליקציה, כולל בעיות שנובעות משינוי גרסאות של יחסי תלות או Android SDK. לדוגמה, אם משדרגים את compileSdk ומשתמשים בממשקי ה-API החדשים שלו, הכלי מדווח על אלה שלא זמינים בגרסאות קודמות של ה-SDK.

Lint פועל בעורך של Android Studio ומדווח על בעיות בזמן ביצוע השינויים. אבל בדרך כלל הוא לא פועל כחלק מה-build ב-Studio או כשמריצים build בשורת הפקודה, אלא אם משתמשים ביעדים build או lint.

אם אתם משתמשים ב-Continuous Integration (CI), כדאי להריץ את gradlew build או את gradlew lint במהלך ה-builds של ה-CI (או לפחות ב-builds היומיים) כדי לזהות את סוגי השגיאות האלה.

אם אתם לא משתמשים ב-CI, הקפידו להריץ את gradlew lint מדי פעם לפחות.

הערה: כללי איתור שגיאות כלליים וכללי איתור שגיאות ברמת Android SDK מסופקים עם AGP, וכללים ספציפיים לספריות נארזים עם הספריות שלהם. חשוב לוודא ש-AGP ויחסי התלות בספריות עדכניים ככל האפשר, כדי לוודא שכל כללי האיתור של שגיאות בקוד (lint) העדכניים ביותר חלים על הקוד שלכם. חשוב במיוחד לעשות זאת לגבי כללי איתור שגיאות בקוד חדשים שנוספו או שודרגו לגרסה חדשה של Android SDK.

חשוב לשים לב במיוחד לשגיאות ולאזהרות של איתור שגיאות בקוד. ספריות מסוימות כוללות בדיקות ניקוי קוד משלה, שעוזרות להבטיח שימוש תקין ב-API שלהן. גרסאות חדשות מסוימות של ספרייה כוללות אזהרות ושגיאות חדשות של איתור שגיאות בקוד, וכתוצאה מכך יתקבלו דוחות חדשים בזמן ה-build.

צמצום סיכונים

אחרי שמגדירים סיכוני שדרוג, מחליטים איך לצמצם אותם:

• לקבל סיכונים מסוימים כפי שהם. חלק מהסיכונים נמוכים מספיק כדי להיות מקובלים, במיוחד כשזמן השדרוג והמשאבים מוגבלים.
• לדחות סיכונים מסוימים באופן מוחלט. יכול להיות שחלק מהשדרוגים ייראו מסוכנים מדי, במיוחד אם יש לכם זמן או משאבים מוגבלים לצמצם את הסיכון בשלב הזה. אם אתם צריכים לבצע בדיקה, התמקדו בשדרוגים שנחוצים לבאגים שנתקלתם בהם או לתכונות חדשות שנדרשות לכם.
• צמצום הסיכונים הנותרים
  • מומלץ לקבץ את השדרוגים לקבוצות קטנות יותר של שינויים עצמאיים. כך אפשר לצמצם את הסיכון הכולל ולחזור למצב הקודם באופן חלקי.
  • בודקים את השינויים בפירוט.
  • בודקים את האפליקציה כדי לבדוק אם יש שינויים לא צפויים. מוסיפים בדיקות חדשות לפי הצורך כדי לקבל ביטחון בשדרוג.
  • אם מוצאים משהו שנוי במחלוקת, כדאי לבדוק את המקור (אם הוא זמין).
  • מבצעים את השינויים הנדרשים במקור או ב-build.

לתעד את ההחלטות. אם סיכונים משדרוג הופכים לבעיות בזמן הרצת האפליקציה, תיעוד של ניתוח הסיכונים יכול לצמצם את ניתוח השגיאות הדרוש.

אימות רישיונות

מפתחי ספריות מקבלים רישיון לשימוש בספריות. עליכם לציית לתנאי הרישיון, אחרת אי אפשר להשתמש בספרייה. חלק מהרישיונות מאוד מתירניים, ולרוב נדרש רק שיוך לספרייה והצגת טקסט הרישיון שלה למשתמשי קצה. חלקן נחשבות וויראליות. אם משתמשים בספריות האלה, צריך להחיל את אותו רישיון באפליקציה או בספרייה.

הרישיונות עשויים להשתנות בכל גרסה. בכל פעם שמשדרגים, צריך לוודא שיחסי התלות שבהם אתם משתמשים מוקצים ברישיון באופן שתואם לאפליקציה או לספרייה.

אם רישיון לא תואם (או שהשתנה כך שהוא כבר לא תואם), אי אפשר להשתמש בגרסה הזו של הספרייה. אפשר:

• פנו לבעלים של הספרייה ובקשו להמשיך את הרישיון הקיים או לקבל רישיון כפול כדי להמשיך להשתמש ברישיון הישן.
• עליכם לפנות לצוות המשפטי שלכם כדי לבדוק אם תוכלו לשנות את הרישיון כך שיהיה תואם.
• מוצאים ספרייה אחרת עם רישיון תואם ומשנים את האפליקציה לפי הצורך.
• יוצרים פורק (fork) של הגרסה האחרונה התואמת של הספרייה (אם הרישיון מאפשר יצירה של נגזרות והשינויים לא רטרואקטיביים) ומבצעים את השינויים שלכם.