כך בונים את נתיב הזהב הראשון שלכם ל-Azure בפלטפורמת מפתחים פנימית (IDP)

By Mirko Peters · 2026-08-13

למדו כיצד לתכנן, לאוטומט וליישם את נתיב הזהב הראשון שלכם ל-Azure בתוך פלטפורמת מפתחים פנימית (IDP), כדי לצמצם את החיכוכים שחווים המפתחים.

Automatically translated with AI from the original post. Read the English original

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

עיקרי הדברים

• התחילו את מסע הנדסת הפלטפורמה שלכם בתהליך עבודה אחד שכואב למפתחים ומתרחש שוב ושוב, ולא בניסיון לבנות פלטפורמה שלמה בבת אחת.
• נתיב זהב טוב ל-Azure מקצה אוטומטית מאגרי קוד, צינורות CI/CD, זהויות מנוהלות, סודות ב-Key Vault וניטור.
• ברירות מחדל סבירות מפחיתות משמעותית את עייפות ההחלטות, ועדיין מאפשרות מוצאי חירום מבוקרים לדרישות יוצאות דופן של אפליקציות.
• שימוש בכלי תשתית כקוד כמו Bicep או Terraform מבטיח שארכיטקטורת Azure הבסיסית תישאר עקבית וניתנת למעקב.
• מדידה של קיצור זמני האספקה וירידה בפניות להקמה תעזור להוכיח לבעלי העניין את הערך של ההשקעה הראשונית בפלטפורמה.

זיהוי תהליך העבודה הנכון להתחלה

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

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

אוטומציה של שכבת התשתית ב-Azure

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

כלים כמו Bicep או Terraform מאפשרים להגדיר במפורש את המצב הרצוי של סביבת Azure שלכם. כאשר מפתח מפעיל את ה-Golden Path, הפלטפורמה צריכה לספק באופן אוטומטי את סביבת האירוח הנדרשת, כמו Azure App Service או Azure Kubernetes Service, יחד עם גבולות הרשת הנחוצים, חשבונות אחסון ומופעי מסדי נתונים. בנוסף, קוד התשתית שלכם צריך להחיל אוטומטית תגיות חובה למעקב עלויות, לסיווג סביבות ולבעלות צוותית, כך שהממשל הארגוני לא יסתמך לעולם על הזיכרון האנושי.

שילוב אבטחה וזהות בתוך ה-Golden Path

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

התחילו בהגדרת Microsoft Entra ID כדי לקבוע בקרות גישה נכונות לפי עיקרון ההרשאות המינימליות. מפתחים צריכים לקבל רק את ההרשאות הדרושות לניהול השירותים הספציפיים שלהם, בסביבות הפיתוח שהוגדרו עבורם. לאחר מכן, הפסיקו את ההרגל המסוכן של שמירת סיסמאות למסדי נתונים ומפתחות API בתוך קובצי הגדרות של היישום או במאגרי קוד מקור. במקום זאת, הגדירו ב-Golden Path הקצאה אוטומטית של Azure Key Vault והקצאת managed identity ליישום. כך לתוכנה שלכם יש "תג דיגיטלי" מאובטח לאימות מול שירותי Azure אחרים, מה שמפחית משמעותית את משטח התקיפה מבלי להכביד על המפתח.

חיבור תצפיתיות וקטלוגי שירותים

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

בנוסף, בכל פעם שה-Golden Path מסתיים בהצלחה, הוא צריך לרשום את היישום החדש בקטלוג השירותים המרכזי שלכם. מיפוי זה מבטיח שלארגון תמיד יהיה תיעוד ברור של התוכנה הפעילה, הכולל בעלות מוגדרת, מיקומי קוד מקור ב-GitHub או ב-Azure DevOps וקישורים ישירים לספרי ההפעלה התפעוליים. כאשר מתרחש אירוע בשתיים בלילה, מהנדסי התורנות ידעו מיד מי הבעלים של השירות והיכן נמצאים הלוגים שלו, וחיפוש מתיש של שעות יהפוך לעניין של שניות.

סיכום

בניית ה-Golden Path הראשון היא הדרך היעילה ביותר להניע הנדסת פלטפורמות בארגון. על ידי התמקדות בתהליך עבודה אחד בעל חיכוך גבוה, אוטומציה של תשתית Azure באמצעות Bicep או Terraform, שילוב מנגנוני הגנה וחיבור לתצפיתיות, תוכלו להאיץ משמעותית את אספקת התוכנה ולשמור על סביבת הענן שלכם מאובטחת ותואמת לרגולציה.

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

שאלות נפוצות

איזה תהליך עבודה כדאי לבחור ל-Golden Path הראשון שלכם?

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

כיצד מטפלים ביישומים שדורשים תשתית Azure מותאמת אישית?

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

האם יש להשתמש ב-Bicep או ב-Terraform לבניית Golden Path ב-Azure?

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

כיצד זהויות מנוהלות משתלבות ב-Golden Path של Azure?

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