כיצד לנהל תוכנית InnerSource מוצלחת
כאן, נדון באופן שבו ניתן לעצב תוכנית InnerSource כדי ליהנות מהתבניות הטובות ביותר של קוד פתוח בתוך כל ארגון בפיתוח תוכנה.
מהו InnerSource?
כל אחד יכול להשתמש בתוכנה בקוד פתוח, לשנות ולשתף אותה באופן חופשי. באמצעות תוכנת קוד פתוח, כל אחד יכול להציג, לשנות ולהפיץ פרוייקט לכל מטרה באמצעות הרעיון ששיתוף קוד מוביל לתוכנה טובה ומהימנה יותר.
InnerSource הוא הנוהל של החלת תבניות קוד פתוח על פרוייקטים עם קהל מוגבל. לדוגמה, חברה עשויה להקים תוכנית InnerSource המראה את המבנה של פרוייקט קוד פתוח טיפוסי, פרט לכך שהיא נגישה רק לעובדים בחברה זו. בתוקף, זו תוכנית קוד פתוח מאחורי חומת האש של החברה שלך.
יתרונות InnerSource
תוכנית InnerSource יכולה להציע יתרונות רבים מעבר למה שמודלים מסורתיים של מקור סגור מספקים.
ראשית, הם תומכים בנראות פנימית. גישה לקוד המקור של פרוייקטים אחרים של חברה יכולה לעזור למפתחים להיות פרודוקטיביים יותר בעת עבודה על פרוייקטים משלהם. הם יכולים לראות כיצד צוותים שונים פותרים בעיות דומות לאופן שבו הן נתקלות, ולרוב הן מוצאות קוד ונכסים אחרים בהן הם יכולים לעשות שימוש חוזר. גישה לבעיות צוות, בקשות משיכה ותוכניות פרוייקט גם מספקת נתונים טובים יותר כדי לאפשר להם להבין את המהירות והכיוון של הפרוייקט.
בשלב הבא, להפחית את. נניח שצוות צרכן תלוי בתיקון באגים או בתכונה חדשה עבור פרוייקט בבעלות צוות אחר. בתוכנית InnerSource, יש להם ערוץ שדרכו הם יכולים להציע את השינויים הדרושים להם. ואם לא ניתן למזג שינויים אלה מסיבה כלשהי, לצוות הצרכן יש אפשרות להוסיף את הפרוייקט כדי שיעמוד בצרכים שלו.
לבסוף, הם לתתקנים את. ארגוני פיתוח אתגרים נפוצים בפני ארגונים הוא שקבוצות שונות מתפצלות לעתים קרובות בדרכים שהן פועלות. בניית תוכנית InnerSource היא הזדמנות נהדרת לאמץ מוסכמות סטנדרטיות שניתן להשתמש בהן בכל צוות פיתוח, גם אם הם אינם פועלים לפי שיטות עבודה זהות. לדוגמה, שני צוותים עשויים להעדיף תהליכים שונים לקבלת תרומות. תקנים של התהליכים השונים שלהם מאפשרת לכל אחד לתרום בקלות רבה יותר.
עצה
שקול להשתמש בדיונים של GitHub ובפרוייקטים של GitHub כדי לתמוך עוד יותר בשיתוף פעולה של InnerSource בין צוותים.
דוגמאות אלה הן רק כמה מהיתרונות שתוכניות InnerSource נהנות מהן. לקבלת מידע נוסף, ראה מבוא ל- InnerSource.
הגדרת תוכנית InnerSource ב- GitHub
הגדרת ניראות והרשאות של מאגר
באפשרותך להגדיר מאגרים של GitHub עם שלוש רמות של ניראות. משתמשים שאינם עומדים בדרישות הניראות רואים דפים "לא נמצאו" כשהם מנסים לגשת למאגר שלך. הרמות הן:
- מאגרי ציבוריים גלויים לכולם. השתמש ניראות זו עבור פרוייקטים שהם באמת קוד פתוח ומציעים גישה לאנשים בתוך הארגון ומחוצה לו.
- מאגרים פנימיים גלויים רק לחברי הארגון שבבעלותם.
הערה
מאגרים פנימיים זמינים רק ללקוחות GitHub Enterprise. השתמש ניראות זו עבור פרוייקטים של InnerSource.
- מאגרי פרטיים גלויים רק לבעלים ולקבוצות או לאנשים שהם מוסיפים. השתמש ניראות זו עבור פרוייקטים שרק למשתמשים ולקבוצות ספציפיים צריכה להיות גישה אליהם.
לאחר יצירת ניראות המאגר, באפשרותך לקבוע תצורה של הרשאות על בסיס אדם או צוות. קיימות חמש רמות הרשאה:
- הקריאה מומלצת עבור משתתפים שאינם משתתפים בקידוד שברצונך להציג את הפרוייקט או לדון בו.
- קביעת עדיפויות מומלצת עבור משתתפים שיצטרכו לנהל באופן יזום בעיות ובקשות משיכה ללא גישת כתיבה.
- כתיבה רמה מומלצת עבור משתתפים שגולשים לפרוייקט באופן פעיל.
- שמור רמה זו מומלץ עבור מנהלי פרוייקטים הזקוקים לניהול המאגר ללא גישה לפעולות רגישות או הרסניות.
- ניהול מומלצת עבור אנשים הזקוקים לגישה מלאה לפרוייקט, כולל פעולות רגישות והרסניות, כגון ניהול אבטחה או מחיקה של מאגר.
קבל מידע נוסף הרשאות גישה למאגר לפי רמה.
יצירת מאגרים הניתנים לגילוי
ככל שתוכנית InnerSource גדלה, מספר המאגרים גדל באופן משמעותי. למרות שזה נהדר שכל הנכסים הללו זמינים לארגון, זה עלול להיות מאתגר למצוא תוכן ביעילות. כדי לטפל בבעיה זו באופן יזום, מומלץ לצוותים לשקול מה הם יכולים לעשות כדי להקל על אחרים למצוא את המאגרים שלהם ולעבוד איתם.
כמה שיטות עבודה מומלצות כוללות:
- השתמש בשם תיאורי של מאגר, כגון
warehouse-apiאוsupply-chain-web. - כלול תיאור תמציתי. משפט או שניים אמורים להספיק כדי שמשתמשים פוטנציאליים יוכלו לדעת אם הפרוייקט עשוי להתאים לצרכיהם.
- רשיון למאגר שלך כך שהלקוחות יוכלו לדעת כיצד הם יכולים להשתמש בתוכנה, לשנות אותה ולהפיץ אותה.
- כלול
README.mdקובץ במאגר. GitHub משתמש בקובץ זה כדף הנחיתה כאשר אנשים מבקרים במאגר.
הוספת קובץ README
קובץ README מקיים תקשורת עם הציפיות של הפרוייקט שלך עוזר לך לנהל תרומות. קבצי README יכולים:
- להסביר את המטרה והחזון של הפרוייקט כך שצרכנים פוטנציאליים יבינו אם הוא מתאים לצרכיהם.
- הצע עזרים חזותיים, כגון צילומי מסך או דוגמאות קוד, כדי להמחיש את הפרוייקט בפעולה.
- כלול קישורים לגירסת ייצור או הדגמה של היישום לסקירה.
- הגדר את הציפיות עבור דרישות מוקדמות ונהלי פריסה.
- כלול הפניות לפרוייקטים שבהם אתה תלוי. הפניות אלה הן דרך טובה לקדם את עבודתם של אחרים.
- השתמש ב- Markdown כדי להדריך קוראים באמצעות תוכן מעוצב כראוי.
אם אתה מכניס את קובץ ה-README.md שלך לספריית השורש של המאגר שלך, או בספרייה המוסתרת .github או docs בספריה, GitHub מזהה ומציג אוטומטית את ה-README שלך למבקרים במאגר. אם מאגר מכיל יותר מקובץ README אחד, הקובץ המוצג נבחר ממיקומים בסדר הבא:
- המדריך
.github - ספריית השורש של המאגר
- המדריך
docs
עיין בכמה דוגמאות README מדהימה.
לאחר הפעלת הפרוייקט, השתמש בדואר אלקטרוני ובערוצים אחרים של עבודה ברשת כדי לקדם אותו. הגעה לקהל מתאים עשויה להפיק דחיפה משמעותית בהשתתפות הפרוייקט.
קבל מידע נוסף על קובצי README בתיעוד של GitHub.
ניהול פרוייקטים ב- GitHub
ככל שפרוייקטים מתקדמים, ההון של משתמשים ותרומות יכול לדרוש הרבה עבודה לניהול. בהתאם לפרוייקט, ייתכן שתידרש כמות עבודה משמעותית רק כדי לנהל את הציפיות של משתתפי הפרוייקט.
כדי לטפל בבעיה זו באופן יזום, GitHub CONTRIBUTING.md קובץ חדש בבסיס (או /docs או /.github) של מאגר. השתמש בקובץ זה כדי להסביר את מדיניות התרומה עבור הפרוייקט. הפרטים המדויקים עשויים להשתנות, אך מומלץ לאפשר למשתתפים פוטנציאליים לדעת באילו מוסכמות הפרוייקט פועל. לדוגמה, כאשר הצוות מחפש בקשות משיכה, אילו פרטים מתבקשים עבור דוחות באגים וכן הלאה.
אם קיים CONTRIBUTING.md, GitHub מציג קישור אליו כאשר משתמשים יוצרים בעיות או בקשות משיכה כדי לעודד אותם לעקוב אחריו.
ראה כמה מדהים CONTRIBUTING.md דוגמאות
בנוסף, שקול קובץ CODEOWNERS למאגר כדי להגדיר אנשים או צוותים האחראים על סקירת שינויי קוד.
יצירת תבניות של נושא ובקשה משיכה
GitHub תומך בתבניות להפעלה עבור בעיות חדשות ובקשות משיכה. השתמש בתבניות אלה כדי לספק את טקסט התיאור הראשוני עבור בעיה חדשה שנוצרה או בקשת משיכה.
לדוגמה, אם הפרוייקט שלך כולל .github/ISSUE_TEMPLATE.md, בכל פעם שמשתמש מתחיל בתהליך של יצירת בעיה, הוא רואה תוכן זה. במקום לעיין כל הזמן בפרטים הדרושים מקובץ CONTRIBUTING.md, הם יכולים פשוט למלא את הבעיה כמו טופס באמצעות טקסט התבנית.
הדבר זהה עבור בקשות משיכה, פרט לכך שהנתיב .github/PULL_REQUEST_TEMPLATE.md.
עיין בכמה של GitHub & תבניות בקשת משיכה.
הגדרת זרימות עבודה
עבור פרוייקטים המעודדים תרומות חיצוניות, הקפד לציין איזו זרימת עבודה תתווסף לפרוייקט. זרימת העבודה צריכה לכלול פרטים אודות המקום והאופן שבו יש להשתמש הסתעפויות עבור באגים ותכונות. היא אמורה לכלול גם את האופן שבו יש לפתוח בקשות משיכה, וכל פרטים אחרים שאנשים מחוץ לצוות המאגר צריכים לדעת לפני שהם דוחפת קוד. אם עדיין לא עלית על זרימת עבודה, שקול להשתמש בזרימת GitHub.
עליך להודיע על אסטרטגיה לניהול מהדורות ופריסה. חלקים אלה של זרימת העבודה משפיעים על יצירת הסתעפות יומית ומיזוג, ולכן חשוב להעביר אותם למשתתפים. קבל מידע נוסף על האופן שבו הם קשורים לאסטרטגיית של Git.
מדידת הצלחת התוכנית
כל צוות ההוצאת לתוך InnerSource צריך לחשוב על סוגי המדדים שהם רוצים לעקוב אחריהם כדי לאמוד את הצלחת התוכנית שלהם. בעוד מדדים מסורתיים כגון "זמן לשוק" ו"באגים מדווחים" הם עדיין ישימים, הם לא בהכרח הולכים להמחיש את היתרונות שהושגו באמצעות InnerSource.
במקום זאת, שקול להוסיף מדדים המראה כיצד השתתפות חיצונית שיפרה את איכות הפרוייקט. האם המאגר שמקבל בקשות משיכה ממקורות חיצוניים מתקן באגים ומוסיף תכונות? האם קיימים משתתפים פעילים בדיונים לגבי הפרוייקט והעתיד שלו? האם התוכנית מעוררת השראה להרחבת InnerSource שמעוררת יתרונות במקום אחר בארגון?
בקצר, מדדים מקשים, במיוחד כשמדובר במדידת הערך וההשפעה של תרומות בודדים לצוותים. במקרה של שימוש לא נכון, מדדים יכולים להזיק לתרבות, לתהליכים הקיימים ולהקטין את הסנטימנט הקולקטיבי כלפי הארגון או צוות המנהיגות. בעת מחשבה על מדידת האימוץ של InnerSource, שקול את ההנחיות הבאות לגבי מדדים:
- תהליך מדידה, לא פלט
- זמן הפעלה של סקירת קוד
- גודל בקשת משיכה
- עבודה מתבצעת
- זמן לפתיחה
- מדוד כנגד יעדים ולא מוחלטים
- מדוד צוותים ולא אנשים בודדים
- מספר המשתתפים הייחודיים לפרוייקט
- מספר הפרוייקטים המשתמשים בקוד מחדש
- מספר קווים חוצי @mentions
למד על ההצלחות שאנשים אחרים נהנו מהם ניתוחי מקרה של InnerSource.