PRolice
v0.0.1 -
ooooooooo. ooooooooo. oooo o8o
`888 `Y88. `888 `Y88. `888 `"'
888 .d88' 888 .d88' .ooooo. 888 oooo .ooooo. .ooooo.
888ooo88P' 888ooo88P' d88' `88b 888 `888 d88' `"Y8 d88' `88b
888 888`88b. 888 888 888 888 888 888ooo888
888 888 `88b. 888 888 888 888 888 .o8 888 .o
o888o o888o o888o `Y8bod8P' o888o o888o `Y8bod8P' `Y8bod8P'
------------ What you gonna do when they come for you -------------
Prolice (تقلص شرطة العلاقات العامة ) هي أداة لإدارة الهندسة لإلغاء وقياس بيانات طلب السحب من مستودعات GitHub.
الصراخ إلى SourceLevel ومدونتها الممتازة حول المقاييس (معظمها يتم تنفيذها من خلال هذا التطبيق):
يعزز العديد من مديري الهندسة طلبات السحب كجزء من سير عمل التطوير. إنها ممارسة موحدة تجلب الكثير من الفوائد. وهو يتألف من مقارنة التغييرات في الفرع مع فرع قاعدة المستودع (يسمى بشكل تقليدي Master).
توفر طلبات السحب مقاييس مفيدة وقابلة للتنفيذ. ومع ذلك ، فإن اتباع المقاييس الخاطئة تسبب تشوهات وجلب عيوب أكثر من الفوائد. يمكن للمديرين استخدام مقاييس طلبات السحب لفهم ديناميات الفريق والتصرف بشكل مناسب لتصحيح السلوكيات قبل أن تخرج الأمور عن المسار.
يهدف Prolice إلى جمع عينة من طلبات السحب من مستودع مستهدف وتحليلها ، بهدف تقديم نظرة ثاقبة على سير عمل المشروع الجماعي مع مرور الوقت.
مرة أخرى ، صرخت إلى Sourcelevel's Blogpost (على محمل الجد ، اقرأها إذا لم تقم بالفعل):
قبل الدخول في المقاييس ، أريد أن أجعل إخلاء المسؤولية: لا تستخدم هذه الأرقام لمقارنة الأفراد .
في بعض الأحيان ، يتطلب الخطأ الذي يصعب العثور عليه إصلاح سطر واحد من التعليمات البرمجية ، واستغرق هذا السطر المفرد أسبوعًا من العمل. لقد شاهدت ذلك عدة مرات في حياتي المهنية.
لقد شاهدت أيضًا مديري الهندسة الذين يشجعون المطورين على فتح طلبات السحب مع الكثير من التغييرات التي لم يكن من غير العملي مراجعتها. عادة ما يعززون أنه من خلال إخبار الجميع بأن هؤلاء المطورين مثمرون ، فإنهم يقومون بالمهمة الصعبة عندما يأخذ الآخرون أسهلهم.
قد يكون قياس الأفراد من خلال طلبات السحب غير عادلة. يميل مطور مخصص للحفاظ على قاعدة كود قديمة إلى أن يكون أبطأ من آخر ، والذي يعمل في مشروع حقل الأخضر.
لهذا السبب فإن قياس طلبات السحب أمر صعب. لا يمكن لمديري الهندسة استخدام بيانات طلب السحب إلى الحمير. إذا قمت بسحب الطلبات ، فأنت تريد أن يتعاون فريقك. في هذه الممارسة ، التعاون هو القيمة الأساسية. لا يمكن قياس جهود المطورين فقط بعدد طلبات السحب المفتوحة أو الاندماج. حتى الأسوأ ، الجهد لا يمثل حجمه.
أول الأشياء أولاً ، سيتعين عليك إنشاء رمز وصول شخصي. هذا شرط لمرة واحدة ولا ينبغي أن يستغرق أكثر من دقيقتين.
سيحتاج الرمز المميز إلى قراءة الوصول إلى المستودعات وسحب الطلبات من أجل العمل . شيء من هذا القبيل:
مع توفر رمز وصولك الشخصي ، وقم بتنزيل ثنائي من قسم الإصدارات ، يتم استدعاء prolice داخل محطة الاختيار المفضلة لديك - حاليًا Linux و MacOS (Darwin): يتم دعمها:
prolice --owner < owner > --repository < repository > --github-token < github-token >على سبيل المثال ، إذا أردنا قياس مقاييس المستودع الرسمي لـ Rust ( ملاحظة : هذا الإعدادات الافتراضية لعينة من 100 PRS):
prolice --owner rust-lang --repository rust --github-token < github-token >يتم دعم مقاييس العلاقات العامة الفردية أيضًا:
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > يحتوي Prolice على اثنين من الأعلام والمعلمات الاختيارية التي يمكن استخدامها لضبط فعلها وحجم العينة:
prolice --helpUSAGE:
prolice [FLAGS] [OPTIONS] --owner < owner > --repository < repository > --sample-size < sample-size > --github-token < github-token >
FLAGS:
-h, --help Prints help information
-m, --include-merge-prs Marks merge-PRs as valid targets for analysis (by default these are
excluded). Valid only for whole Repository analysis ; for individual
PR analysis this flag is ignored
-l, --print-legends Prints the metrics ' legends before sending the operation results to
stdout.
-s, --silent-mode Marks the operation as silent, which turns off all logging and
printing to stdout, with the sole exception of the analysis results.
This makes it useful for piping just the results, without the added
' noise ' . (NOTE: piping is automatically detected, which activates
silent-mode without having to explicitly add the flag to the command)
-V, --version Prints version information
OPTIONS:
-G, --github-token <github-token>
Sets the personal access token under which to perform the PR analysis
-L, --log-level <log-level>
Overrides the logging verbosity for the whole application [default: INFO] [possible
values: INFO, DEBUG, TRACE, WARN, ERROR, OFF]
-O, --owner <owner> The owner of the repository under scrutiny
-P, --pr-number <pr-number>
A specific pull-request to be selected as target for the analysis.
-R, --repository <repository> The repository under scrutiny
-S, --sample-size <sample-size>
The amount of PRs that will be fetched as sample for the analysis (unless a specific PR
number is selected as individual target) [default: 100]يمكن أن تكون نتائج Prolice أنابيب إلى ملف. يتم اكتشاف الأنابيب (أو أي عدم وجود TTY) تلقائيًا بواسطة التطبيق ، والذي سيقوم بإيقاف تشغيل جميع السجلات والرسائل ، حتى لو لم يقدم المستخدم هذه الأعلام كجزء من الأمر. هذا مفيد للحصول على نتائج أولية قد يتم إطعامها في عملية أخرى.
على سبيل المثال:
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json سوف results.json ملفًا
{
"score" : [
{
"AmountOfParticipants" : 4
},
{
"AmountOfReviewers" : 1
},
{
"Attachments" : 1
},
{
"AuthorCommentaryToChangesRatio" : 31.138690476190472
},
{
"PullRequestsDiscussionSize" : 4065
},
{
"PullRequestFlowRatio" : 1.9121686296350902
},
{
"PullRequestLeadTime" : 1
},
{
"PullRequestSize" : 255
},
{
"TestToCodeRatio" : 0.42988095238095236
},
{
"TimeToMerge" : 4
}
]
} ما يعنيه "كل مقياس" (ويعرف أيضًا باسم سبب قيمة القياس) يمكن طباعته كجزء من نتائج التحليل "عن طريق تمرير --print-legends . ومع ذلك ، فإن ذلك قد يلوث المحطة بفعالية مفرطة ؛ للرجوع إليها ، هذه هي معنى كل مقياس:
AmountOfParticipantsكمية الأشخاص غير المؤلفين المشاركين في مناقشة العلاقات العامة. المشاركة الأكبر قد تثري المناقشة وإنتاج رمز جودة أعلى.
AmountOfReviewersكمية الأشخاص غير المؤلفين الذين اتخذوا موقفا على نتائج العلاقات العامة ، إما عن طريق الموافقة أو طلب التغييرات. هذا يقيس مقدار المشاركين الذين يقررون بشكل فعال مصير العلاقات العامة.
Attachmentsيمكن أن تكون المرفقات أي شيء يتراوح من لقطات شاشة إضافية إلى ملفات PDF المضمنة. مفيد بشكل خاص لأولئك PRS الذين لديهم مكون بصري مرتبط به.
AuthorCommentaryToChangesRatioيجب أن يكون الكود الجيد ذاتيًا ؛ ولكن قد يتضمن العلاقات العامة الجيدة أيضًا تعليقًا إضافيًا على ما يهدف إلى تحقيقه ، وكيف يفعل ذلك و/أو لماذا يفعل ذلك بالطريقة المختارة.
قد يكون التعليق الرفيع في العلاقات العامة الغامضة ، وتحويل عبء الفهم إلى المراجع ويستهلك وقتًا إضافيًا منه. من ناحية أخرى ، قد تلوث الكثير من التعليقات العلاقات العامة مع ضوضاء غير ضرورية ، بنفس التأثير.
PullRequestsDiscussionSizeعلى غرار نسبة تعليق المؤلف إلى التغييرات ، فإنه يقيس إجمالي كمية التعليقات في العلاقات العامة ، ولكن بغض النظر عن من جاءوا منه. على عكس وظائف وسائل التواصل الاجتماعي ، يؤدي الكثير من المشاركة في طلبات السحب إلى عدم الكفاءة. يعطي قياس عدد التعليقات وردود الفعل لكل طلب سحب فكرة عن كيفية تعاون الفريق. التعاون رائع ، وتأييده شيء مطلوب. ومع ذلك ، بعد مستوى معين ، تبطئ المناقشات التنمية.
قد تكون المناقشات التي تصبح كبيرة جدًا مؤلفة من شيء خاطئ: ربما لا يتم محاذاة الفريق ، أو ربما لا تكون متطلبات البرنامج دقيقة بما فيه الكفاية. في أي حال ، فإن الاختلال في المناقشات ليس التعاون ؛ هم مضيعة للوقت. في السيناريو المعاكس ، فإن عدم وجود مشاركة تقريبًا يعني أن مراجعة الكود ليست جزءًا من عادات الفريق.
باختصار ، يجب أن يصل هذا المقياس إلى "رقم مثالي" بناءً على حجم الفريق وتوزيعه. لا يمكن أن يكون أكثر من اللازم ، ولا يمكن أن يكون القليل جدًا أيضًا.
PullRequestFlowRatioنسبة تدفق طلب السحب هي مجموع طلبات السحب المفتوحة في يوم مقسوم على مجموع طلبات السحب المغلقة في نفس اليوم. يوضح هذا المقياس ما إذا كان الفريق يعمل بنسبة صحية. يعد دمج طلبات السحب والنشر إلى الإنتاج أمرًا جيدًا ، لأنه يضيف قيمة إلى المستخدم النهائي. ومع ذلك ، عندما يغلق الفريق المزيد من طلبات السحب أكثر من المفتوحة ، قريباً ، توضح قائمة انتظار طلب السحب ، مما يعني أنه قد يكون هناك توقف في التسليم. من الناحية المثالية ، من الأفضل التأكد من أن الفريق يدمج طلبات السحب بنسبة أقرب ما يتم فتحه ؛ كلما اقتربت من 1: 1 ، كان ذلك أفضل.
PullRequestLeadTimeيعطي مقياس المدة الرصاص فكرة عن عدد المرات (عادة في الأيام) التي يتم دمجها أو إغلاقها. للعثور على هذا الرقم ، هناك حاجة إلى تاريخ ووقت كل طلب سحب عند فتحه ثم الاندماج. الصيغة سهلة: متوسط بسيط لفرق التواريخ. يمكن لحساب هذا المقياس في جميع المستودعات في المنظمة أن يمنح الفريق فكرة أوضح عن ديناميكياتهم.
PullRequestSizeتفرض كمية كبيرة من التغييرات لكل علاقات عامة على الضغط على المراجع ، الذي يرى انتباهه بالتفاصيل يقلل أكبر من تغيير. ومن المفارقات أن المطورين يميلون إلى دمج طلبات السحب الأطول بشكل أسرع من أقصر ، لأنه من الصعب إجراء مراجعات شاملة عندما يحدث الكثير من الأشياء. بغض النظر عن مدى شمولية المراجعات ، تؤدي PRS الكبيرة إلى الوقت للاندماج ، والجودة تنخفض.
TestToCodeRatioكقاعدة عامة ، يجب أن يتألف نصف العلاقات العامة على الأقل من اختبارات كلما كان ذلك ممكنًا.
TimeToMergeبشكل عام ، تكون طلبات السحب مفتوحة مع وجود بعض الأعمال الجارية ، مما يعني أن قياس طلب السحب لا يروي القصة بأكملها. حان الوقت للاندماج هو مقدار الوقت الذي يستغرقه الالتزام الأول بفرع للوصول إلى الفرع المستهدف. في الممارسة العملية ، فإن الرياضيات بسيطة: إنها الطابع الزمني لأقدم الالتزام بفرع ناقص الطابع الزمني لالتزام الدمج.
عادة ما يكون وقت الاندماج مفيدًا في حين مقارنة بوقت طلب السحب. خذ المثال التالي:
- سحب طلب المهلة = 3 أيام
- حان الوقت للاندماج = 15 يومًا
في السيناريو أعلاه ، استغرق طلب السحب وقتًا متوسطه 3 أيام لدمجه (وهو أمر جيد جدًا) ؛ ولكن الوقت للاندماج كان 15 يوما. مما يعني أن المطورين عملوا في المتوسط 12 يومًا (15 - 3) قبل فتح طلب سحب.
ملاحظة: يتم تقديم هذا المقياس إلى حد ما إذا عمل المطورون على فروع WIP قبل سحق جميع التغييرات في التزام واحد يتم استخدامه لاحقًا كقاعدة للعلاقات العامة (هذا سيجعل الوقت لدمج مساوٍ فعليًا لوقت طلب السحب). ومع ذلك ، لا يزال المقياس مفيدًا بشكل لا يصدق بالنسبة لدمج PRS (على سبيل المثال ، Merge تطوير إلى Master): سيكون لدى PRS المذكور وقتًا قصيرًا للغاية لطلب السحب المهلة (لا يحصلون على إعادة مراجعة شاملة) ، لكن القياس مقابل تاريخ الالتزام الأول (وقت الاندماج) سيخبر المدة التي تستغرقها الميزات للتراكم في بهم يستحق بما يكفي من الاندماج في أحد البلاغات الكبيرة.
cargo كُتِب برقوق في الصدأ. إن تجميع تطبيق الاستخدام في النظام الأساسي المضيف أمر سهل مثل استخدام cargo build القديمة:
cargo build --releasecargo-make (Linux إلى MacOS)دعنا نبدأ هذا القسم أولاً بمقدمة صغيرة من هذا المدونة الرائعة:
أكره التجميع المتقاطع
هناك ملايين من الطرق لتدمير نظام التشغيل الذي تعمل عليه والتجميع المتقاطع هو واحد منهم. يبدأ عادةً بالفكرة البريئة المتمثلة في الحصول على سلسلة بناء واحدة تحتاج إلى تشغيل برنامج صغير على Linksys WRT 1900 ACS (OpenWrt و ARMV7).
تجد حولك عدة قصاصات مختلفة على Reddit أو بعض المشكلات في مشروع GitHub حيث قام شخص عشوائي بنشر بضعة أسطر من Bash التي تبدو وكأنها مفقودة من المعلومات التي تحتاجها.
يمكن أن يتسبب تشغيل باش في أحد الأشياء التالية:
- إنشاء سلسلة بناء عمل (من غير المرجح للغاية)
- قم بإنشاء سلسلة بناء تفشل بعد 80 ٪ من بنيتك
- أضف مناجم Bitcoin المحلية أثناء التظاهر بإنشاء سلسلة بناء فعليًا
بعد أن شعرت بهذه الآلام على المستوى الشخصي ، تم إتاحة التثبيت المتبادل على مستوى خالٍ من الألم من قبل الأهداف المحددة داخل make- cargo-makefile.toml .
بالطبع ، إذا كان التجميع فقط للآلة المضيفة ، فإن التمسك cargo build القديم هو الخيار الأول دائمًا. ولكن لنفترض أن الهدف كان التجميع من Linux إلى MacOS (Darwin) من نقطة الصفر ، بالإضافة إلى مخطط أدوات الصدأ العادي الذي ستحتاج إلى تثبيت cargo-make على النحو التالي:
cargo install --force cargo-makeبعد ذلك ، يتم الاعتناء بخطوات التجميع بالكامل من خلال التذرع:
cargo make --makefile cargo-makefile.toml release-darwinهذا من شأنه أن يخلق ويضع ، بعد الانتهاء من العملية ، الثنائي المضغوط على:
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
ومع ذلك ، خذ في الاعتبار أن Linux-to-Darwin المتقاطع يتطلب Docker ، لذلك مرة أخرى قد تنقذ العديد من MBS عن طريق التمسك ببناء الثنائيات لآلة المضيف الخاص بك من خلال استدعاء cargo build القديمة البسيطة.
