ארכיטקטורת Self-Service של פלטפורמה למפתחים

הושלם

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

רכיבי Self-Service מפתחים

בסיס של שירות עצמי למפתחים מורכב מכמה רכיבים עיקריים שפועלים יחד כדי לייעל זרימות עבודה של מפתחים להפוך לאוטומטיות. רכיבים אלה כוללים את ה- API של פלטפורמת המפתחים של , Developer Platform Graph, Developer Platform Orchestrator, Developer Platform Providersו- User Profile and Team Metadata.

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

משלים את ה- API של פלטפורמת המפתחים הוא Developer Platform Graph, מבנה נתונים מאובטח ומנוהל שמקל על הגילוי והשיוך של ישויות ותבניות בתוך הפלטפורמה. ישויות מצרפות נתונים ממקורות מרובים, בעוד שתבניות מנונות קלט של משתמשים לאוטומציה.

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

כדי לבצע פעולות מבוססות-תבנית, Developer Platform Orchestrator מנתב ומעוקבת אחר בקשות, תיאום עם ספקי פלטפורמה למפתחי מיוחדים שמשתלבות עם מערכות במורד הזרם. Orchestrator מאפשר למפתחים או למערכות לבקש פעולות באמצעות תבניות, מבלי לבצע את הפעולות ישירות. היא מתואמת למנגנון משימות, למנוע זרימת עבודה או ל- orchestrator אחר כדי לבצע את הפעולות. רכיב זה חיוני להפיכת שירות עצמי לזמין, מכיוון שהוא מאפשר למפתחים להפעיל פעולות ללא צורך בהרשאות ישירות. בניגוד ל- CI/CD, פעולות אלה אינן מוגבלות לקוד המקור של היישום. מנועי זרימת עבודה כגון GitHub Actions או Azure Pipelines יכולים לשמש כמתזים, אך הפשטה יכולה להיות שימושית לתמיכה במנועים שונים לאורך זמן. גמישות זו מאפשרת העברת מנועים, תומכת בשלבים ידניים עבור תהליכים שעשויים להיות אוטומטיים מאוחר יותר, ומתאימים לפעולות הממקדות תפקידים שאינם של פיתוח (לדוגמה, חשבונות ניתנים לתשלום). בנוסף, ניתן לטפל במשימות פשוטות יותר באמצעות בקשות HTTP, וימנע את הצורך במנועים מורכבים.

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

הבסיס כולל גם יכולות לניהול פרופילי משתמש ומטה-נתונים של צוות, המ קשר בין פרטי אדם לצוות וחשבונות המתארחים על-ידי ספק זהויות, כגון Microsoft Entra ID. מטה-נתונים אלה משמשים לקיבוץ ולשליטה בגישה בתוך ה- API של פלטפורמת המפתחים. למרות שניתן יהיה לאחסן מידע זה ב- Developer Platform Graph, הפרדתו מבטיחה בהירות.

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

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

מושגי ספק של פלטפורמת מפתח למפתחים

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

ישויות

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

מאפיינים משותפים

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

ישויות נפוצות וישויות ספציפיות לספק

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

תבניות

תבניות מיועדות לקדם פעולות כגון הקצאת תשתית, יצירת מאגר או תהליכים אחרים שפועלים לאורך זמן. תבניות אלה זמינות באמצעות ספקי פלטפורמות מפתחים וכוללות מאפיינים נפוצים כגון שיוכי ישויות וקלט נדרש (לדוגמה, שמות משאבים). תבניות יכולות לייצג תבניות שונות, כולל תבניות תשתית כקוד (IaC), תבניות יישומים או קבצי Script עם פרמטרים. לעתים קרובות הם ספציפיים לספק, עם ייצוגים שונים בהתאם לטכנולוגיה בשימוש. דוגמאות לייצוגים אלה כוללות תבניות Terraform או Bicep, תרשימי Helm, זרימות עבודה עם פרמטרים של פעולות GitHub, קווי צינור של Azure, קבצי Script פשוטים או תבניות מותאמות אישית המותאמות ל- Ecosystems ספציפיות של ספקים.

