هل لديك أي سياسات الالتزام؟

Question

أعلن مديري أمس عن سياسات الالتزام الجديدة لـ Checkins في المستودع. هذه السياسات صالحة للالتزامات في الرأس/الجذع والفروع.
يجب أن تحتوي رسالة الالتزام على العناصر التالية:

• السبب (معرف الخلل ، معرف المشروع ، أو تغيير غير وظيفي)
• اسم المراجع

بعد الالتزام ، يتعين علينا أيضًا إنشاء إدخال مدونة تغيير في CMS لدينا.

أنا لست معجبًا كبيرًا بهذه السياسات الالتزام ، لأنني لا أحتاج عادةً إلى مراجع عندما أقوم بعمل أشياء جديدة أو تجريبية في فرع غير منتشر.

هل لديك أي سياسات الالتزام هل عليك اتباعها؟

أعتقد أنه من الجيد تغيير الفرع الإنتاجي فقط بسبب تقرير الأخطاء ، ولكن يجب أن يكون فروع التطوير أقل تقييدًا.

Answer 1

الالتزام مبكرا والالتزام في كثير من الأحيان.

نحن في الواقع نستخدم /الجذع كتطوير وعلامات لتفريغ الإصدارات المختلفة. فقط التغييرات التدخلية الهيكلية تذهب في /فروع.

نحن نستخدم علامات الإنتاج والقبول بنشاط ، حتى نتمكن من العودة في الوقت المناسب بسهولة. يجب أن يكون لأي شيء ارتكابه في الجذع رسالة تصف ما الذي تغير الالتزام أو إضافته لفترة وجيزة.

أنا لست معجبًا كبيرًا باستخدام مساحة الرسائل لربط معرف الأخطاء ، فهو لا يزال يتطلب البحث عن المعرف في هذه الحالة في هذه الحالة يمكنك أيضًا البحث عنه في برنامج تتبع الأخطاء وإغلاقه هناك ، وهو ما يتعلق بي نفس الجهد.

حتى لا أقول إنني لا أحب أي تكامل SVN: - نستخدم المزيد من الخير من البرامج النصية الآلية لـ Nant لإصدار الإصدارات التي تفرعها في /علامات - Props SVN بالفعل تخزين أرقام الإصدار لدينا: ص. - خطاف البرامج النصية لإشعار البريد الإلكتروني وتسجيل الرسائل (رائع لنسخ ملاحظات إصدار لصق).

Answer 2

لدينا عدد من السياسات ، والتي يتم فرضها عبر مكون إضافي داخلي إلى Visual Studio. نتحقق من أن مجموعة الرمز ويتم تشغيل اختبارات الوحدة هذه بنجاح. في الوقت الحالي ، نتحقق أيضًا من تغطية الكود وإصدار تحذيرات للرمز الذي لا يحتوي على اختبارات كافية. نقوم أيضًا بإجراء العديد من عمليات فحص الاتساق والتحقق من وجود مهمة مناسبة في نظام إدارة التغيير لدينا من أجل توفير التتبع لجميع التغييرات.

تعتبر ميزة دعم الأدوات رائعة ، لأن الأمر لا يعود إلى الناس احترام السياسات ، ولكن من الواضح أن هناك عيبًا وكذلك هذه الشيكات تستغرق وقتًا طويلاً. ومع ذلك ، مع العديد من المطورين ، من الصعب فرض المعايير دون دعم الأدوات المناسب.

Answer 3

يبدو المراجع بلا جدوى للأسباب التي ذكرتها ، لأنه لا يجب مراجعة كل شيء من قبل الآخرين.

في الماضي ، كانت سياسة الالتزام الوحيدة التي كان لدينا (حيث اعتدت العمل) هي تضمين تعليق يشير إلى ما قمت بتغييره ولماذا ، ولكن هذا هو الفطرة أكثر من أي شيء آخر.

Answer 4

