שילוב חלק של Microsoft Fabric עם GitHub ו-Azure DevOps

By Mirko Peters · 2026-08-12 · Updated 2026-08-29

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

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

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

כדי להעמיק עוד בנושא ולשמוע פירוט מומחים על אופן האינטראקציה בין המערכות, הקשיבו לפרק הפודקאסט הנלווה: GitHub vs Azure DevOps for Microsoft Fabric CI/CD.

GitHub מול Azure DevOps: 5 עובדות מפתיעות

1. מקורות שונים, תכונות מתכנסות: למרות ששתי הפלטפורמות מיועדות ל-CI/CD ולשיתוף פעולה, GitHub נוצרה כפלטפורמה לפיתוח קוד חברתי, ואילו Azure DevOps התפתחה מכלי ה-ALM הארגוניים של Microsoft (Team Foundation Server). לכן תהליכי העבודה והשילובים הארגוניים שלהן שונים באופן משמעותי.
2. ניידות צינורות: צינורות Azure DevOps יכולים להריץ בניות מבוססות YAML על פלטפורמות רבות, ואף לעשות שימוש חוזר במשימות מצינורות ה-classic שלהם, ואילו GitHub Actions מציעה מרקטפלייס ציבורי גדול יותר של פעולות שנוצרו על ידי הקהילה. משמעות הדבר היא שהניידות תלויה לעיתים קרובות בפעולות הזמינות במרקטפלייס לעומת ספריות המשימות המובנות של Azure.
3. פילוסופיית Boards מול Issues: Azure DevOps כוללת מערכת פריטי עבודה מלאה (Boards) עם תבניות תהליך הניתנות להתאמה אישית ודיווח המיועד לתכנון ארגוני, ואילו GitHub Issues פשוטה יותר וחברתית יותר. זה מפתיע צוותים שמצפים למעקב פרויקטים זהה בהשוואה של "github vs azure devops".
4. ציות ארגוני ואפשרויות on-prem: Azure DevOps Server מספקת אירוח מקומי בוגר ובקרות ציות שארגונים מפוקחים דורשים לעיתים קרובות, ואילו GitHub מציעה את GitHub Enterprise Server, אך היסטורית התמקדה יותר בתהליכי עבודה בענן תחילה. לכן מדובר בשתי בחירות שונות לצוותים עם דרישות ציות מחמירות.
5. הבדלים במחירון ובמודל המשתמשים: התמחור ומודל המשתפים של GitHub מתמקדים במאגרים ובארגונים, עם מסלולים חינמיים נדיבים לקוד פתוח, ואילו Azure DevOps משתמשת ברישוי לפי משתמש עבור תכונות מסוימות (Test Plans, Artifacts) ויכולה להיות צפויה יותר מבחינת עלויות בהסכמי רישוי ארגוניים גדולים. מדובר בגורם לא צפוי בהשוואה של "github vs azure devops".

הסבר על בעלות הפריסה

מהי בעלות הפריסה

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

קוד ונכסים

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

• מעקב אחר קוד מקור
• בדיקות
• פריסה
• ניהול תשתיות
• מעקב אחר בניות
• ניהול סודות
• ניהול שחרורים

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

הרשאות וממשל

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

למה הבעלות חשובה

הבעלות מעניקה לכם שליטה על סביבת ה-DevOps שלכם. אתם מגינים על צינור האספקה מפני סיכונים ושומרים על פיתוח מאובטח. אתם שומרים על ציות לרגולציות ותומכים בשליטה תפעולית.

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

טיפ: כשאתם הבעלים של צינור ה-DevOps שלכם, אתם יכולים להגיב במהירות לשינויים ולשמור על פיתוח התוכנה בתלם.

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

מודל הבעלות של GitHub

אחסון קוד וארטיפקטים

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

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

הרשאות וגישה

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

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

• הקצו תפקידים והרשאות ברמת המאגר, הארגון או ה-enterprise.
• השתמשו ב-code owners כדי לדרוש סקירות לשינויים חשובים בקוד.
• הגבילו את גישת המנהל והשתמשו בה רק כשנדרש.
• בדקו באופן קבוע את יומני הביקורת לאיתור פעולות לא מורשות.

ממשל ותאימות

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

