בקרת מקור עם קבצי פתרונות
ניתן להשתמש בכלי SolutionPackager עם כל מערכת בקרת מקור. לאחר חילוץ קובץ .zip של פתרון לתיקיה, פשוט הוסף ושלח את הקבצים למערכת בקרת המקור שלך. לאחר מכן, ניתן לסנכרן קבצים אלה במחשב אחר ולארוז אותם שם בקובץ .zip זהה חדש של פתרון.
היבט חשוב בעת שימוש בקבצי רכיבים שחולצו בבקרת המקור הוא שהוספת כל הקבצים לבקרת המקור עשויה לגרום לשכפול מיותר. ראה חומר עזר בנושא קובץ רכיב פתרון כדי לגלות אילו קבצים נוצרים עבור כל סוג רכיב ואילו קבצים מומלצים לשימוש בבקרת המקור.
מכיוון שהתאמות אישיות ושינויים נוספים נדרשים עבור הפתרון, המפתחים צריכים לערוך את הרכיבים או להתאים אותם אישית באמצעים הקיימים, לייצא שוב כדי ליצור קובץ .zip ולחלץ את קובץ הפתרון הדחוס לאותה תיקיה.
חשוב
למעט הסעיפים המתוארים במאמר מתי יש לערוך את קובץ ההתאמות האישיות, אין תמיכה בעריכה ידנית של קבצי .zip וקבצי רכיבים שחולצו.
כאשר הכלי SolutionPackager מחלץ את קבצי הרכיבים, הוא אינו מחליף קבצי רכיבים קיימים בעלי אותו שם אם תוכן הקבצים זהה. בנוסף, הכלי מכבד את התכונה לקריאה בלבד בקבצי רכיבים אשר מפיקה אזהרה בחלון המסוף שקבצים מסוימים לא נכתבו. כך מתאפשר למשתמש להוציא, מתוך בקרת המקור, את הערכה המינימלית של הקבצים שמשתנים. ניתן להשתמש בפרמטר /clobber לצורך עקיפה, כדי לגרום לכתיבה או למחיקה של קבצים לקריאה בלבד. ניתן להשתמש בפרמטר /allowWrite כדי להעריך את ההשפעה של פעולת חילוץ מבלי לגרום בפועל לכתיבה או למחיקה של קבצים. ניתן להשתמש בפרמטר /allowWrite באופן יעיל עם רישום מילולי.
לאחר השלמת פעולת החילוץ עם ערכת הקבצים המינימלית שהוצאה מתוך בקרת המקור, המפתח יכול לשלוח את הקבצים שהשתנו בחזרה לבקרת המקור, כפי שנעשה עם כל סוג אחר של קובץ מקור.
פיתוח צוות
כאשר כמה מפתחים עובדים על אותו רכיב פתרון, עלולה להיווצר התנגשות כאשר שינויים של שני מפתחים גורמים לשינויים בקובץ אחד. ניתן לצמצם את הסיכוי להתרחשות מצב זה על-ידי חילוץ של כל רכיב או רכיב משנה הניתן לעריכה בנפרד אל קובץ נפרד. שקול את הדוגמה הבאה.
מפתח א' ומפתח ב' עובדים על אותו פתרון.
במחשבים עצמאיים, שניהם מקבלים את המקורות העדכניים ביותר של הפתרון מתוך בקרת המקור, אורזים אותם ומייבאים קובץ .zip של פתרון לא מנוהל לארגונים עצמאיים של Microsoft Dataverse.
מפתח א' מתאים אישית את תצוגת המערכת 'אנשי קשר פעילים' ואת הטופס הראשי עבור הישות 'איש קשר'.
מפתח ב' מתאים אישית את הטופס הראשי עבור הישות 'תיק לקוח' ומשנה את 'תצוגת בדיקת מידע של אנשי קשר'.
שני המפתחים מייצאים קובץ .zip של פתרון לא מנוהל ומבצעים חילוץ.
מפתח א' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'איש קשר' וקובץ אחד עבור התצוגה 'אנשי קשר פעילים'.
מפתח ב' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'תיק לקוח' וקובץ אחד עבור 'תצוגת בדיקת מידע של אנשי קשר'.
שני המפתחים יכולים לבצע שליחה, בכל סדר, מכיוון שהשינויים המתאימים שלהם נגעו בקבצים נפרדים.
לאחר השלמת שתי השליחות, הם יכולים לחזור על שלב 2 ולאחר מכן להמשיך לבצע שינויים נוספים בארגונים העצמאיים שלהם. כל אחד מהם מקבל את שתי קבוצות השינויים, ללא החלפות של העבודה שלהם.
הדוגמה הקודמת ישימה רק כאשר מתבצעים שינויים בקבצים נפרדים. לא ניתן להימנע ממקרים שבהם התאמות אישיות עצמאיות יחייבו שינויים בקובץ אחד. בהתבסס על הדוגמה שהוצגה לעיל, בוא נניח שמפתח ב' התאים אישית את התצוגה 'אנשי קשר פעילים' בזמן שגם מפתח א' התאים אותה אישית. בדוגמה חדשה זו, סדר האירועים הופך לחשוב. התהליך הנכון לפתרון הבעיה מפורט להלן במלואו.
מפתח א' ומפתח ב' עובדים על אותו פתרון.
במחשבים עצמאיים, שניהם מקבלים את המקורות העדכניים ביותר של הפתרון מתוך בקרת המקור, אורזים אותם ומייבאים קובץ .zip של פתרון לא מנוהל לארגונים עצמאיים.
מפתח א' מתאים אישית את תצוגת המערכת 'אנשי קשר פעילים' ואת הטופס הראשי עבור הישות 'איש קשר'.
מפתח ב' מתאים אישית את הטופס הראשי עבור הישות 'תיק לקוח' ומשנה את 'אנשי קשר פעילים'.
שני המפתחים מייצאים קובץ .zip של פתרון לא מנוהל ומבצעים חילוץ.
מפתח א' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'איש קשר' וקובץ אחד עבור התצוגה 'אנשי קשר פעילים'.
מפתח ב' יצטרך להוציא קובץ אחד עבור הטופס הראשי של 'תיק לקוח' וקובץ אחד עבור התצוגה 'אנשי קשר פעילים'.
מפתח א' הוא הראשון שמסיים.
לפני השליחה לבקרת המקור, עליו לקבל את המקורות העדכניים ביותר כדי לוודא שאף הכנסת קובץ קודמת אינה מתנגשת עם השינויים שלו.
אין התנגשויות, כך שהוא יכול לבצע את השליחה.
מפתח ב' מסיים אחרי מפתח א'.
לפני השליחה, עליו לקבל את המקורות העדכניים ביותר כדי לוודא שאף הכנסת קובץ קודמת אינה מתנגשת עם השינויים שלו.
קיימת התנגשות, מכיוון שהקובץ עבור 'אנשי קשר פעילים' השתנה מאז האחזור האחרון של המקורות העדכניים ביותר.
מפתח ב' חייב לפתור את ההתנגשות. ייתכן שהיכולות של מערכת בקרת המקור שבה נעשה שימוש עשויות לסייע בתהליך זה; אם לא, כל האפשרויות הבאות תקפות.
מפתח ב', דרך היסטוריית בקרת המקור, אם זמינה, יכול לראות שמפתח א' ביצע את השינוי הקודם. באמצעות תקשורת ישירה, הם יכולים לדון בכל אחד מהשינויים. לאחר מכן, מפתח ב' צריך רק לעדכן את הארגון שלו לגבי הפתרון שעליו הוסכם. לאחר מכן, הוא מייצא, מחלץ ומחליף את הקובץ שכולל התנגשויות ושולח אותו.
הוא יכול לאפשר לבקרת המקור להחליף את הקובץ המקומי שלו. מפתח ב' אורז את הפתרון ומייבא אותו לארגון שלו, ולאחר מכן מעריך את מצב התצוגה ומתאים אותה אישית מחדש בהתאם לצורך. לאחר מכן, הוא יכול לייצא, לחלץ ולהחליף את הקובץ שכולל התנגשויות.
אם השינוי הקודם מיותר, מפתח ב' מאפשר לעותק שלו של הקובץ להחליף את הגירסה בבקרת המקור ולאחר מכן מבצע שליחה.
בין אם מדובר בעבודה בארגון משותף או בארגונים עצמאיים, פיתוח צוות של פתרונות Dataverse דורש מהמפתחים שעובדים באופן פעיל על פתרון משותף להיות מודעים לעבודה של אנשים אחרים. הכלי SolutionPackager אינו מבטל את הצורך הזה במלואו, אך הוא מאפשר מיזוג קל של שינויים שאינם מתנגשים ברמת בקרת המקור, וכן מדגיש באופן יזום את הרכיבים התמציתיים שבהם התרחשו התנגשויות.
הסעיפים הבאים מתארים את התהליכים הכלליים לשימוש יעיל בכלי SolutionPackager בבקרת המקור בעת פיתוח עם צוותים. הם פועלים באופן זהה עם ארגונים עצמאיים או עם ארגוני פיתוח משותפים, למרות שעם ארגונים משותפים, הייצוא והחילוץ יכללו באופן טבעי את כל השינויים שקיימים בתוך הפתרון, ולא רק את השינויים שבוצעו על-ידי המפתח שמבצע את הייצוא. בדומה לכך, בעת ייבוא קובץ .zip של פתרון, מתרחש אופן הפעולה הטבעי: החלפת כל הרכיבים.
יצירת פתרון
ההליך הבא מזהה את השלבים האופייניים שבהם נעשה שימוש בעת יצירת פתרון לראשונה.
בארגון נקי, צור פתרון בשרת Dataverse ולאחר מכן הוסף או צור רכיבים בהתאם לצורך.
כשתהיה מוכן להכניס קובץ, בצע את הפעולות הבאות.
ייצא את הפתרון הלא מנוהל.
באמצעות הכלי SolutionPackager, חלץ את הפתרון לקבצי רכיבים.
מתוך קבצי הרכיבים שחולצו, הוסף את הקבצים הדרושים לבקרת המקור.
שלח שינויים אלה לבקרת המקור.
שינוי פתרון
ההליך הבא מזהה את השלבים האופייניים שבהם נעשה שימוש בעת שינוי פתרון קיים.
סנכרן או קבל את המקורות העדכניים ביותר של קבצי רכיבי הפתרון.
באמצעות הכלי SolutionPackager, ארוז את קבצי הרכיבים לקובץ .zip של פתרון לא מנוהל.
ייבא את קובץ הפתרון הלא מנוהל לארגון.
התאם אישית וערוך את הפתרון לפי הצורך.
כשתהיה מוכן להכניס את השינויים לבקרת המקור, בצע את הפעולות הבאות.
ייצא את הפתרון הלא מנוהל.
באמצעות הכלי SolutionPackager, חלץ את הפתרון המיוצא לקבצי רכיבים.
סנכרן או קבל את המקורות העדכניים ביותר מתוך בקרת המקור.
אם קיימות התנגשויות, פתור אותן.
שלח את השינויים לבקרת המקור.
יש לבצע את שלבים 2 ו- 3 לפני ההתרחשות של התאמות אישיות נוספות בארגון הפיתוח. בשלב 5, יש להשלים את שלב ב' לפני שלב ג'.
למידע נוסף
חומר עזר בנושא קובץ רכיב פתרון (SolutionPackager)
הכלי SolutionPackager