تتمثل سياسة الالتزام الشائعة في ربط معرف الأخطاء بالالتزام بالجذع كمبرر. في بعض الأحيان ، يتم تكوين أنظمة التحكم في الإصدار وتتبع الأخطاء لفرض هذه السياسة.

Answer 5

تبدو سياسة الالتزام الخاصة بنا مثلك إلى حد ما ، ونحن فقط لا نفرضها على فروع المهام (حيث يكون فرع المهام يشبه صندوق الرمل للمطور للتجربة).

يجب أن تتضمن تعليقات التزامنا إما معرف التحكم في التغيير (ميزة جديدة أو تحسين) أو معرف مشكلة (إصلاح الأخطاء). يجب عليك أيضًا تضمين تفسير موجز ل لماذا لقد قمت بهذا التغيير. تتبع التحكم في الإصدار من ، وماذا ، متى وأين.

Answer 6

تتضمن رسالة الالتزام الخاصة بي وصفًا قصيرًا ما قمت بتطبيقه أو تغييره في الفصول الدراسية.

رقم الأخطاء والوصفات الإضافية التي وضعتها في التعليق فوق الكود الجديد. معرفات داخل رسائل الالتزام التي نضعها عندما ندمج التغييرات في فرع معلم.

كل ليلة يقوم البناء التلقائي بالتحقق من الميزات والمنتجات المختلفة أيضًا ، تتأكد من أن قاعدة التعليمات البرمجية تستقر.

لكن في النهاية ، أعتقد أنه لا يمكنك الحصول على الكثير من وصفات الفصول الجديدة أو المتغيرة ، ولكن هناك الكثير من السياسات التي يتعين عليك القيام بها قبل الالتزام. اسم المراجع هو شيء لن أضعه في رسالة الالتزام.

فكر في أن عليك أحيانًا عدم التخلص من الكود الذي قمت بتطبيقه قبل عامين. وبعد ذلك أنت سعيد بالالتزام بالرسائل التي لا تشبه "التحديث بعد تصحيح الأخطاء".

Answer 7

لدينا فروع لكل إصدار رئيسي تم إصداره من البرنامج الذي لا يزال مدعومًا بنشاط. يتطلب التحقق من أي من هذه الفروع معرف الخلل - يتم فرضه بواسطة SCMBUG, ، والتي لن تتحقق فقط من أن التعليق مسبوق بواسطة معرف الأخطاء ، ولكنه سيبحث أيضًا عن هذا الخطأ في قاعدة بيانات الأخطاء ، وتأكد من تعيينه للالتزام ، وربما التحقق من المعايير الأخرى (على سبيل المثال أن "الإصلاح في الفرع" الحقل هو الفرع الذي يجري الالتزام به).

يتمتع أحد المنتجات بمزيد من الإمكانات للفشل في إحراج الطرق ، ويتطلب ذلك التحقق من ذلك ليس مجرد معرف خطأ بل مراجعة التعليمات البرمجية أيضًا. ومع ذلك ، يتم التعامل مع معايير مراجعة التعليمات البرمجية في قاعدة بيانات الأخطاء الخاصة بنا - لدينا حقول مخصصة لهذا ولا يمكن قبول الأخطاء وإغلاقها حتى تتم مراجعتها. بالنسبة لي ، يعمل هذا من المستوى المفاهيمي - من الأفضل التحقق من الكود الذي يُعتقد أنه يعمل في المستودع غير المراجعة ، ثم إعادة فتح الخطأ وتغييره إذا لزم الأمر بدلاً من التوقف عن الالتزام حتى تكون بالتأكيد إنه جاهز للإصدار.

بخلاف ذلك ، لا توجد سياسة صريحة للجذع (على الرغم من بالطبع المبادئ العامة للتحقق في كثير من الأحيان دون كسر البناء ، بما في ذلك رسائل الالتزام الوصفية الجيدة ، والتحقق من وحدات العمل لا تزال تنطبق على ذرية).