היום חשוב מאוד לעדכן את האפליקציות, אבל זה גם קשה. במאמר הזה מפורטים כמה שלבים בסיסיים למפתחי Java שרוצים להתחיל ליישם שיטות עבודה של DevOps. זו רשימה חלקית בלבד. רוב הרעיונות האלה מגיעים ממחקרים של DORA בנושא DevOps, שמספקים סקירה מלאה יותר של שיטות מומלצות. מקורות נוספים כוללים את הספרים Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations מאת Nicole Forsgren PhD, Jez Humble ו-Gene Kim, ואת הספר Software Engineering at Google בעריכת Titus Winters, Tom Manshreck ו-Hyrum Wright.
לפני שקוראים את הדף הזה, מומלץ לקרוא את המאמר הגדרת סביבת פיתוח בשפת Java.
הצרכים של כל ארגון פיתוח הם ייחודיים, אבל אפשר לבנות מערכת בסיסית באמצעות אחת מהטכנולוגיות הבאות:
| דוגמה לסטאק טכנולוגיות 1 | דוגמה לסטאק תוכנות 2 |
|---|---|
|
|
מערכת שמורכבת מהרכיבים האלה יכולה לעזור לכם לשפר את האיכות ואת משך מחזור הפעילות. הוא גם יכול לעזור לכם לשמור על קוד מעודכן עם תיקוני הבאגים ועדכוני האבטחה האחרונים.
ניהול גרסאות
מחקר (עמוד 17 , עמוד 14 , עמוד 31 ועמוד 60) גילה שבקרת גרסאות לקוד מקור בשילוב עם אוטומציה ובדיקות, מאפשרת לשפר את האיכות וליהנות מיתרונות רבים אחרים.
- Cloud Source Repositories [מדריך למתחילים] מספק תהליך עבודה חינמי של Git לקוד המקור.
- Artifact Registry [קונטיינרים] [חבילות Java] הוא מקום מצוין לשמירת ארטיפקטים של Java שנוצרו.
GitHub, Gitlab ו-Bitbucket הן פלטפורמות טובות לאירוח קוד המקור.
בדיקות אוטומטיות
בדיקת אוטומציה יכולה להיות קריטית להצלחה שלכם בשימוש ברוב הטכניקות האלה. למידע נוסף על שיטות מומלצות לבדיקות, אפשר לעיין בפרק בנושא בדיקות לצורך אמינות בספר SRE ובבלוג בנושא בדיקות של Google.
מפתחי Java מתעניינים בעיקר בבדיקות יחידה אוטומטיות ובבדיקות שילוב. JUnit, Testing with Spring, Apache Maven Surefire ו-Gradle Java testing הם מקורות מידע שימושיים למפתחי Java.
אוטומציה של אינטגרציה רציפה (CI) ופריסה
אינטגרציה רציפה ואוטומציה של פריסה הן הבסיס לעבודות DevOps מודרניות. פיתוח, בדיקה ופריסה.
- Cloud Build [מדריכים למתחילים] [מדריכים ספציפיים ל-Java] [פריסה] [טריגר] מספקת בחינם (120 דקות build ביום) או במחיר נמוך מערכת build קלה לשימוש שניתן להתאים אותה בקלות לרוב המשימות.
- Tekton הוא פרויקט בקוד פתוח שמאפשר לכם להתאים את הרעיונות של Cloud Build למערכות שלכם.
- Spinnaker היא פלטפורמה בקוד פתוח לפיתוח רציף (continuous delivery) מרובה עננים (multi-cloud), שעוזרת לכם להפיץ שינויים בתוכנה במהירות ובביטחון. הוא עוזר לכם לנהל את התהליך של הפצה והחזרה של מערכות תוכנה מורכבות.
- GitHub's Actions הוא פתרון של צד שלישי שמאפשר להגדיר בדיקות ולהריץ אותן ב-GitHub.
- יש גם פתרונות רבים אחרים, כמו Gitlab, Circle CI ו-Travis CI.
ספריות לקוח ב-Cloud
יש הרבה דרכים להשתמש בשירותי Google, אבל הדרך המומלצת היא לפעול לפי ההוראות בדף ספריות הלקוח של Cloud. ב-Java, Libraries-BOM יכול לעזור לכם לוודא שאתם משתמשים בגרסאות תואמות של כל ארטיפקט.
אם תבחרו גרסאות משלכם של ספריות לקוח, יכול להיות שתיבחר גרסה לא תואמת של ארטיפקט. הבעיה הזו נקראת בעיית התלות בצורת יהלום. אם עדיין צריך לבחור את הספריות האישיות, צריך לעדכן אותן אחת בכל פעם ולבדוק אם העדכון גרם לשגיאה. הגרסאות האחרונות תמיד מופיעות בדף הזה, או שאפשר למצוא אותן בחיפוש ב-Maven-Central.
שמירה על עדכניות של יחסי התלות
כדי להגן על עצמכם מפני גורמים זדוניים, חשוב מאוד לשמור על עדכניות של התלויות. יש הרבה כלים של צד שלישי שיכולים לעזור לכם:
אם מגדירים את הכלים האלה בצורה נכונה, הם עוזרים לשמור על עדכניות של התלויות. כשמשלבים בדיקות אוטומטיות עם אינטגרציה רציפה (CI) / פריסה רציפה (CD), התהליך הוא כזה:
- אוטומציית התלות מציעה שינוי בבקרת המקור.
- מערכת ה-build הרציף יוצרת את השינוי ובודקת אותו.
- בודק אנושי בודק את ההצעה, ואם היא מקובלת, הוא מאשר את השינוי, אולי יחד עם שינויים אחרים.
- אחרי שהשינויים מאושרים, מוצע למערכת הפיתוח הרציף (Continuous Delivery) לפרסם את הקוד בסביבת הייצור. (או שפועלים לפי התהליך המותאם אישית שלכם).
שימוש בסביבת זמן ריצה של Java (JRE) נתמכת
JRE, קבוצת משנה של Java Development Kit, נמצאת מעל מערכת ההפעלה ומספקת את התוכנה והמשאבים שנדרשים להפעלת אפליקציית Java. רוב המשתמשים מעדיפים להשתמש בגרסת ה-LTS העדכנית ביותר בסביבת הייצור כדי לקבל גישה לעדכונים, לאבטחה ולתיקוני באגים. בדרך כלל אפשר לעדכן ל-JRE מאוחר יותר גם אם הקוד שלכם קומפל מול JDK מוקדם יותר.
אם אתם עובדים עם כמה גרסאות JDK, SDKMAN! יכול לעזור לכם להשתמש בגרסאות שונות של JDK ולנהל אותן.
שימוש בקונטיינרים (Google Kubernetes Engine, Cloud Run, אשכולות GKE)
אם אתם משתמשים במאגרי Docker עם RenovateBot או DependaBot, הבוט מציע עדכונים ל-JRE ול-JDK שלכם באופן תקופתי – כדאי לשמור את ה-JDK ואת ה-JRE באותה גרסה.
אם מעדכנים את קובץ ה-Dockerfile באופן ידני, פשוט משנים את ה-JRE לגרסה העדכנית ביותר ומבצעים בנייה מחדש.
שימוש ב-Compute Engine
ההגדרה הזו בדרך כלל ספציפית מאוד לאפליקציה. מומלץ להשתמש בסקריפט לטעינה בזמן ההפעלה. כדי לשדרג, צריך לעדכן את הסקריפט.
סביבה גמישה של App Engine
App Engine Standard
אפשר לעיין במאמר בנושא העברת אפליקציית App Engine מ-Java 8 ל-Java 11.
שימוש בגרסת LTS של Java Development Kit
JDK היא קבוצה של כלים לפיתוח אפליקציות Java. תכונות חדשות של שפות קשורות ל-JDK מסוים. מומלץ להצמיד את השימוש ב-JDK לגרסה עם תמיכה לטווח ארוך (LTS), ולשדרג לגרסת ה-LTS הבאה כשמתאים לאפליקציה שלכם. מומלץ להשתמש בגרסה המשנית האחרונה של גרסת ה-LTS הראשית המוצמדת.
רוב המשתמשים ירצו לשמור על סנכרון בין JDK ל-JRE. לפעמים זה לא אפשרי (לדוגמה, אם אין יותר תמיכה ב-JDK), ואז צריך לבצע קומפילציה עם JDK מאוחר יותר ולהריץ ב-JRE מוקדם יותר.
כדי לעשות את זה באמצעות Maven:
מגדירים את רמת השפה שבה רוצים לכתוב קוד ואת JRE היעד. מעדכנים את הקובץ pom.xml באופן הבא (ל-Java 8):
xml
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
כדי לעדכן ל-Java 11, צריך לשנות את הערך ל:
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
אם אתם משתמשים ב-Gradle, אתם צריכים לעדכן את קובץ build.gradle של Java 8 עם:
compileJava {
sourceCompatibility = 1.8
targetCompatibility = 1.8
}
או ב-Java 11:
compileJava {
sourceCompatibility = 11
targetCompatibility = 11
}
שימו לב שבגרסה Java 8 ובגרסאות קודמות, הגרסאות כללו קידומת 1. (1.7 ל-Java 7, 1.8 ל-Java 8) שהוסרה אחרי Java 8.