מדריך

אכיפת איכות קוד (בנייה, בדיקה, כיסוי) לפני מיזוג בקשת משיכה.

→בענף היעד, הגדר מדיניות אימות בנייה המפעילה Pipeline ביצירת PR. ה-Pipeline חייב לפרסם תוצאות כיסוי קוד. הגדר מדיניות ענף לכיסוי מינימלי.

למה: זה אוכף איכות לפני מיזוג. טריגר CI סטנדרטי רץ לאחר המיזוג. שערי שחרור מיועדים לפריסות, לא ל-PRs.

בחירת אסטרטגיית Git branching הממזערת קונפליקטים במיזוג ותומכת בפריסה מהירה ורציפה ל-production.

→יישם פיתוח מבוסס trunk עם ענפי תכונה קצרי טווח הממוזגים ל-`main` בתדירות גבוהה (יומית או יותר).

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

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

→הגדר Branch Policies על ענף `main` ב-Azure Repos. אפשר מדיניות עבור מספר מינימלי של סוקרים, אימות בנייה, וקישור פריטי עבודה.

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

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

→יישם את מודל ה-GitFlow branching, המשתמש בענפים `main`, `develop`, `feature/*`, `release/*`, ו-`hotfix/*`.

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

סוד הועלה בטעות ונדחף (pushed). יש להסיר אותו לחלוטין מכל היסטוריית Git.

→ראשית, סובב את הסוד שנחשף. לאחר מכן, השתמש בכלי כמו `git-filter-repo` או BFG Repo-Cleaner כדי לשכתב היסטוריה, תוך הסרת הקובץ. בצע force-push לשינויים והודע לכל המפתחים לבצע re-clone.

למה: `git rm` או revert פשוט אינם מסירים את הסוד מההיסטוריה. שכתוב היסטוריה נדרש לטיהור קבוע.

מידול זרימת עבודה מורכבת עם שלבים מקבילים ותלות בין שלבים.

→השתמש ב-YAML multi-stage pipelines. השתמש במילת המפתח `dependsOn` עבור תלויות שלבים והגדר משימות מקבילות בתוך שלבים.

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

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

→השתמש ב-Azure App Service deployment slots. פרוס ל-staging (ירוק) slot, אמת, ולאחר מכן בצע החלפת slot עם production (כחול).

למה: החלפת slot היא פעולה אטומית, כמעט מיידית, המנתבת מחדש תעבורה. חזרה לאחור פשוטה כמו החלפה חזרה.

מקור↗

מזעור כפילות Pipeline עבור microservices רבים החולקים שלבי בנייה/פריסה נפוצים אך דורשים התאמות אישיות ספציפיות.

→צור תבניות YAML במאגר מרכזי. בכל Pipeline ספציפי לשירות, השתמש במילת המפתח `extends` והעבר פרמטרים להתאמה אישית.

למה: `extends` מקדם עקרונות DRY ואוכף סטנדרטים תוך מתן גמישות באמצעות פרמטרים. עוצמתי יותר מקבוצות משימות עבור מבני Pipeline שלמים.

הגבלת שלב Pipeline (לדוגמה, פריסת production) לרוץ רק על מיזוגים לענף ספציפי (לדוגמה, main).