ניתן להשתמש ב-artifact attestations כדי לוודא שקבצי הפריסה שלכם לא שונו. GitHub תומכת ב-OpenID Connect (OIDC) לפריסות מאובטחות בפלטפורמות ענן. ניתן לשלוט בפריסות על ידי הגדרת כללים לגבי מי רשאי לפרוס ומתי. GitHub מאפשרת גם לצפות בהיסטוריית הפריסות, מה שעוזר בביקורות ובבדיקות תאימות.

הערה: GitHub Actions משתלב עם Microsoft Fabric, כך שניתן לאוטומט פריסות ולנהל פתרונות אנליטיקה עם אותן בקרות ממשל.

שיקולי אבטחה

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

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

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

התחלה עם GitHub כמאגר - רשימת בדיקה (GitHub מול Azure DevOps)

רשימת בדיקה מעשית להתחלה בשימוש ב-GitHub כמאגר הקוד שלכם.

• צרו חשבון GitHub או התחברו לחשבון קיים
• החליטו בין חשבון אישי לבין ארגון לצורך בעלות צוותית
• צרו מאגר חדש (ציבורי או פרטי) ובחרו את רמת הנראות המתאימה
• הוסיפו שם מאגר ברור וקובץ README.md תיאורי
• הוסיפו קובץ LICENSE שמתאים לצרכי הפרויקט שלכם
• הוסיפו קובץ .gitignore המותאם לשפה או למסגרת העבודה שלכם
• אתחלו את המאגר עם ענף ברירת מחדל (main) וכללי הגנה לענף
• הגדירו CODEOWNERS והנחיות לתרומה לפרויקט (CONTRIBUTING.md)
• הגדירו תבניות לדיווח על בעיות ותבנית לבקשות משיכה (pull request)
• הגדירו תוויות, אבני דרך ולוחות פרויקט למעקב אחר בעיות
• הגדירו זרימות עבודה ב-GitHub Actions לצורך CI/CD או שלבו צינורות קיימים
• הוסיפו סודות למאגר עבור CI, פריסות ושירותי צד שלישי
• הגדירו כללי הגנה לענף: נדרשות סקירות, בדיקות סטטוס וחתימות דיגיטליות על commits במידת הצורך
• הפעילו את Dependabot לעדכוני תלויות והתראות אבטחה
• הפעילו תכונות אבטחה: סריקת קוד, זיהוי סודות והתראות על פגיעויות
• הגדירו webhooks או אינטגרציות עבור CI, ChatOps או שירותים חיצוניים
• הזמינו משתפי פעולה או חברי צוות והגדירו הרשאות למאגר
• העבירו מאגרים ובעיות קיימים (אם עוברים מ-Azure DevOps, תכננו את ההעברה ומפו פריטי עבודה)
• תעדו את מבנה המאגר, זרימת העבודה בפיתוח ותהליך השחרור בוויקי או בתיקיית docs
• הגדירו ניטור והתראות עבור שחרורים, פריסות וזרימות עבודה חשובות
• בחנו והשוו בין זרימות העבודה של GitHub לבין חלופות (GitHub מול Azure DevOps) כדי לייעל את בחירות ה-CI/CD וניהול הפרויקטים
• בצעו ביקורת קבועה על הגישה למאגרים, על הסודות ועל הגדרות האבטחה

מודל הבעלות ב-Azure DevOps

מאגרים וצינורות (Pipelines)

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

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

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

בקרת גישה

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

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

ממשל ומדיניות

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

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

טיפ: בצעו סקירה קבועה של הגדרות הממשל ב-Azure DevOps כדי לשמור על פריסות מאובטחות ותואמות.

אבטחה ותאימות

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

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

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

התחלה עם Azure DevOps כמאגר — רשימת בדיקה (GitHub מול Azure DevOps)

