הגדרת מאגר Maven פרטי (Nexus) לפרויקטי Java

למה נשברות בניות בלי מאגר Maven פרטי

הבנייה עוברת על המכונה של המפתח ונופלת ב-CI עם שגיאת רזולוציית תלויות — מפני שהספרייה הפרטית נשארה רק במטמון המקומי ~/.m2.

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

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

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

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

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

מה משתנה בבנייה ובאספקה אחרי ההטמעה

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

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

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

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

פרוקסי, אחסון וקבוצת מאגרים: מה לבחור

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

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

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

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

שלבי ההטמעה: מביקורת תלויות ועד מסירה

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

1. ספירת מלאי של תלויות. עוברים על כל המודולים ואוספים את רשימת הארטיפקטים בפועל: מה נמשך ממקורות חיצוניים, מה מפורסם על ידי הבנייה שלכם, אילו גרסאות מקובעות בקבצי האב. בפלט — רשימת קבוצות עם תדירות פניות, לפיה מחשבים את נפח האחסון ואת הצורך במראות.
2. סכימת פריסה. קובעים כמה מאגרים נדרשים: פרוקסי למקורות חיצוניים, פנימי לארטיפקטים שלכם, קווים נפרדים לבניות ביניים ולבניות מהדורה. רושמים את סדר החיפוש, כדי שהבנייה לא תצא לרשת החיצונית בשביל מה שכבר נמצא מקומית.
3. הגדרת הרשאות גישה. מפרידים בין תפקידים: חשבונות של שרשרת הבנייה מקבלים קריאה וכתיבה רק בקבוצות שלהם, מפתחים — קריאה ופרסום בספריות שהוקצו להם, מנהלים — ניהול. הפרסום נעשה תחת חשבון נפרד, המשויך לפרויקט מסוים, ולא תחת חשבון משותף.
4. בדיקה על פרויקטים אמיתיים. קודם ממלאים את מאגרי הפרוקסי, אחר כך בונים שניים-שלושה פרויקטים עם מטמון מקומי מרוקן לחלוטין. כך רואים שאף תלות לא נמשכת בעקיפין, ושהבנייה עוברת על מכונה נקייה.
5. מסירה לתפעול. מוסרים את כללי הגישה המתוארים, תקנון גיבוי, ניטור מקום פנוי וסדר הסלמה. צוות הלקוח חוזר בעצמו על הפעולות השגרתיות — פרסום, ביטול גרסה, הוספת פרויקט.

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

ערכת מסירה: קונפיגורציות, סכימות, תקנונים

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

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

מקרה בוחן: העברת בניות ממקור ציבורי למאגר משלכם

לפני: הבנייה הייתה תלויה בצומת של מישהו אחר

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

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

מה עשינו

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

התוצאה

מעבר בנייה ממוצע התקצר מ-12–14 ל-6–7 דקות, ומספר העצירות בגלל זמינות חיצונית ירד למקרים בודדים ברבעון. כל 28 הפרויקטים הועברו לנקודת כניסה אחודה, כולל מודולים ישנים עם ההגדרות שלהם.

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

מה עושים אם כבר פרוס אצלכם שרת ארטיפקטים משלכם?

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

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

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

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

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

בירור ספקות: עדכונים, גישה, עמידות בתקלות

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

איך נותנים גישה לקבלן בלי לפתוח את כל המאגר?

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

מה יקרה אם המאגר אינו זמין?

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

כמה מהר גדל נפח האחסון?

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

האם יהיה צורך לשנות את קבצי הבנייה?

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

נדבר על המשימה ונחזור עם הערכה ותוכנית

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

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

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