‏Power Platform: ‏פתרונות מנוהלים לעומת לא מנוהלים – המדריך המלא

By Mirko Peters · 2026-10-21

‏למדו את ההבדלים הקריטיים בין פתרונות Power Platform מנוהלים ללא מנוהלים, כללי הפריסה ושיטות העבודה המומלצות ל-ALM עבור האפליקציות שלכם.

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

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

‏עיקרי הדברים

• ‏פתרונות לא מנוהלים הם עותק העבודה שלכם בסביבות הפיתוח, שבו אתם בונים, עורכים ומתנסים באופן פעיל.
• ‏פתרונות מנוהלים הם עותקים קפואים וניתנים לפריסה, המיועדים אך ורק לסביבות בדיקות וייצור כדי לשמור על היציבות.
• ‏מחיקת פתרון לא מנוהל מסירה רק את המיכל ומשאירה את הרכיבים על כנם, ואילו הסרת התקנה של פתרון מנוהל מוחקת את הטבלאות המותאמות אישית והנתונים הקשורים אליו.
• ‏לא ניתן לייבא פתרון מנוהל חזרה לאותה סביבת פיתוח שבה נוצר ההורה שלו הלא מנוהל.
• ‏התייחסות לפתרונות לא מנוהלים כקוד מקור ולפתרונות מנוהלים כארטיפקטים של build מיישרת את ה-ALM של Power Platform עם שיטות העבודה המקובלות בפיתוח תוכנה.

‏ההבדלים המרכזיים בין פתרונות מנוהלים ללא מנוהלים

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

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

‏פתרונות לא מנוהלים: סביבת העבודה שלכם לפיתוח

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

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

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

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

פתרונות מנוהלים: חבילת הפריסה לסביבת הייצור

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

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

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

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

ארכיטקטורת סביבות וכללי בדיקה

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

הגדרה תקינה ומסודרת של ALM (ניהול מחזור חיי יישום) כוללת לפחות שלוש סביבות נפרדות:

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

שליטה באסטרטגיית הפריסה של Power Platform

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

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