• צרו ארגון Azure DevOps או התחברו לארגון קיים
• צרו פרויקט חדש (בחרו נראות: פרטי/ציבורי) ובחרו בקרת גרסאות: Git
• צרו את מאגר הקוד הראשון שלכם או ייבאו מאגר קיים (מ-GitHub או מקומי)
• הוסיפו קובץ README.md מתאר וקובץ רישיון
• הוסיפו קובץ .gitignore המותאם לשפה או למסגרת העבודה של הפרויקט
• הגדירו אסטרטגיית ענפים (branches) וכללי שמות (main, develop, feature/*, hotfix/*)
• הגנו על ענף main: הפעילו מדיניות ענפים, דרישה לסוקרים ובדיקות סטטוס
• צרו תבניות לבקשות משיכה (PR) והנחיות למתכנתים תורמים
• הגדירו הרשאות וקבוצות למאגר (Readers, Contributors, Project Administrators)
• הגדירו חיבורי שירות לפריסות (Azure, AWS, רג'יסטרי של Docker, ספקי git חיצוניים)
• צרו צינורות CI (Azure Pipelines YAML או הגדרה קלאסית) ואמתו בניות בבקשות משיכה
• צרו צינורות CD או צינורות שחרור לסביבות (dev/stage/prod) והוסיפו שערי אישור
• שלבו עם Boards: צרו פריטי עבודה וקשרו commits ובקשות משיכה לפריטי העבודה
• הגדירו webhooks או service hooks לאינטגרציות חיצוניות (Slack, Teams, Jenkins)
• הגדירו מדיניות שמירה לענפי המאגר ולבניות
• הפעילו ביקורת (auditing) והגדירו בקרות תאימות ואבטחה נדרשות
• הגדירו סריקת קוד, ניתוח אבטחה ובדיקות תלויות (GitHub עשוי להציע כלים נוספים — השוו לפי הצרכים שלכם)
• הגדירו feed לחבילות (artifacts) אם אתם צריכים אירוח חבילות (NuGet, npm, Maven)
• צרו wiki או אתר תיעוד, ושמרו את התיעוד במאגר הקוד במקומות המתאימים
• תכננו שלבי מעבר אם עוברים מ-GitHub: מיפוי מאגרים, בעיות, בקשות משיכה, CI/CD וחשבונות שירות
• הזמינו חברי צוות ובדקו את הגישה מחשבונות שלהם
• הריצו בדיקת קצה לקצה ראשונית: שכפול, commit, push, פתיחת בקשת משיכה, הרצת צינור והפריסה לסביבת בדיקות
• נטרו את השימוש בצינורות ושפרו את המדיניות והאוטומציה באופן מתמשך

שילוב Microsoft Fabric

אינטגרציית Git

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

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

CI/CD עם Azure DevOps ו-GitHub

אפשר להגדיר צינורות CI/CD ב-Microsoft Fabric באמצעות Azure DevOps או GitHub Actions. הכלים האלה עוזרים לכם להפוך לאוטומטיים את שלבי הבנייה, הבדיקה והפריסה. כדאי לתת לצינורות הפריסה שמות ברורים ותיאוריים. כך קל לזהות את מטרתו של כל צינור. אפשר להשתמש בסביבות עבודה קיימות או ליצור חדשות עבור שלבי צינור שונים, כמו פיתוח, בדיקות וייצור.

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

ממשל נתונים

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

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

אבטחה וציות

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

Microsoft Fabric פועלת יחד עם Microsoft Defender for Cloud Apps. האינטגרציה הזו מעניקה לכם שקיפות ושליטה טובות יותר בפעילות שלכם. אפשר לנטר פעילויות ולהגדיר התראות על התנהגות מסוכנת. אפשר גם לעקוב אחר מקור הנתונים ומסלול העיבוד שלהם. התכונה הזו מאפשרת לראות כיצד הנתונים זורמים במערכת. תוכלו להשתמש במידע הזה כדי לוודא ציות ולהבין את זרימת הנתונים הרגישים.

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

GitHub לעומת Azure DevOps לעומת Fabric: השוואת בעלות

מיקום המאגר

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

כדאי לבחור בפלטפורמה שמתאימה לצרכים שלכם. אם אתם רוצים שיתוף פעולה פתוח, GitHub מתאימה היטב. אם אתם זקוקים לשליטה הדוקה, Azure DevOps מציעה לכם יותר אפשרויות. Microsoft Fabric מאפשרת להשתמש בשתיהן, כך שתוכלו להתאים את הפלטפורמה לתהליך העבודה שלכם.

ניהול ארטיפקטים

ניהול ארטיפקטים הוא הדרך שבה מטפלים בתוצרי בנייה, חבילות וקבצים שהפרויקטים שלכם יוצרים. בהשוואה בין GitHub ל-Azure DevOps רואים הבדלים משמעותיים. GitHub משתמשת ב-GitHub Packages לאחסון ארטיפקטים. אתם מקבלים תכונות בסיסיות כמו אחסון ושיתוף של חבילות. Azure DevOps מציעה את Azure Artifacts, שמעניקה בקרות מתקדמות. אפשר לנהל גרסאות, להגדיר feeds ולעקוב אחר השימוש. Microsoft Fabric מתמקדת בארטיפקטים של אנליטיקה, כמו דוחות Power BI ומודלים סמנטיים. היא מתחברת למאגר שלכם לניהול גרסאות ומשתמשת בצינורות פריסה להעברת ארטיפקטים בין סביבות.

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

ממשל וציות

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

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

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

Microsoft Fabric מביאה ממשל לתהליכי העבודה של האנליטיקה שלכם. אתם משתמשים ב-Microsoft Purview כדי לקטלג נתונים ולעקוב אחר מקורם. אתם מגדירים מדיניות ברמת OneLake, והיא חלה על כל סביבות העבודה. הגישה המאוחדת הזו מקלה על ניהול הציות ככל שהנתונים שלכם גדלים.

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

תנוחת אבטחה

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

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

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

Microsoft Fabric מתמקדת באבטחת נתונים. משתמשים ב-Microsoft Defender for Cloud Apps כדי לנטר פעילות ולהגדיר התראות על התנהגות מסוכנת. אפשר לסווג ולהגן על נתונים רגישים בצינורות שלכם.

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

תרחישי DevOps מהעולם האמיתי

קוד פתוח עם GitHub

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

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

ארגון עם Azure DevOps

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

ניתוח נתונים עם Fabric

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

טיפ: השתמשו בצינורות הפריסה של Microsoft Fabric ובהרשאות מרחב העבודה כדי לשמור על הנתונים מאובטחים ועל הצוות יעיל.

פריסות היברידיות

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

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

בחירת פלטפורמת DevOps המתאימה

שאלות מפתח בנושא בעלות

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

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

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

היתרונות של כל פלטפורמה

לכל פלטפורמת DevOps יש יתרונות ייחודיים. צריך להתאים את היתרונות האלה לצרכים של הפרויקט. אפשר להשתמש ב-GitHub Actions לאימוץ מהיר ולאינטגרציה קלה. Azure DevOps מספקת בקרות מתקדמות לזרימות עבודה מורכבות. Microsoft Fabric מביאה ניתוח ממשל מאוחד. אפשר לקשר את מרחב העבודה שלכם ל-GitHub או ל-Azure DevOps לצורך בקרת גרסאות ופריסה.

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

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

כדי להמשיך במסע הלמידה שלכם ולגלות תובנות נוספות בנושא, האזינו ישירות לפרק הקשור: GitHub vs Azure DevOps for Microsoft Fabric CI/CD.

שאלות נפוצות

מה המשמעות של בעלות על פריסה בפלטפורמות DevOps?

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

כיצד GitHub, Azure DevOps ו-Microsoft Fabric מטפלים בבקרת גישה?

מגדירים תפקידים והרשאות בכל פלטפורמה. GitHub משתמש בצוותים ובבעלי קוד. Azure DevOps משתמש בקבוצות אבטחה ובגישה מבוססת תפקידים. Microsoft Fabric נשען על Microsoft Entra ID להרשאות סביבת העבודה.

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

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

כיצד Microsoft Fabric משתלב עם GitHub ו-Azure DevOps?

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

אילו תכונות אבטחה מגנות על הפריסות שלכם?

משתמשים באימות דו-שלבי, בניהול סודות ובסריקות אבטחה אוטומטיות. Azure DevOps מוסיף שערי אישור ו-Defender for Cloud. Microsoft Fabric מציע Data Loss Prevention וכלים לניהול פרטיות.

כיצד מנהלים תאימות בפלטפורמות האלה?

מגדירים מדיניות לענפים, יומני ביקורת וכללי ממשל. Azure DevOps ו-Microsoft Fabric תומכים במסגרות תאימות כמו GDPR ו-ISO. ל-GitHub Enterprise יש כלי תאימות מתקדמים לארגונים.

למי שייך נכס אנליטיקה שנפרס ב-Microsoft Fabric?

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

מהם ההבדלים המרכזיים בין Azure DevOps ל-GitHub?

Azure DevOps (ado) היא חבילת כלי פיתוח הכוללת את Azure Boards, Pipelines, Repos, Test Plans וניהול ארטיפקטים, ומתמקדת בניהול פרויקטים ארגוני ובתהליכי CI/CD. לעומת זאת, GitHub היא פלטפורמה שמבוססת על git, ומתמקדת במאגרי git, בבקשות משיכה (pull requests) ובקהילת המפתחים. היא מציעה תכונות כמו GitHub Repos, GitHub Enterprise Cloud ו-GitHub Actions. Azure DevOps מועדף לרוב בשל מעקב משולב אחר פריטי עבודה ובשל המורשת של Visual Studio Team Services (TFS). GitHub מספק מערכת אקולוגית גדולה של קוד פתוח ותכונות שיתוף פעולה מודרניות.

איזה כלי כדאי להשתמש בו לניהול גרסאות: Azure Repos או GitHub Repos?

שניהם תומכים במאגרי git ובניהול גרסאות. Azure Repos משולב היטב עם Azure Boards ו-Azure Pipelines, ולכן הוא אטרקטיבי לצוותים שעובדים עם תהליכי Microsoft Azure DevOps. GitHub Repos (המאוחסן ב-GitHub) מצטיין במאגרים ציבוריים ופרטיים, בניהול פרויקטים של קוד פתוח, בתרומות מהקהילה ובתכונות כמו זרימות עבודה של בקשות משיכה. בחרו לפי השאלה אם אתם מעדיפים את Azure Boards המשולב או את פלטפורמת GitHub הרחבה והקהילה שלה.

האם אפשר להעביר מאגרים מ-Azure Repos ל-GitHub?

כן, אפשר להעביר מאגרים מ-Azure Repos ל-GitHub. צוותים רבים מייצאים מאגרי git מ-ado repos ומייבאים אותם ל-GitHub, או משתמשים בכלי מעבר. המעבר כולל לרוב שמירה על היסטוריית הקומיטים, ניהול משתמשים מנוהלים בארגון עבור GitHub Enterprise Cloud, ועדכון אינטגרציות CI/CD מ-Azure Pipelines ל-GitHub Actions, אם זה רצוי.

כיצד Azure Boards ו-GitHub Issues משתווים לניהול פרויקטים אג'ילי?

Azure Boards מספקת ניהול פרויקטים אג'ילי עשיר עם פריטי עבודה, backlogs, ספרינטים ואינטגרציה עמוקה עם צינורות ועם Test Plans, וזו הסיבה שהיא כלי ניהול פרויקטים חזק לארגונים גדולים. GitHub issues (ולוחות הפרויקטים) פשוטים יותר ומתאימים יותר לזרימות עבודה של קוד פתוח ושל קהילות מפתחים. עם זאת, GitHub התרחבה ותומכת כיום ביותר תכונות לתכנון פרויקטים. חלק מהצוותים משלבים את היתרונות של שני העולמות על ידי חיבור מאגרי GitHub ל-Azure Boards.

האם GitHub Copilot זמין למשתמשי Azure DevOps?

GitHub Copilot משתלב בעיקר עם כלים למפתחים כמו Visual Studio Code ו-Visual Studio, ולכן מפתחים שעובדים עם Azure DevOps יכולים להשתמש ב-Copilot בסביבות הפיתוח שלהם. השקת GitHub Copilot ותכונות ה-copilot workspace שבאו אחריה הופכות אותו לזמין למפתחים ללא קשר לפלטפורמת ה-CI/CD בצד השרת. עם זאת, חלק מבקרות הארגון והרישוי תלויים בשאלה אם אתם משתמשים ב-GitHub Enterprise Cloud או מעדיפים סביבות המנוהלות ב-Azure DevOps.

איזו פלטפורמה טובה יותר למשתמשים מנוהלים ארגונית ולאבטחה: GitHub או Azure DevOps?

שתי הפלטפורמות מציעות יכולות ארגוניות: Microsoft Azure DevOps מספקת בקרת גישה מדויקת, אינטגרציה עם Azure AD ותכונות ציות מתקדמות, ואילו GitHub Enterprise Cloud כוללת משתמשים מנוהלים ארגונית ואת GitHub Advanced Security for Azure, הכוללת סריקת קוד, סריקת סודות וניהול תלויות. הבחירה תלויה בצרכים הארגוניים: Azure DevOps עשויה להשתלב טוב יותר בכלי Microsoft הקיימים, בעוד GitHub מספקת יכולות חזקות יותר לקוד פתוח ולקהילה, לצד אפשרויות אבטחה מתקדמות.

איך משתוות צינורות CI/CD בין Azure Pipelines ל-GitHub Actions?

Azure Pipelines (חלק מ-Azure Boards and Pipelines) מציעה CI/CD רב-פלטפורמי ואמין, עם אינטגרציה חזקה ל-Azure DevOps ול-Visual Studio. GitHub Actions משולבת היטב בפלטפורמת GitHub ומספקת זרימות עבודה גמישות שמופעלות על ידי אירועים במאגר, לצד אוטומציה חלקה של pull requests. שתי הפלטפורמות תומכות בקונטיינרים, בפריסות בענן ובסוכנים מתארחים עצמית (self-hosted runners). בחרו את כלי ה-DevOps שמתאים לזרימת העבודה שלכם, או שלבו את היתרונות של שניהם על ידי חיבורם זה לזה.

האם אפשר להשתמש ב-Visual Studio וב-VS Code בשתי הפלטפורמות?

כן, גם Visual Studio וגם Visual Studio Code (VS Code) תומכים ב-GitHub וב-Azure DevOps. ל-Visual Studio יש אינטגרציות מובנות ל-Azure Repos ול-ADO, ואילו VS Code עובד היטב עם מאגרי GitHub, עם GitHub Copilot ועם מאגרי git כלליים. מפתחים יכולים להשתמש בכלים האלה על פני שתי הפלטפורמות כדי לערוך קוד, להריץ בדיקות ולעבוד עם pull requests או עם פריטי עבודה.

מה לגבי בדיקות: האם Azure Test Plans קיים ב-GitHub?

Azure Test Plans הוא פתרון בדיקות משולב ב-Azure DevOps, המספק כלים לבדיקות ידניות ולבדיקות חקרניות (exploratory). GitHub אינו מציע מוצר תוכניות בדיקה מובנה זהה, אך ניתן לשלב במאגרי GitHub מסגרות בדיקה, actions וכלי ניהול בדיקות של צד שלישי, כדי להשיג יכולות דומות של אוטומציית בדיקות ודיווח.

איך נבדלים התמחור והאירוח: אירוח ב-GitHub לעומת Microsoft Azure DevOps?

GitHub מציעה שירותים מתארחים (GitHub.com ו-GitHub Enterprise Cloud) עם תוכניות מדורגות לצוותים ולארגונים, והיא מדגישה מאגרים ציבוריים ופרטיים ונגישות לקהילה. גם Microsoft Azure DevOps Services מציעה אפשרויות ענן מתארחות עם תמחור מבוסס משתמשים, וכן גרסאות מקומיות (on-premises), שהיו ידועות קודם לכן בשם TFS/Visual Studio Team Services. בהחלטות על עלויות יש לשקול את דקות ההרצה של הצינורות, אחסון ארטיפקטים, משתמשים מנוהלים ארגונית, והאם נדרש אירוח מקומי (on-prem).

האם צוותים יכולים להשתמש גם ב-GitHub וגם ב-Azure DevOps יחד?

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

איזה כלי מעדיפים מפתחים בקהילת המפתחים: GitHub או Azure DevOps?

מפתחים בקוד פתוח ומפתחים עצמאאים רבים מעדיפים את GitHub משום שהוא מטפח קהילה, תומך במאגרים ציבוריים ופרטיים ומציע תהליכי סקירה משולבים, בעוד שמפתחים ארגוניים וצוותים שזקוקים לניהול פרויקטים מקיף נוטים להעדיף את Azure DevOps. ההעדפות תלויות גם בהשקעה הקיימת ב-Visual Studio וב-Microsoft Azure, וגם בשאלה אם תכונות כמו GitHub Copilot או GitHub Advanced Security for Azure נמצאות בראש סדר העדיפויות.

אילו שיקולים צריך צוות לשקול כשהוא מחליט בין GitHub ל-Azure DevOps?

שקלו את צורכי ניהול גרסאות שלכם, את האינטגרציה עם Visual Studio או VS Code, את הדרישה לניהול פרויקטים ב-Agile (Azure Boards), את צורכי האבטחה והתאימות, את הצורך ב-Azure Test Plans, את החשיפה לקהילה ולקוד פתוח, ואם אתם רוצים תכונות כמו GitHub Copilot או סריקת אבטחה מתקדמת. הערכו איזה כלי DevOps מתאים לזרימת העבודה שלכם, או אמצו מודל היברידי שבו משתמשים במאגרים מ-Azure Repos או במאגרי GitHub יחד עם Azure Boards ו-Pipelines.