בקרת מקור עם קבצי פתרון

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

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

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

חשוב

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

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

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

תבניות קובץ של בקרת מקור

הכלי Solution Packager תומך בשתי תבניות קובץ עבור קבצי רכיבים שחולצו. בחירת התבנית הנכונה מראש תימנע מהצורך להעביר את מבנה המאגר במועד מאוחר יותר.

	תבנית XML (דור קודם)	תבנית בקרת מקור YAML
מניפסט פתרון	Other\Solution.xml + Other\Customizations.xml	solutions/<name>/solution.yml ותמיכה בקובצי YAML
קריאות	XML מילולי	Compact YAML – קל יותר לקרוא ולסקרו
איכות Diff ב- Git	הבדלים גדולים של XML	פערים מינימליים ממוקדים
מאגר מרובה פתרונות	לא נתמך	נתמך – פתרונות מרובים משתפים תיקיה אחת
אפליקציות Canvas (.msapp)	לא נתמך	נתמך
זרימות מודרניות	לא נתמך	נתמך
שילוב מקורי של Git	לא בשימוש	תמיד משמש — אינטגרציה עם Git כותבת תמיד YAML

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

מתי להשתמש בתבנית XML: רק בעת עבודה עם מאגרים קיימים שכבר משתמשים בתבנית XML, או בעת שימוש בכלי מדור קודם שאינו תומך ב- YAML.

הערה

כאשר אתה מבצע פתרונות באמצעות שילוב Git המקורי ב- Power Apps, הם מאוחסנים תמיד בתבנית בקרת המקור YAML. כדי לארוז או לפרק את האריזה של מקור זה באופן ידני באמצעות SolutionPackager pac solution packאו , על התיקיה לעקוב אחר מבנה התיקיות YAML. מידע נוסף: כלי SolutionPackager — תבניות קובץ של בקרת מקור

פיתוח צוות

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

1. מפתח א' ומפתח ב' עובדים על אותו פתרון.

2. במחשבים עצמאיים, שניהם מקבלים את המקורות העדכניים ביותר של הפתרון מתוך בקרת המקור, אורזים אותם ומייבאים קובץ ‎.zip של פתרון לא מנוהל לארגוני Microsoft Dataverse עצמאיים.

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

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

5. שני המפתחים מייצאים קובץ ‎.zip של פתרון לא מנוהל ומבצעים חילוץ.

   1. מפתח א' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'איש קשר' וקובץ אחד עבור התצוגה 'אנשי קשר פעילים'.

   2. מפתח ב' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'תיק לקוח' וקובץ אחד עבור 'תצוגת בדיקת מידע של אנשי קשר'.‬

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

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

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

1. מפתח א' ומפתח ב' עובדים על אותו פתרון.

2. במחשבים עצמאיים, שניהם מקבלים את המקורות העדכניים ביותר של הפתרון מתוך בקרת המקור, אורזים אותם ומייבאים קובץ ‎.zip של פתרון לא מנוהל לארגונים עצמאיים.

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

4. מפתח ב' מתאים אישית את הטופס הראשי עבור הטבלה 'תיק לקוח' ומשנה את '‏‫אנשי קשר פעילים‬'.

5. שני המפתחים מייצאים קובץ ‎.zip של פתרון לא מנוהל ומבצעים חילוץ.

   1. מפתח א' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'איש קשר' וקובץ אחד עבור התצוגה 'אנשי קשר פעילים'.

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

6. מפתח א' מוכן ראשון.

   1. לפני שמפתח א' שולח לבקרת המקור, עליו לקבל את המקורות העדכניים ביותר כדי לוודא שאף הכנסת קובץ קודמת אינה מתנגשת עם השינויים שלו.

   2. אין התנגשויות, כך שמפתח א' יכול לבצע את השליחה.

7. מפתח ב' מוכן להיות הבא אחרי מפתח א'.

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

   2. קיימת התנגשות מכיוון שהקובץ עבור 'אנשי קשר פעילים' השתנה מאז שהמפתח ב' אחזר לאחרונה את המקורות העדכניים ביותר.

   3. מפתח ב' חייב לפתור את ההתנגשות. ייתכן שהיכולות של מערכת בקרת המקור שבה נעשה שימוש עשויות לסייע בתהליך זה; אם לא, כל האפשרויות הבאות תקפות.

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

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

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

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

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

יצירת פתרון

ההליך זה מזהה את השלבים האופייניים שבהם נעשה שימוש בעת יצירת פתרון לראשונה.

1. בסביבה נקייה, יש ליצור פתרון בשרת Dataverse ולאחר מכן להוסיף או ליצור רכיבים בהתאם לצורך.

2. כאשר אתה מוכן לבצע צ'ק-אין, פעל לפי השלבים הבאים.

   1. ייצאו את הפתרון הלא מנוהל.

   2. באמצעות הכלי מארז הפתרונות, חלץ את הפתרון לקבצי רכיבים.

   3. מתוך קבצי הרכיבים שחולצו, הוסף את הקבצים הדרושים לבקרת המקור.

   4. שלח שינויים אלה לבקרת המקור.

שינוי פתרון

ההליך הבא מזהה את השלבים האופייניים שבהם נעשה שימוש בעת שינוי פתרון קיים.

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

2. באמצעות הכלי מארז הפתרונות, ארוז את קבצי הרכיבים לקובץ ‎.zip של פתרון לא מנוהל.

3. יש לייבא את קובץ הפתרון הלא מנוהל לסביבה.

4. התאם אישית וערוך את הפתרון לפי הצורך.

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

   1. ייצאו את הפתרון הלא מנוהל.

   2. באמצעות כלי ה-Solution Packager, חלץ את הפתרון המיוצא לקבצי רכיבים.

   3. סנכרן או קבל את המקורות העדכניים ביותר מתוך בקרת המקור.

   4. אם קיימות התנגשויות, פתור אותן.

   5. שלח את השינויים לבקרת המקור.

   יש לבצע את שלבים 2 ו- 3 לפני ההתרחשות של התאמות אישיות נוספות בארגון הפיתוח. בשלב 5, יש להשלים את שלב ב' לפני שלב ג'.

למידע נוסף

חומר עזר בנושא קובץ רכיב פתרון (SolutionPackager)
הכלי SolutionPackager
תבניות קובץ של בקרת מקור