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

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

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

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

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

יצירת ספרייה	האם אתם מפתחים אפליקציה שהמשתמשים מורידים ומפעילים במכשיר? או שאתם יוצרים ספרייה כדי לעזור למפתחים אחרים ליצור אפליקציות? אם אתם מפתחים אפליקציה, עליכם להתמקד בשמירה על עדכניות ויציבות של האפליקציה. אם אתם מפתחים ספרייה, כדאי להתמקד באפליקציות של מפתחים אחרים. השדרוגים משפיעים על הצרכנים שלכם. אם משדרגים את אחת מהתלות, הגרסה הזו הופכת למועמדת לפתרון התלות ב-Gradle, ויכול להיות שהשימוש של האפליקציה בתלות הזו ייפגע. קודם כול, צמצום יחסי התלות של הספרייה ככל האפשר. ככל שיש לכם פחות יחסי תלות, כך ההשפעה על פתרון יחסי התלות של הצרכן קטנה יותר. חשוב לפעול בהתאם לשיטת ניהול הגרסאות הסמנטית כדי לציין את סוגי השינויים שאתם מבצעים. לדוגמה, ב-AndroidX נעשה שימוש במערכות ניהול גרסאות סמנטיות, עם סכימה לניהול גרסאות של גרסאות טרום-הפצה. נסו להימנע משדרוגים לגרסה major כדי לא לגרום לשיבושים אצל הצרכנים. כדאי ליצור גרסה מועמדת להשקה (RC) של הספרייה כדי שהמשתמשים יוכלו לבדוק אותה בשלב מוקדם. בהנחיות בנושא תאימות לאחור לכותבי ספריות מוסבר איך לשמור על תאימות של ממשק ה-Application Binary Interface ‏ (ABI) של הספרייה. כדאי להשתמש בבדיקות אינטגרציה ובכלים כמו Binary compatibility validator כדי לוודא ששינויי ה-ABI תואמים לשינוי הגרסה המיועד. אם תפיצו תיקונים ב-patch לגרסאות נמוכות יותר של הספרייה, הצרכנים לא יצטרכו לשדרג את הספרייה לגרסה הבאה של major או minor, אלא אם הם רוצים תכונות חדשות. מומלץ להימנע משדרוג של יחסי תלות טרנזיטיביים בשדרוגים האלה. אם השדרוג של הספרייה מחייב שינויים משמעותיים שעשויים להיות קשים במיוחד לצרכנים, כדאי לשקול לפרסם אותם כפריט חדש כדי שהגרסה הישנה והגרסה החדשה יוכלו להתקיים זו לצד זו ולאפשר השקה הדרגתית יותר. הערה: אם השדרוג של אחת מהתלות מכיל שינוי משמעותי ב-API, מומלץ לשדרג אותו במהדורה major או minor ולבצע את השינויים הנדרשים. אם לא תעשו זאת, משתמשי הספרייה עשויים לעשות זאת, וכתוצאה מכך יהיו אי-תאימות בין הספרייה לבין הספרייה התלויה. יכול להיות שהדבר יקרה גם אם לא יהיו שינויים בספרייה. אפשר לפרסם גרסה חדשה רק כדי לשדרג את התלות הזו.
מחזור הפצה	באיזו תדירות אתם משחררים את האפליקציה או הספרייה? מחזורי פיתוח והשקה קצרים יותר נותר פחות זמן לשדרוג. אתם יכולים להיעזר בהם כדי לא להתעכב. שדרוגים קטנים תכופים יכולים להקל על עומס העבודה. אם שדרוג של ספרייה יגרום לבעיות, תוכלו לבטל את השדרוג מהר יותר. כלים כמו Dependabot ו-Renovate מפחיתים את עומס העבודה, אבל חשוב לנתח את התוצאות כדי לבדוק אם יש סיכונים. מחזורי פיתוח והשקה ארוכים יותר יש לכם יותר זמן לבצע שדרוגים ולבדוק אותם. סביר להניח שגרסאות חדשות יותר של יחסי התלות יפורסמו במהלך המחזור. החזרה לאחור של שדרוגים והשקה מחדש של האפליקציה או הספרייה נמשכים זמן רב יותר.
איך להתעדכן בתכונות החדשות	האם אתם מעדיפים להשתמש בתכונות ובממשקי ה-API העדכניים ביותר, או לשדרג רק כשאתם צריכים תכונה או תיקון באג? כדאי לשקול את היתרונות והחסרונות של שדרוגים תכופים. שדרוגים עתידיים יהיו קלים יותר (פחות שינויים לשילוב), אבל תצטרכו להסתכן בשדרוגים בתדירות גבוהה יותר. בדיקת שדרוגים לגרסאות טרום-השקה (אלפא, בטא, גרסה מועמדת להשקה) של ספריות יכולה לעזור בהכנה לקראת זמינות של גרסאות יציבות.
תלות חדשה	אם מוסיפים יחסי תלות חדשים, כדאי להשתמש בתהליך בדיקה יסודי שבודק את הספרייה בכל קריטריוני הסיכון כדי לוודא שהם הוערכו כראוי. לא לאפשר הוספה של יחסי תלות חדשים ללא בדיקה.
צוות ייעודי	האם יש לכם צוות ייעודי ל-build? האם מהנדסי התוכנה שלכם אחראים על התחזוקה של ה-build? לרוב, צוות ייעודי יכול להקדיש יותר זמן לניתוח סיכוני השדרוג ולבדיקת הגרסאות החדשות כדי לוודא שה-build פועל כמו שצריך לפני שהמהנדסים משתמשים בגרסאות החדשות.
סוג השדרוג	יש שדרוגים חשובים יותר מאחרים. כדאי לחשוב אילו תכונות הכי חשובות לכם. בדרך כלל, לשדרוגים של כלי build, כמו Gradle ופלאגינים של Gradle, יש השפעה פחותה על המשתמשים, ורוב הסיכון הוא פנימי ל-build. ה-build עצמו עוזר לאמת את השינויים האלה. קשה יותר לאמת שדרוגים של ספריות ו-SDK, והם מהווים סיכון גבוה יותר למשתמשים. Android Gradle Plugin‏ (AGP) – כלי ה-build המשמשים ליצירת האפליקציה או הספרייה של 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 שיכול לעזור במשימות האלה. אם אתם משתמשים במסנן או מבצעים את השדרוג באופן ידני, כדאי לשקול את הנושאים הבאים: הערות הגרסה של APG משדרגים את Gradle לפחות לגרסה שמופיעה ברשימה. משדרגים את Android Studio לגרסה שתומכת בגרסה שנבחרה של AGP. משתמשים בגרסאות של Android Studio ו-AGP שתומכות ב-Android SDK שבו רוצים להשתמש. בודקים את התאימות ל-SDK Build Tools,‏ NDK ו-JDK. אם אתם מפתחים פלאגין של Gradle (לשימוש פנימי או ציבורי) שמרחיב את AGP או משתמש בנתונים ממנו, כדאי לבדוק אם אתם צריכים לשדרג את הפלאגין. לפעמים AGP מפסיקה את השימוש בממשקי API ומסירה אותם מאוחר יותר, מה שגורם לאי-תאימות עם יישומי פלאגין קודמים.
השפה, הזמן הריצה והמחשב של Kotlin	כדאי לעיין בהערות המוצר של Kotlin כדי לבדוק אם יש בעיות מוכרות או חוסר תאימות. אם אתם משתמשים ב-Jetpack פיתוח נייטיב: אם גרסת Kotlin החדשה נמוכה מ-2.0.0: מאתרים את הפלאגין התואם של Compose compiler. משדרגים את kotlinCompilerExtensionVersion ב-build.gradle.kts של כל המודולים שבהם הוא מופיע. אם גרסת Kotin החדשה היא 2.0.0 ואילך: מגדירים את Compose Compiler Gradle Plugin באותה גרסה כמו של קומפילטור Kotlin. אם אתם משתמשים ב-Kotlin Symbol Processing‏ (KSP), תוכלו לעיין במדריך למתחילים בנושא KSP כדי לקבל מידע על ההגדרה, ובגרסאות KSP כדי לקבל מידע על הגרסאות הזמינות. חשוב לזכור שצריך להשתמש בגרסה של KSP שתואמת לגרסה של Kotlin. לדוגמה, אם אתם משתמשים ב-Kotlin 2.0.21, תוכלו להשתמש בכל גרסה של הפלאגין KSP שמתחילה ב-2.0.21, למשל 2.0.21-1.0.25. בדרך כלל לא תצטרכו לשדרג את מעבדי KSP (כמו הקומפילר של Room, שמופיע כיחס תלות ksp בקובצי ה-build). הפלאגין של KSP מספק הפשטה של חלק גדול מ-API של הקומפילר, ו-KSP API שמשמש את המעבדים יציב. שדרוג של כל יתר הפלאגינים של Kotlin Compiler שבהם אתם משתמשים. ממשק ה-API של פלאגין קומפילר Kotlin משתנה לעיתים קרובות בין גרסאות, והפלאגינים חייבים להשתמש ב-API תואם. אם הפלאגין מופיע בקטע Compiler plugins, צריך להשתמש באותה גרסה כמו של קומפילר Kotlin. לגבי כל פלאגין אחר ל-compile, צריך לבדוק את המסמכים שלו כדי למצוא את המיפוי המתאים. חשוב לזכור שפלאגינים של קומפילטור שלא מתוחזקים לצד קומפילטור 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 יש כלי לשדרוג Android SDK שיכול לעזור במשימות האלה. אם אתם משתמשים במאמן או מבצעים את השדרוג באופן ידני, כדאי לשקול את הדברים הבאים: כל גרסה של Android SDK כוללת תכונות וממשקי API חדשים, תיקוני באגים ושינויים בהתנהגות. חובה לעדכן את targetSdk בחנות Play, אבל מומלץ לעדכן את targetSdk לפני המועדים הסופיים כדי שיהיה לכם מספיק זמן לבצע את השינויים הנדרשים. לפני שמשדרגים את Android SDK, חשוב לקרוא בעיון את הערות המוצר. חשוב לשים לב לקטע 'שינויים בהתנהגות', שכולל את הפרטים הבאים: הרשאות חדשות שתצטרכו לבקש בזמן ההתקנה או בזמן הריצה. ממשקי API שהוצאו משימוש והחלופות שלהם. שינויים קיצוניים בממשקי API או בהתנהגות. ממשקי API חדשים של Kotlin או Java, שעשויים להשפיע על הקוד שלכם. הקטע 'שינויים בהתנהגות' יכול להיות ארוך למדי, אבל חשוב להקדיש לו תשומת לב רבה כי לרוב הוא מכיל שינויים קריטיים שצריך לבצע באפליקציה. צריך לשדרג את targetSdk כדי לעמוד בדרישות של חנות Play. השדרוג של 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… הכלי לשדרוג Android SDK…
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 ב-Android build.

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

