غالبًا ، كجزء من فحص طلب السحب ، بالإضافة إلى مراجعة الشفرة نفسها ، هناك حاجة إلى إجراء مجموعة من الفحوصات الروتينية. قد تتعلق بعض الشيكات بتصميم العلاقات العامة. أخرى - تحقق من الشروط ذات الصلة التي تشكل أساس عملية اعتماد التغيير.
إذا لم تكن الفحوصات الروتينية آلية ، فقد يبدأ الشخص في نسيانها أو التحايل عليها. لأن الروتين ممل.
تقدم Visual Studio Team Services بنية تحتية ملائمة إلى حد ما للتعامل مع طلب السحب. يتضمن هذا سياسات دمج مدمجة مخصصة ، وتعيين المراجعين ، ودمج قواعد التغييرات المقبولة. كل هذا يكمله نظام ملائم لمناقشة والتعليق على التعليمات البرمجية.
إن أقوى أداة لتوسيع عملية طلب السحب هي سياسات المكونات الإضافية الخارجية.
سنتحدث عن إنشائها واستخدامها (ونرى الرمز)
حالات طلب سحب قابلة للتوسيع
حالات العلاقات العامة هي علامات محددة في السياق. السياق - مزيج فريد من اسم السياق و "النوع". عادة ما يكون النوع واحدًا لكل تطبيق يعالج الحالة.
على سبيل المثال:
الحالة 1: النوع = 'my-policy' ، name = 'check-1'
الحالة 2: النوع = 'my-policy' ، name = 'check-2'
تأخذ الحالة إحدى القيم المحددة مسبقًا. لغرض دعم العملية ، سنهتم باثنين: نجحت وفشلت.
يمكن استخدام الحالات عند إعداد سياسة الإفطار المتأخر: يجب أن تكون العلامات المحددة قد نجحت في الحالة حتى يتم قبول العلاقات العامة. بنفس الطريقة ، يتم تنفيذ سياسات مدمجة للتحقق من عدد السائقين ، ووجود تذكرة مرفقة ، وما إلى ذلك.
انتقل إلى تحرير سياسة الفرع. أضف سياسة خارجية.
إذا تم تعيين الحالة مرة واحدة على الأقل ، فستتوفر في القائمة المنسدلة.
في الجزء السفلي ، يمكنك تحديد عنوان للحالة ، وكيف سيتم عرضها في كتلة إكمال طلب السحب.
ستظهر الحالات المضافة في صفحة طلب السحب في خانة الاختيار:
إذا لم يتم استخدام الحالة كسياسة ، يتم عرض قيمتها على الصفحة في قسم الحالة. إذا تم تحديد الحالة كسياسة ، فسوف تكون مرئية أعلى الكتلة.
إدارة حالة البرنامج
يمكن معالجة حالات العلاقات العامة برمجياً باستخدام REST API. وبالتالي ، من الممكن تنفيذ عمليات فحص إضافية للعلاقات العامة وترجمة نتائجها مباشرة إلى عملية إجراء التغييرات.
تتم إضافة قيمة الحالة الجديدة من خلال طريقة إنشاء . بالإضافة إلى النتيجة والسياق ، من الضروري نقل النص الذي يراه المستخدم. يمكنك تمرير عنوان URL اختياريًا: في هذه الحالة ، ستصبح علامة الحالة في نموذج العلاقات العامة رابطًا وسيتمكن المستخدم من الانتقال إلى الصفحة التي تحتوي على تفاصيل الحالة.
ينتج عن استدعاء الأسلوب إنشاء سجل حالة PR جديد. ضمن سياق واحد ، تعتبر قيمة الحالة المضافة الأخيرة نشطة. إدخالات الحالة السابقة غير مرئية من واجهة المستخدم ، ولكن يمكن الحصول عليها باستخدام طريقة القائمة .
بالنسبة لحالة الحالات في الصورة السابقة ، يمكن أن تكون القائمة الحقيقية لحالات طلب السحب كما يلي:
{ "value": [ { "id": 1, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.0324172Z", "updatedDate": "2018-11-06T18:35:57.0324172Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 2, "state": "failed", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.5167963Z", "updatedDate": "2018-11-06T18:35:57.5167963Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 3, "state": "succeeded", "description": "No offset from develop", "context": "@{name=check-offset; genre=my-pr-policy}", "creationDate": "2018-11-06T18:35:57.782379Z", "updatedDate": "2018-11-06T18:35:57.782379Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 4, "state": "succeeded", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:46:37.2627154Z", "updatedDate": "2018-11-06T18:46:37.2627154Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 5, "state": "succeeded", "description": "Build for last update", "context": "@{name=check-build; genre=my-pr-policy}", "creationDate": "2018-11-06T18:51:33.7920543Z", "updatedDate": "2018-11-06T18:51:33.7920543Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 6, "state": "failed", "description": "PR title format", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T18:53:44.3075889Z", "updatedDate": "2018-11-06T18:53:44.3075889Z", "createdBy": "Masked value", "targetUrl": null }, { "id": 7, "state": "failed", "description": "Title format is not correct", "context": "@{name=check-title; genre=my-pr-policy}", "creationDate": "2018-11-06T19:26:11.3019433Z", "updatedDate": "2018-11-06T19:26:11.3019433Z", "createdBy": "Masked value", "targetUrl": null } ], "count": 7 }
بعد الاطلاع على قائمة الحالات الحالية ، يمكنك تحديث الحالة المحددة حسب الفهرس في القائمة. للقيام بذلك ، استخدم طريقة التحديث .
أخيرًا ، يمكن حذف سجلات الحالة باستخدام طريقة الحذف .
يمكن أن يكون سجل تغييرات حالة العلاقات العامة مفيدًا لمزيد من التحليل. لذلك ، نستخدم الطريقة التالية لتغيير الحالات:
- ابحث عن أحدث سجل حالة لنفس السياق
- إذا كانت لديها نفس قيم النتائج والأوصاف والروابط التي نريد إضافتها ، فلن نفعل شيئًا
- خلاف ذلك ، قم بإضافة سجل حالة جديد.
هذا يسمح لك بالاحتفاظ بسجل من التغييرات ، وليس تضخيمه إلى حد كبير.
function Set-PullRequestStatus { param( [Parameter (Mandatory = $true)] [string] $pullRequestId, [Parameter (Mandatory = $true)] [string] $state, [Parameter (Mandatory = $true)] [string] $description, [Parameter (Mandatory = $true)] [string] $contextName, [Parameter (Mandatory = $false)] [string] $contextGenre, [Parameter (Mandatory = $false)] [string] $targetUrl, [Parameter (Mandatory = $true)] [object] $context ) $b = @{ state = $state; description = $description; context = @{ name = $contextName; genre = $contextGenre; }; targetUrl = $targetUrl; } $body = ConvertTo-Json $b # # Get current list of statuses # $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) # # Try to find a status for a given context genre and name. Start looking from the last one. If found - check if it has same values. # $i = $res.count $foundSameStatus = $false while ($i -GT 0) { $r = $res.value[$i-1] if (($r.context.name -EQ $contextName) -AND ($r.context.genre -EQ $contextGenre)) { $foundSameStatus = ($r.state -EQ $state) -AND ($r.description -EQ $description) -AND ($r.targetUrl -EQ $targetUrl) break } $i-- } $res = $r # # If same status / values was not found - add new record. # if (-not $foundSameStatus) { $endpoint = (Get-ProjectBaseURL) + "/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=4.1-preview.1" $res = Get-AzureRequestReqults -URI $endpoint -context ($context + @{pullRequestId = $pullRequestId}) -method POST -query $body } return @{status = $res; status_changed = $(-not $foundSameStatus)} }
تطبيق عملي
لقد اعتمدنا نهجًا محافظًا إلى حد ما لقبول التغييرات في فرع التكامل. نحاول اختبار التغيير إلى الحد الأقصى في فرع الميزة إلى الحد الأقصى.
فيما يلي بعض المهام التي نقوم بحلها بمساعدة حالات العلاقات العامة ، كجزء من السياسات المخصصة:
- يجب أن يتم تزيين جميع المستفيدين الرئيسيين بنفس النمط. لذلك ، فإن أول عنصر تحكم تم إنشاؤه هو تصميم رأس العلاقات العامة. نتحقق من ذلك مقابل التعبير العادي.
- لا يجب أن يتأخر فرع العلاقات العامة خلف الفرع حيث يتم سكبه (يتم التكامل).
- إذا تم تغيير ملفات مشروع قاعدة البيانات ، في إطار العلاقات العامة ، فيجب أيضًا وجود ملفات الاختبار التلقائي.
- يوجد تجميع ناجح للفرع للتغيير الأخير.
- تم ضخ هذا التجميع بنجاح إلى منصة الاختبار واجتازت الاختبارات التلقائية.
يمكن التحقق من الشروط المذكورة يدويًا. لقد فعلنا هذا من قبل. لكن هذا روتين ، وقد تم استبداله بعملية آلية. الآن يمكننا استكمال وتغيير مجموعة الشيكات - سيتم دمجها دائمًا في العملية ، وتنفيذها دائمًا.
إضافة ضخمة أخرى من السياسات - فهي شفافة للجميع ، ودائمة في الأفق - على صفحة العلاقات العامة. لم تعد بحاجة إلى تذكير.
بالإضافة إلى ذلك ، بالنسبة إلى السياسات التي تفشل التحقق ، نعرض رابطًا لصفحات Wiki الخاصة بنا مع وصف للسياسة والإجراءات المتوقعة.
التنفيذ الفني لإنفاذ السياسة
حاليا ، يتم تنفيذ منطق السياسة في شكل مخطوطات powerhell. نظرًا لأن cmdlets عالية المستوى ونموذج بيانات كائن جيد ، فإن كود البرنامج النصي مضغوط للغاية. والقدرة على تشغيل البرنامج النصي بشكل تفاعلي في خطوات والتعامل مع المتغيرات تجعل عملية التطوير والتصحيح أسهل بكثير.
بالمناسبة ، بعد إصدار نواة powerhell - يمكن تشغيل البرامج النصية على منصات أخرى (تم اختبارها على نظام MacOS).
قم بتشغيل البرامج النصية في إصدار خاص من VSTS وفقًا لجدول زمني مرة كل بضع ساعات تقريبًا. ربما سنبدأ في الجري عبر sheduler في كثير من الأحيان.
هذا النهج ، بالطبع ، يعطي استجابة أبطأ بشكل ملحوظ مما لو قمت بتطبيق نفس الشيء في شكل وظيفة Azure وربطه بـ VSTS من خلال ربط الويب. ولكن بالنسبة لنا كان من الأهم تنفيذ عمليات التحقق ومعرفة كيفية عمل ذلك في العملية (MVP). كفاءة الفحص ليست مهمة بعد. ستكون هذه هي الخطوة التالية.
يمكن العثور على المكتبات للعمل مع VSTS REST API ، والتي يتم استخدامها في عمليات الفحص ، بالإضافة إلى مثال صغير يطبق بعض هذه السياسات في المستودع على GitHub . آمل أن يجدها شخص ما مفيدا.