→השתמש ב-`condition` על השלב או המשימה. לדוגמה, `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

למה: בניות אימות PR משתמשות בהפניית ענף מקור שונה (לדוגמה, `refs/pull/...`), ולכן תנאי זה מונע נכון פריסה במהלך מחזור חיי ה-PR.

פריסת יישומים מ-Azure DevOps לשרתים מקומיים מאחורי חומת אש ארגונית.

→התקן סוכנים עצמאיים (self-hosted agents) על השרתים המקומיים. רשום אותם למאגר סוכנים ב-Azure DevOps.

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

דרישת אישור רב-אישי לפריסות Production והגבלתן לחלונות תחזוקה ספציפיים.

→הגדר Azure DevOps Environment עבור Production. הגדר אישורים עם מאשרים נדרשים. הוסף בדיקת "שעות עבודה" כשער לאכיפת חלון הזמן.

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

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

→השתמש ב-Azure App Configuration לניהול תכונות. הצב כלי אינסטרומנטציה ביישום כדי לקרוא את ה-flags ולאפשר את יכולות הרענון הדינמי שלו.

למה: מפריד בין שחרור תכונות לפריסות. App Configuration מספק ממשק משתמש מרכזי ו-SDKs לעדכונים דינמיים, ובכך מונע הפעלות מחדש של יישומים.

ניהול מצב אשכול Kubernetes באופן דקלרטיבי, כאשר Git הוא מקור האמת היחיד והשינויים מיושמים אוטומטית.

→פרוס סוכן GitOps כמו Flux או ArgoCD לאשכול AKS. הגדר את הסוכן לנטר מאגר Git המכיל Kubernetes manifests ולסנכרן אוטומטית את מצב האשכול.

למה: מודל מבוסס משיכה זה מאפשר התאמה מתמדת וזיהוי סחף, שהם ליבת ה-GitOps. הוא איתן יותר מ-Pipelines מבוססי `kubectl` מבוססי דחיפה.

ניהול מצב Terraform לשיתוף פעולה בצוות, תוך הבטחת אבטחה ומניעת שינויים מקבילים.

→הגדר את ה-Terraform backend לשימוש בחשבון Azure Storage Account. זה מספק אחסון מצב מרוחק, עם נעילת מצב המטופלת באמצעות Azure Blob lease.

למה: מונע השחתת קבצי מצב מפעולות `apply` בו-זמניות ושומר נתוני מצב רגישים מחוץ לבקרת מקור.

מקור↗

ב-monorepo, הפעל Pipeline CI של יישום רק כאשר קבצים בספרייה הספציפית שלו (או בספרייה משותפת) משתנים.

→ב-YAML של ה-Pipeline, השתמש במסנן `trigger.paths.include` כדי לציין את הספריות הרלוונטיות, לדוגמה, `include: ['/apps/frontend/**', '/apps/shared/**']`.

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

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

→הרץ בדיקות יחידה ובדיקות אינטגרציה במשימות מקבילות בתוך אותו שלב.

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

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

→שלב כלי כמו GitVersion ב-CI Pipeline. הוא מנתח הודעות commit, ענפים ותגים כדי לחשב אוטומטית גרסת SemVer (Major.Minor.Patch).

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

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

→השתמש ב-YAML Pipeline מרובה שלבים עם שלבים עוקבים, אחד לכל אזור, תוך שימוש ב-`dependsOn` לאכיפת סדר. השתמש בשערי Environment בין שלבים לאימות.

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

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

→הגדר טריגר CI בענף `main`. אכוף PRs עם מדיניות אימות בנייה המריצה בדיקות מהירות ומקיפות. שלב התראות מהירות (לדוגמה, ל-Teams/Slack) עבור שברי בנייה.

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

העברת Artifacts גדולים (לדוגמה, מודלי ML, >5GB) בין שלבי Pipeline ביעילות.

→העלה את ה-Artifact הגדול ל-Azure Blob Storage בשלב היצרן. העבר את ה-URI של ה-blob לשלב הצרכן כמשתנה פלט.

למה: Azure Blob Storage חסכוני וביצועי יותר מ-Artifacts מובנים של Pipeline עבור קבצים בגודל מספר גיגה-בייט.

קיצור זמני בנייה על ידי מניעת הורדה מחדש של תלויות (לדוגמה, NuGet, npm) בכל הרצה.

→השתמש במשימת `Cache@2`. הגדר מפתח בהתבסס על קובץ נעילת החבילה (לדוגמה, `packages.lock.json`). המשימה תאחסן ותשחזר את תיקיית התלויות.

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

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

→השתמש ב-`strategy: matrix` במשימת ה-YAML Pipeline. הגדר משתנים עבור כל שילוב, אשר יצור משימה עבור כל כניסת matrix.

למה: אסטרטגיית matrix שומרת על הגדרת ה-Pipeline יבשה (DRY), יוצרת וריאציות מרובות של משימות מהגדרה אחת ומריצה אותן במקביל.

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

→השתמש בבקר מסירה מתקדמת כמו Flagger, המשולב עם service mesh (לדוגמה, Istio) וספק מדדים (לדוגמה, Prometheus).

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

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

→ב-YAML של היישום, הגדר את הספרייה המשותפת תחת `resources.repositories` והגדר בלוק `trigger` על משאב זה.

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

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

→השתמש ב-Pipeline מרובה שלבים עם שלבי apply ו-destroy נפרדים עבור IaC (Terraform/Bicep). הגדר את שלב ה-destroy עם `condition: always()`

למה: התנאי `always()` מבטיח ששלב הניקוי ירוץ ללא קשר להצלחה או כישלון של שלבים קודמים, ובכך מונע משאבים יתומים.

מניעת פריסת production מלהתקדם אלא אם קיימת בקשת שינוי מאושרת בכלי ITSM כמו ServiceNow.

→הגדר שער Environment המפעיל את שער "Query ServiceNow" כדי לבדוק את סטטוס בקשת השינוי.

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

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

→הגדר מאגר סוכנים של Azure DevOps באמצעות Azure Virtual Machine Scale Set (VMSS), המוגדר להתרחב אוטומטית בהתבסס על מספר המשימות הממתינות.

למה: סוכני VMSS משלבים את ההתאמה האישית של סוכנים עצמאיים עם הגמישות של סוכנים מבוססי ענן, ובכך מייעלים ביצועים ועלויות.

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

→השתמש בכלי הגירה (לדוגמה, Flyway, DbUp). יישם את תבנית ה-expand/contract עבור שינויים בסכמה כדי לשמור על תאימות לאחור.

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

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

→ב-YAML של ה-Pipeline, ברמת המשימה, הגדר `workspace: clean: all`.

למה: תצורת Pipeline מונעת זו פותרת את שורש הבעיה ללא צורך בהתערבות ידנית או שינויים מתמשכים בתשתית.

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

→הגדר משאב קונטיינר (לדוגמה, SQL Server, Postgres) כשירות ב-YAML של ה-Pipeline. משימת הבדיקה יכולה אז להתחבר לשירות ארעי זה.

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

שיפור אמינות וביצועי שחזור חבילות ממאגרים ציבוריים (לדוגמה, npmjs, nuget.org).

→ב-Azure Artifacts, צור feed והגדר upstream sources המצביעים על המאגרים הציבוריים. בקש מלקוחות לצרוך חבילות מ-feed של Azure Artifacts.

למה: ה-feed מטמון חבילות ממקורות upstream, מגן מפני השבתות של מאגרים ציבוריים ומאיץ שחזורים עבור חבילות בשימוש תכוף.

פריסת Helm chart למספר סביבות (dev, prod) עם ערכי תצורה שונים.

→השתמש בקבצי `values-<env>.yaml` נפרדים לכל סביבה. במשימת `HelmDeploy`, השתמש בקלט `valueFile` כדי לציין את הקובץ המתאים וב-`overrideValues` כדי להזריק ערכים דינמיים כמו image tags.

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

ניהול וצריכת סודות (לדוגמה, מחרוזות חיבור) ב-Pipelines בצורה מאובטחת, ללא קידוד קשיח.

→אחסן סודות ב-Azure Key Vault. ב-Azure DevOps, צור Variable Group המקושר ל-Key Vault. הפנה לסודות מקבוצת המשתנים ב-Pipeline.

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

יישום סריקת אבטחה ב-CI Pipeline כדי לזהות פגיעויות בקוד היישום (SAST) ובתלויות צד שלישי (SCA).

→שלב את הרחבת Microsoft Security DevOps, הכוללת מספר סורקים. שקול גם את GitHub Advanced Security for Azure DevOps לחבילה מקורית ומקיפה.

למה: גישת "shift-left" זו מזהה פגיעויות מוקדם במחזור חיי הפיתוח, מפחיתה עלויות וסיכונים.

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

→הסר תפקידי Contributor/Owner קבועים. השתמש ב-pipeline Service Connections לפריסות. למצבי חירום, השתמש ב-Azure AD Privileged Identity Management (PIM) לגישה מוגברת Just-In-Time (JIT).

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

אספקת סודות ל-microservices ב-AKS בצורה מאובטחת, עם רוטציה אוטומטית וגישה ספציפית לעומס עבודה.

→השתמש ב-Azure Key Vault המשולב עם Secrets Store CSI Driver עבור AKS. השתמש ב-workload identity עבור pods כדי לבצע אימות מול Key Vault.

למה: טוען סודות ישירות ל-pods מ-Key Vault, ובכך נמנע מ-Kubernetes Secrets. מאפשר זהות ברמת ה-pod ורוטציה חלקה של סודות.

מקור↗

אכיפה שרק תמונות קונטיינר סרוקות וחתימות יכולות להיפרס לאשכול Kubernetes ב-production.

→השתמש ב-Azure Container Registry (ACR) content trust לחתימת תמונות. השתמש ב-Microsoft Defender for Containers לסריקה. השתמש ב-Azure Policy for Kubernetes לאכיפת מדיניות על AKS.

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

חיבור Azure Pipelines למשאבי Azure ללא שימוש בסודות לקוח או אישורים.

→צור חיבור שירות Azure Resource Manager באמצעות "Workload Identity Federation".

למה: מבטל את הצורך לנהל ולסובב סודות, ומשפר את מצב האבטחה של מערכת ה-CI/CD.

פריסה למנוי Azure של לקוח מארגון Azure DevOps שלך ללא החלפת סודות.

→פרוס סוכן עצמאי בסביבת Azure של הלקוח. הקצה Managed Identity למכונה וירטואלית/VMSS של הסוכן והענק לו את תפקידי ה-RBAC הנדרשים.

למה: שומר את כל עקרונות האימות בתוך ה-tenant של הלקוח, תוך שמירה על מודל Zero Trust. אין סודות שעוברים בין tenants.

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

→השתמש בפרויקט יחיד עם Area Paths עבור כל צוות כדי לספק להם Backlogs מסוננים. השתמש ב-Delivery Plans כדי להמחיש התקדמות ותלויות בין צוותים.

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

קישור אוטומטי של commits/PRs לפריטי עבודה ומעבר מצב פריט העבודה (לדוגמה, ל-"Resolved") עם מיזוג PR.

→בהגדרות הפרויקט, אפשר "Automatically complete work items with pull requests". מפתחים חייבים להשתמש ב-#<ID> בהודעות commit או לקשר PRs.

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

מדידת מדדי תהליך מפתח כמו Cycle Time, Lead Time, ומדדי DORA לניתוח זרם ערך.

→השתמש בשירות Azure DevOps Analytics ובפיד ה-OData שלו. חבר את Power BI או השתמש בווידג'טים מובנים של לוח מחוונים כדי להמחיש מדדים אלה.

למה: שירות Analytics מספק את הנתונים הבסיסיים למדדי זרימה ו-SRE מרכזיים, ומאפשר שיפור תהליכים מבוסס נתונים.

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

→ב-Application Insights, השתמש בלשונית Performance עם ניתוח אחוזונים (P95, P99) ו-Transaction Search כדי להתעמק בדגימות בקשות איטיות ספציפיות.

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

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

→הצב כלי אינסטרומנטציה בכל השירותים באמצעות ה-Application Insights SDK. הוא מפיץ אוטומטית W3C Trace Context correlation ID על פני קריאות שירות.

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

ניטור פרואקטיבי של Service Level Objective (SLO) של יישום וקבלת התראה *לפני* שה-SLO מופר.

→הגדר SLIs באמצעות שאילתות KQL ב-Azure Monitor. צור כלל התראה שמופעל על בסיס קצב שריפת תקציב השגיאות (כמה מהר התקציב נצרך).

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

אימות שפריסה הייתה מוצלחת מבחינה פונקציונלית מנקודת מבטו של המשתמש, לא רק שמשימות ה-Pipeline הושלמו.

→כשלב לאחר פריסה או שער שחרור, הרץ בדיקות זמינות של Application Insights (ניטור סינתטי) המדמות זרימות משתמש מפתח.

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

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

→השתמש במשימת Azure Pipelines כדי ליצור "Release Annotations" ב-Application Insights, המציב סמן על גרפי מדדים.

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

בדיקה פרואקטיבית של עמידות יישומים ותשתית לכשלים באופן מבוקר.

→שלב את Azure Chaos Studio ל-release pipelines. צור ניסויים שמחדירים תקלות (לדוגמה, כיבוי VM, זמן אחזור ברשת) ומאמתים את התנהגות המערכת.

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