שדרוג של יחסי תלות עלול להוביל לסיכונים כמו שינויים ב-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).

חשוב לזכור ש-Dependency Guard מתעד רק את רשימת יחסי התלות בספריות. יש יחסי תלות אחרים בקובצי ה-build, כמו גרסאות Android SDK ו-JDK. ביצוע השמירה במערכת ה-VCS לפני ששינויים ביחסי התלות מאפשרים להדגיש את השינויים האלה גם ב-diff של מערכת ה-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 Archives‏ (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, סביבת הפיתוח המשולבת בודקת את מדד ה-SDK ומסמנת שימוש בגרסאות ספרייה חשופות. המכון הלאומי לתקנים וטכנולוגיה (NIST) מנהל מסד נתונים לאומי של נקודות חולשה (NVD). הפלאגין Dependency Check ל-Gradle בודק את יחסי התלות שבהם אתם משתמשים מול NVD. כדי להשתמש ב-Dependency Check, מבקשים מפתח API של NVD, מגדירים את הפלאגין של Gradle ומריצים את ./gradlew dependencyCheckAnalyze. לתשומת ליבכם, הפעולה הזו עשויה להימשך זמן רב.
התנגשויות בין גרסאות	האם הגרסאות נפתרות כמצופה? מחפשים קונפליקטים, במיוחד הבדלים משמעותיים בגרסאות. במאמר פתרון יחסי התלות ב-Gradle מוסבר איך לחפש התנגשויות. באופן ספציפי, מחפשים את -> בדוח ./gradlew app:dependencies. כשהדבר אפשרי, כדאי לעבוד עם מחברי יחסי התלות כדי לפתור את הבעיות. אם החברה מאפשרת זאת, אפשר לשלוח שינויים לספרייה (upstreaming) כדי לשפר את התאימות שלה.
בדיקת הרישיונות	כשמשדרגים ספרייה, חשוב לבדוק אם יש שינויים ברישיונות. יכול להיות שהספרייה עצמה תשתנה לרישיון שלא תואם יותר לאפליקציה או לספרייה שלכם. יחסי תלות טרנזיטיביים חדשים עלולים גם להציג רישיונות לא תואמים. במאמר אימות רישיונות מוסבר איך בודקים את קבוצת הרישיונות הנוכחית בכל יחסי התלות.
סיכוני תחזוקה ואיכות	בספריות עם מאגרים ציבוריים: כמה שותפים מנהלים את הספרייה? מתי בוצע השדרוג האחרון, ותדירות השינוי בספרייה? איך נראה עומס הבקשות הפתוחות (אם יש כזה)? כדאי לקרוא אותו בעיון כדי לקבל מושג על בעיות פוטנציאליות ועל החוב הטכני של הספרייה. עד כמה בדיקות היחידה מכסות את הספרייה? האם יש דפוסים שליליים מוכרים בקוד? האם הספרייה מתועדת היטב? האם יש הרבה תגובות _fixme_ בקוד?
קוד פתוח לעומת קוד סגור	אם הספרייה היא בקוד פתוח, קל יותר לנפות באגים בהשוואה לקוד סגור, בין שהבעיות נמצאות בקוד שלכם ובין שהן נמצאות בקוד הספרייה. צמצום יחסי התלות במקורות סגורים וביצוע בדיקה נוספת במהלך ההערכה שלהם. האם יש חלופות טובות שמתאימות לתרחיש לדוגמה שלכם? אילו הסכמי רמת שירות זמינים לספריות עם קוד סגור? אם בוחרים להשתמש בספרייה עם תלות במקור סגור, צריך להיות מוכנים לכתוב עוד תרחישי בדיקה כדי לצמצם את הסיכונים.

הרצת build

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

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

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

Android lint יכול לזהות בעיות רבות באפליקציה, כולל בעיות שנובעות מגרסאות משתנות של יחסי התלות או של 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) של הגרסה האחרונה התואמת של הספרייה (אם הרישיון מאפשר יצירה של נגזרות והשינויים לא רטרואקטיביים) ומבצעים את השינויים שלכם.