ניהול ALM תקין של טופס יישום מונחה-דגמים
מאמר זה מספק לך מידע על התרחישים השונים הנוגעים ליישום ולתרגול של ניהול מחזור חיים של יישום (ALM) תקין עבור התאמה אישית של טפסים בפתרונות היישום מונחה הדגמים שלך.
הסעיפים הבאים מתארים כיצד פועל מיזוג טפסים וכיצד לשמור על התאמות אישיות. תרחישי הפיתוח הבסיסיים עם המלצות לשמירה על ALM מוצלח עבור טופס של יישום מונחה-דגמים מכוסים בפירוט בכל סעיף לאחר מכן. כל תרחיש כולל שלבים לביצוע שיכולים לעזור לך ליישם תהליך ALM תקין בעת עדכון הפתרון או היישום מונחה הדגמים שלך.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
- צור טופס חדש בשם FormA בסביבת הפיתוח שלך ובצע התאמות אישיות בטופס.
- צור פתרון חדש (בשם Solution A בתרשים שלהלן) בסביבת הפיתוח, שיהיה פתרון לא מנוהל והוסף את הטופס החדש שלך. יצא את הפתרון כפתרון מנוהל. שלב זה מייצא FormXml מלא עבור הטופס.
- בסביבת הבדיקות שלך, ייבא את הפתרון המנוהל משלב 2, שיוצר FormA בסביבת הבדיקות. בתרשים שלהלן, FormA נוצר בסביבת הבדיקות וממשק המשתמש עבור הטופס מציג Field1 ו- Field2 אשר Solution A הוסיף לטופס.
- כאשר תמשיך להתאים אישית את הטופס שיצרת בשלב 1 באמצעות סביבת פיתוח (מקור) חדשה, יהיה עליך לייבא את פתרון A המנוהל שנוצר בשלב 2, ולוודא שמופע הפיתוח שאתה משתמש בו הוא בעל FormA במצב מנוהל. כפי שמוצג בתרשים להלן, Solution A מנוהל מיובא בסביבת הפיתוח והטופס מותאם אישית ויוצר התאמות אישיות פעילות. לאחר מכן ניתן להוסיף את FormA לפתרון לא מנוהל חדש (Solution B בתרשים) ולייצא כפתרון מנוהל מסביבת הפיתוח. שלב זה מייצא FormXml שונה עבור הטופס.
- בסביבת הבדיקות שלך, יבא את הפתרון המנוהל (Solution B) משלב 4. כפי שמוצג בתרשים להלן, Solution B מוסיף Field3 חדש אל FormA ומסיר את Field2, שנוסף על-ידי Solution A. ממשק המשתמש בסביבת הבדיקות מציג כעת את Field3 ו- Field1 בטופס, אבל לא Field2 לאחר המיזוג.
כפי שניתן לראות בתרשים שלהלן, זו אינה שיטת עבודה תקינה של ALM ליצור פתרונות מנוהלים מרובים מסביבת הפיתוח שבה פתרון הבסיס (Solution A) הוא במצב לא מנוהל. הסיבה לכך היא שכשאתה יוצר פתרון לא מנוהל אחר (Solution B) עבור הטופס הלא מנוהל, FormXml מיוצא כ- FormXml מלא, במקום FormXml שונה, כפי שמוצג בתרחיש החוקי לעיל. כתוצאה מכך, שינויים כגון הסרת עמודה לא ייכנסו לתוקפם.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
צור טופס חדש בשם FormA בסביבת הפיתוח שלך ובצע התאמות אישיות בטופס.
צור פתרון (בשם Solution A בתרשים שלהלן) שיהיה פתרון לא מנוהל והוסף את הטופס החדש שלך. יצא את הפתרון כפתרון מנוהל. שלב זה מייצא FormXml מלא עבור הטופס.
בסביבת הבדיקות שלך, יבא את הפתרון המנוהל משלב 2, וכך צור את הטופס בסביבת הבדיקות. בתרשים שלהלן FormA נוצר בסביבת הבדיקות וממשק המשתמש עבור הטופס מציג Field1 ו- Field2 אשר Solution A הוסיף לטופס.
כשתמשיך להתאים אישית את הטופס שיצרת בשלב 1 באמצעות תיקונים, השתמש באותה סביבה שבה Solution A הוא במצב לא מנוהל וצור תיקון עבור הפתרון והתאם אישית את הטופס. בשלב הבא, יצא את התיקון כפתרון מנוהל. שלב זה מייצא formXml מלא עבור הטופס.
בסביבת הבדיקות שלך, יבא את פתרון התיקון המנוהל משלב 4. כפי שמוצג בתרשים שלהלן, התיקון Solution A מוסיף Field3 חדש ל- FormA ומסיר את Field2 שנוסף על-ידי Solution A.
הערה
תיקונים המכילים formXml מלא תמיד מושווים לשכבת הבסיס שממנה נוצר התיקון ומתעלמות מכל תיקון ביניים בין הבסיס לתיקון הנוכחי. כתוצאה מכך, Field2 יוסר, מכיוון שהוא קיים בשכבת הבסיס פתרון A וההסרה תזוהה. מצד שני, Field3 מתווסף על-ידי פתרון התיקון, ולא ניתן להסירו על-ידי התיקונים הבאים. כך, שדות שנוספו באמצעות פתרונות תיקון הם תוספות באופיים.
כשתמשיך להתאים אישית את הטופס שיצרת בשלב 1 באמצעות שדרוגים, השתמש באותה סביבה שבה Solution A הוא במצב לא מנוהל ושכפל את Solution A כדי ליצור את פתרון השדרוג ולהתאים אישית את הטופס. לאחר מכן, יצא את שדרוג Solution A כפתרון מנוהל. שלב זה מייצא FormXml מלא עבור הטופס.
בסביבת הבדיקות שלך, יבא את שדרוג Solution A המנוהל משלב 6. כפי שמוצג בתרשים להלן, שדרוג Solution A מוסיף Field4 חדש ל- FormA ומסיר את Field2, שנוסף על-ידי Solution A. ממשק המשתמש עבור הטופס בסביבת הבדיקות מציג כעת את Field1, Field3, ו- Field4 בטופס, אבל Field2 יוסר לאחר שהטופס ימוזג מהיבוא.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
- ערוך טופס מנוהל קיים בשם FormB בדוגמה זו, בסביבת הפיתוח שלך ובצע התאמות אישיות בטופס. שים לב שפתרון A הוא הפתרון המנוהל שמותקן כבר עבור הטופס בסביבת הפיתוח.
- צור פתרון חדש (Solution B בתרשים להלן), שהוא פתרון לא מנוהל, והוסף FormB. יצא את הפתרון כפתרון מנוהל. שלב זה מייצא FormXml שונה עבור הטופס.
- בסביבת הבדיקות שלך, יבא את הפתרון המנוהל משלב 2, וכך צור שכבת פתרון שנייה עבור הטופס. בתרשים להלן, FormB מקבל את השינויים הממוזגים מ- Solution A ו- Solution B בסביבת הבדיקות וממשק המשתמש עבור הטופס מציג את Field1 ו- Field3 בטופס, אבל לא את Field2, שהוסר על-ידי Solution B.
- כשאתה ממשיך להתאים אישית את הטופס שהתאמת אישית בשלב 1 באמצעות הפתרונות המנוהלים החדשים, הקפד להשתמש בסביבת פיתוח חדשה הכוללת את FormB במצב מנוהל. כפי שמוצג בתרשים להלן, הפתרונות המנוהלים Solution A ו- Solution B מיובאים בסביבת הפיתוח. FormB מותאם אישית ליצירת התאמות אישיות פעילות, שאותן ניתן להוסיף לפתרון חדש (פתרון C בתרשים) ולייצא כ-פתרון מנוהל.
- בסביבת הבדיקות שלך, יבא את Solution C המנוהל משלב 4. כפי שמוצג בתרשים להלן, Solution C מוסיף Field4 חדש אל FormB ומסיר את Field3, שנוסף על-ידי Solution B. ממשק המשתמש עבור הטופס בסביבת הבדיקות מציג כעת את Field1 ואת Field4 בטופס, אבל לא את Field2 ו- Field3.
כפי שמוצג בתרשים שלהלן, זו אינה שיטת עבודה תקינה של ALM ליצור פתרונות מנוהלים מרובים מסביבת הפיתוח המכילה פתרון לא מנוהל אחר שיצרת עבור אותו טופס. שים לב ש- Solution B נמצא במצב לא מנוהל. כאשר אתה יוצר פתרון לא מנוהל אחר (Solution C) עבור FormB, ה- FormXml מיוצא כ- FormXml שונה כפי שמוצג בשלב 4 בתרשים לעיל. אבל FormB מכיל גם את השינויים מ- Solution B, שיוחלפו על-ידי השינויים החדשים שלך.
לדוגמה, כפי שנראה בתרשים להלן, Field3 מתווסף אל FormB ב- Solution B. אבל עכשיו כשאתה יוצר Solution C חדש בסביבה זו, עם Solution B במצב לא מנוהל, ומסיר את Field3, Field3 גם יוסר בסביבת הפיתוח. שדה3 לא יעקוב ב-diff FormXml בעת ייצוא הפתרון, שכן השינוי של הוספה והסרה של עמודה זו נעשה באותו שכבה פעיל. המשמעות היא שכאשר Solution C מנוהל מיובא בסביבת הבדיקות, הטופס עדיין יעבד את Field3 משום שה- FormXml השונה אף פעם לא מתעד אותו כשדה שהוסר (כפי שהוסר בשלב 5 בתרחיש ה- ALM של הטופס התקין לעיל). ביצוע התאמות אישיות בצורה זו יוביל לכך שסביבת הפיתוח לא תהיה עקבית עם סביבת הבדיקות.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
התאם אישית טופס מנוהל קיים בשם FormB בדוגמה זו, בסביבת הפיתוח שלך ובצע התאמות אישיות בטופס. שים לב ש- Solution A הוא הפתרון המנוהל שמותקן כבר עבור הטופס בסביבת הפיתוח.
צור פתרון (Solution B בתרשים להלן), שיהיה פתרון לא מנוהל, והוסף FormB. יצא את הפתרון כפתרון מנוהל. שלב זה מייצא FormXml שונה עבור הטופס.
בסביבת הבדיקות שלך, יבא Solution B מנוהל משלב 2, וכך צור שכבת פתרון שנייה עבור הטופס. בתרשים להלן, FormB מקבל את השינויים הממוזגים מ- Solution A ו- Solution B בסביבת הבדיקות. בנוסף, ממשק המשתמש עבור FormB מציג את Field1 ו- Field3 בטופס, אבל לא את Field2, שהוסר על-ידי Solution B.
כאשר תבצע התאמה אישית נוספת של הטופס שהתאמת אישית בשלב 1 באמצעות פתרון תיקון, תוכל להשתמש באותה סביבת פיתוח כשל שלב 1 שבה Solution B קיים במצב לא מנוהל. כפי שמוצג בתרשים להלן, Solution A הוא במצב מנוהל ו- Solution B הוא במצב לא מנוהל. מתבצעת התאמה אישית נוספת של הטופס ואתה יוצר תיקון עבור Solution B המוסיף את הטופס שלך לפתרון זה ומייצא אותו כפתרון תיקון מנוהל. שלב זה מייצא FormXml שונה.
בסביבת הבדיקות שלך, יבא את Solution B של התיקון המנוהל משלב 4. כפי שמוצג בתרשים להלן, תיקון Solution B מוסיף Field4 חדש אל FormB ומסיר את Field3, שנוסף על-ידי Solution B.
הערה
התיקונים הם תוספות מטבעם ולא יכולים להסיר רכיבים, כגון עמודות, מהטופס. ולכן Field3 לא יוסר מהטופס. ממשק המשתמש עבור הטופס בסביבת הבדיקות מציג כעת Field1, Field3, ו- Field4 בטופס, אבל לא את Field2.
כשתמשיך להתאים אישית את הטופס שיצרת בשלב 1 באמצעות שדרוגים, השתמש באותה סביבה שבה Solution B הוא במצב לא מנוהל ושכפל את Solution B כדי ליצור את פתרון השדרוג ולהתאים אישית את FormB. יצא את השדרוג כפתרון מנוהל. שלב זה מייצא FormXml שונה עבור הטופס.
בסביבת הבדיקות שלך, יבא את פתרון השדרוג Solution B משלב 6. כפי שמוצג בתרשים להלן, שדרוג Solution B מוסיף Field5 חדש אל FormB ומסיר את Field3, שנוסף על-ידי Solution B. ממשק המשתמש עבור הטופס בסביבת הבדיקות מציג כעת את Field1, Field4, ו- Field5 בטופס, אבל Field2 ו- Field3 הוסרו.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
- בסביבת פיתוח 1, צור FormA חדש ובצע התאמות אישיות בטופס.
- צור פתרון (בשם Solution A בתרשים שלהלן) שיהיה פתרון לא מנוהל, והוסף את הטופס החדש שלך. יצא את הפתרון כפתרון לא מנוהל. שלב זה מייצא FormXml מלא עבור הטופס.
- ב- Development Environment 2, יבא את הפתרון הלא מנוהל משלב 2, שיוצר את הטופס ב- Development Environment 2. בתרשים שלהלן, FormA נוצר וממשק המשתמש עבור הטופס מציג Field1 ו- Field2 אשר Solution A הוסיף לטופס.
- באפשרותך להמשיך ולהתאים אישית את הטופס ב- Development Environment 2 וליצור התאמות אישיות פעילות בסביבה, כגון הוספת עמודה חדשה בשם Field3. FormA מציג כעת את שדה1, שדה2 ו שדה3.
- ב- Development Environment 1 שלך, עליך להמשיך ולהתאים אישית את הטופס גם על-ידי הוספת Field4. ממשק המשתמש עבור הטופס ב- Development Environment 1 מציג כעת Field1, Field2 ו- Field4.
- יצא Solution A לא מנוהל עם השינויים שבוצעו בשלב 5. שלב זה מייצא FormXml מלא עבור הטופס.
- ב- Development Environment 2, יבא שדרוג Solution A לא מנוהל משלב 6. משום שהפתרון שאתה מייבא מכיל את ה- FormXml המלא עבור FormA, הוא מחליף את ההתאמה האישית הפעילה שבוצעה ב- Development Environment 1. ולכן הטופס מציג כעת רק Field1, Field2, ו- Field4, אבל לא Field3, שהייתה ההתאמה האישית הפעילה הנוספת שבוצעה ב- Development Environment 1. אופן פעולה זה מתרחש עם כל יבוא של פתרון לא מנוהל הכולל את ה- FormXml המלא עבור הטופס.
בצע את השלבים הבאים כדי ליישם ALM תקין של טופס עבור תרחיש זה.
- ב- Development Environment 1, התאם אישית טופס קיים בשם FormB בדוגמה זו. לאחר מכן בצע התאמות אישיות בטופס.
- צור פתרון (Solution B בתרשים להלן), שיהיה פתרון לא מנוהל, והוסף FormB. יצא את הפתרון כפתרון לא מנוהל. שלב זה מייצא FormXml שונה עבור הטופס.
- ב- Development Environment 2, יבא את הפתרון הלא מנוהל משלב 2, ובכך צור שכבת פתרון שנייה עבור הטופס. ממשק המשתמש של FormB מציג את Field1, Field2, ו- Field3 לאחר מיזוג הטופס.
- באפשרותך להמשיך ולהתאים אישית את הטופס ב- Development Environment 2 וליצור התאמות אישיות פעילות בסביבה, כגון הוספת עמודה חדשה בשם Field4. FormB מציג כעת את שדה1, שדה2, שדה3 , ו שדה4.
- ב- Development Environment 1, עליך להמשיך ולהתאים אישית את הטופס באמצעות הוספת עמודה חדשה בשם Field5. ממשק המשתמש עבור הטופס ב- Development Environment 1 מציג כעת Field3 ו- Field5.
- יצא Solution B לא מנוהל עם השינויים שבוצעו בשלב 5. שלב זה מייצא FormXml שונה עבור הטופס.
- ב- Development Environment 2, יבא שדרוג Solution B לא מנוהל משלב 6. משום שהפתרון שאתה מייבא מכיל את ה- FormXml השונה עבור FormB, הוא יתמזג עם ההתאמה האישית הפעילה שבוצעה ב- Development Environment 1. ולכן הטופס מציג כעת Field1, Field2, Field3, Field4, ו- Field5. אופן פעולה זה מתרחש עבור כל יבוא של פתרון לא מנוהל הכולל את ה- FormXml השונה עבור הטופס.
- אם מיזוג הטופס בשלב 7 אינו מה שאתה רוצה למרות שאתה מייבא FormXml שונה עם הפתרון הלא מנוהל ואתה רוצה להיות מסוגל להחליף את ההתאמות האישיות הפעילות שבוצעו ב- Development Environment 2, הסר את השכבה הפעילה עבור FormB. מידע נוסף: הסרת שכבה לא מנוהלת.
- יצא Solution B לא מנוהל עם השינויים שבוצעו בשלב 5. שלב זה מייצא FormXml שונה עבור הטופס.
- ב- Development Environment 2, יבא שדרוג Solution B לא מנוהל משלב 9. משום שאין שכבה פעילה עבור הטופס ב- Development Environment 2, (ראה שלב 8), כל השינויים מ- Solution B לא מנוהל מיובאים למרות שאתה מייבא FormXml שונה עבור FormB. ולכן הטופס מציג כעת רק Field1, Field2, Field3, ו- Field5. אופן פעולה זה מתרחש עבור כל יבוא של פתרון לא מנוהל הכולל את ה- FormXml השונה עבור הטופס. זו אותה התוצאה כשל שלב 7 בתרחיש שמירה על פתרונול לא מנוהלים והתאמות אישיות עבור טופס קיים בסביבות פיתוח מרובות.
כל חבילת פתרונות מיוצאת כוללת קובץ customizations.xml. בכל פעם שטופס נכלל בפתרון, הגדרת הטופס הקשורה קיימת במקטעי FormXml בקובץ customizations.xml. FormXml יכול להיות מלא או דיפרנציאלי (שונה).
ה- FormXml שאתה מקבל בעת ייצוא פתרון עבור טופס במצב לא מנוהל נקרא FormXml מלא. מלא פירושו שהוא מכיל את הגדרת הטופס המלאה. כאשר אתה יוצר טופס חדש ומייצא אותו, הטופס יהיה תמיד FormXml מלא מכיוון שהטופס בסביבה שממנה אתה מייצא נמצא במצב לא מנוהל וגם במצב יצירה. אם אתה מייצא פתרונות נוספים מאותה סביבה, גם הם יכללו FormXml מלא. משום שהתכונה solutionaction
מציינת FormXml שונה, ה- FormXml המלא בקובץ customization.xml בפתרון שאתה מייצא לא יכלול תכונות solutionaction
.
ה- FormXml שאתה מקבל בעת ייצוא פתרון עבור טופס במצב מנוהל נקרא FormXml דיפרנציאלי או שונה. שונה פירושו ש- FormXml מכיל רק את השינויים שבוצעו בהתאמות האישיות הפעילות בסביבה זו ולא את כל הגדרת הטופס. כאשר אתה מתאים אישית טופס מנוהל קיים ומייצא אותו, הטופס יהיה תמיד FormXml שונה מכיוון שהוא יכיל רק את השינויים הפעילים שבוצעו בו. ה- FormXml השונה בקובץ customization.xml בפתרון שאתה מייצא יכלול תכונות solutionaction
המגדירות מהם השינויים, כגון נוסף, הוסר, השתנה.
FormXml שונה מבטיח שהפתרון שלך יבטא רק את השינויים שהיישום שלך זקוק להם ויושפע פחות משינויים משכבות אחרות. FormXml שונה גם הופך את הפתרון למגושם פחות ומאיץ את הייבוא שלו.