שיקולים

מאמר זה מתאר חלק מהשיקולים שעשויים להיות קשורים לניהול מחזור חיים של יישום Power Platform.

מתודולוגיה לא מנוהלת כשיש לך מספר יישומים בפתרונות מרובים

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

Solution layers for deploying an app

לאחר מכן, צור פתרונות המצייתים למבנה הבא:

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

יצירת פתרון הבסיס

  • מטרת פתרון הבסיס היא לעקוף יחסי תלות בין רכיבים במהלך המרה מפתרון לא מנוהל לפתרון מנוהל.
  • פתרון הבסיס יכול גם לכלול טבלאות ועמודות שאינן בשימוש כעת על-ידי צוות פיתוח כלשהו. הכלי כולל רשימת אי הכללה ראשית של טבלאות ועמודות שישמשו להתעלמות מטבלאות שבבעלות צוותים אחרים.
  • יש להוסיף טבלאות עם AddRequiredComponents = False ו- DoNotIncludeSubcomponents = True לפתרון. יש להגדיר מראש את שם הפתרון והמפרסם.
  • שקול בניית כלי ליצירת פתרון הבסיס. הכלי יכול לכלול רשימת אי הכללה ראשית של טבלאות ועמודות בבעלות צוותי הפיתוח הנוכחיים.
  • פתרון הבסיס יהיה הפתרון הראשון שהומר כמנוהל בכל הסביבות למעט סביבת פיתוח של פתרון בסיס. לא יתווספו פתרונות אחרים לסביבת הפיתוח של פתרון הבסיס.

בניית פתרון משותף

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

שימוש במודל המרה גלי

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

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

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

בדיקות

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

צור סביבות פיתוח חדשות לאחר המרת פתרון הבסיס והפתרון המשותף כמנוהלים בייצור.

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

מגבלות

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

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

שיקולים ספציפיים של פורטלים

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

התאמה אישית של טבלאות מערכת משולבות בצורה מעמיקה

בטבלאות מערכת מסוימות יש קשרי גומלין ויחסי תלות רבים עם טבלאות אחרות שמקשים עליהן לייבא לסביבות אחרות:

  • משתמש.
  • איש קשר. דומה למשתמש מערכת עבור Power Apps אך עלול לגרום לסיבוך בעת ייבוא יישומי פורטלים.