למרות שאין צורך לאחסן תבניות באופן מרכזי, הן חייבות להיות נגישות דרך ספק כדי להבטיח גישה עקבית ברחבי הפלטפורמה. הם יכולים להתקיים מאגרים, רישום או קטלוגים שונים, בהתאם למקרה השימוש. לדוגמה, מאגרי תבניות של GitHub עשויים לשמש עבור תבניות יישומים, בעוד שתבניות IaC עשויות להימצא במאגר קטלוג מוגבל שמפתחים ניגשים אליו באופן עקיף באמצעות כלים כגון סביבת הפריסה של Azure. ייתכן שתבניות אחרות של IaC יאוחסנו ברישום פריטים של Open Container Initiative (OCI), כגון תרשימי Helm. במקרים מסוימים, תבנית עשויה פשוט להפנות אל נקודת קצה של HTTP המבוטעת בפרמטרים.

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

פעולות GitHub כספקי פלטפורמה

כדי להמחיש את אופן הפעולה של ספק, נשקול פעולות GitHub ו- Azure Pipelines. כל אחד מהם יכול לשמש כספק פלטפורמת מפתחים על-ידי הפעלת זרימות עבודה או צינור רץ דרך ממשקי ה- API המתאימים שלהם, כגון REST API של פעולות GitHub או ממשק API של צינור של Azure DevOps. זרימות עבודה או קווי צינור אלה אינם נדרשים לאחסון מאגרי קוד מקור של אפליקציות, דבר המאפשר למהנדסי פלטפורמה לתחזק אותם מאגרים מרכזיים ופרטיים. במודל זה, למפתחים אין גישה ישירה לזרימות העבודה, אך הם יכולים להשתמש ספק פלטפורמת מפתחים כדי לקיים איתם אינטראקציה. הספק יכול לנהל את הסודות הנחוצים, כגון אישורים או מפתחות API, על-ידי שילוב עם שירותים כגון Azure Key Vault. כאשר זרימות עבודה מתבצעות, הספק עוקב אחר המצב שלו, תוך שימוש ב- webhooks עבור פעולות GitHub ורכיבי Hook של שירות עבור Azure Pipelines כדי לנטר את ההתקדמות. לאחר השלמת זרימת העבודה, כל הממצאים המופקים, כגון תוצאות בנייה או פריסה, נלכדים ופורסמו. ניתן להוסיף ממצאים אלה, יחד עם פרמטרי קלט והפניות לזרימות העבודה, לתרשים פלטפורמת המפתחים. גישה זו גם מאפשרת גמישות בשימוש ב- CLIs שרירותי, תוך תמיכה במגוון רחב של משימות אוטומציה לאורך זמן. בנוסף, השימוש בפעולות GitHub או ב- Azure Pipelines בהקשר זה אינו תלוי בתפקיד המסורתי שלהם ב- CI/CD, ומספק ישימות רחבה יותר לניהול תהליכים ותבניות שונים.

קיימים סוגים אחרים של ספקי פלטפורמת מפתחים, ה יכולים לטפל במשימות שונות באמצעות תבניות. עבור פעולות בקרת מקור, ספקים יכולים לעזור לנהל משימות Git כגון יצירת מאגרים, שליחת דוחות משתמש או פעולות אחרות של Git מבלי להשתמש במנועי זרימת עבודה כלליים. ניתן לייעל הקצאת תשתית באמצעות ספקים ייעודיים כגון Azure Deployment Environments או Terraform Cloud, תוך התמקדות בתשתית כקוד (IaC) עם אבטחה ויעילות. ספקי פיגומים של אפליקציות, כגון ממשקי גישה למפתחים של Azure, תומכים ביצירת עצי מקור של אפליקציות ודוחפים אותם למאגרי מקורות, ומוסיף גמישות עבור מערכות Ecosystems שונות. ניתן לנהל תהליכים ידניים, כגון יצירת בקשות משיכה (PRs) או אוטומציה של זרימות עבודה עבור משתמשים שאינם מפתחים, באמצעות ספקים מבוססי תבניות, המאפשרים אוטומציה הדרגתית. דוגמאות אלה מדגישות כיצד יכולת ההרחבה וההסתגלות של ספקי פלטפורמות מפתחים יכולות לשפר את יכולות האוטומציה לאורך זמן.