ما هو سير عمل نشر تطبيق الويب المفضل لديك باستخدام SVN؟

Question

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

Answer 1

جذع للتنمية، وفرع (إنتاج) لمواد الإنتاج.

على جهازي المحلي، لدي VirtualHost الذي يشير إلى فرع قناة الاتصال لاختبار التغييرات.

يؤدي أي التزام بالقناة إلى تشغيل خطاف التزام يقوم بتصدير svn ومزامنته مع عنوان URL الخاص بمطوّر الخادم عبر الإنترنت - لذلك إذا كان الموقع هو stackoverflow.com، فسيقوم هذا الخطاف تلقائيًا بتحديث dev.stackoverflow.com

ثم أستخدم svnmerge لدمج التصحيحات المحددة من صندوق السيارة إلى الإنتاج في عمليات الدفع المحلية الخاصة بي.لدي VirtualHost مرة أخرى على جهازي المحلي ويشير إلى فرع الإنتاج.

عندما أقوم بإجراء التغييرات المدمجة على فرع الإنتاج، يقوم خطاف تصدير SVN مرة أخرى بتحديث تصدير الإنتاج (المباشر) ويصبح الموقع مباشرًا!

Answer 2

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

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

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

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

Answer 3

لم أواجه أي مشكلة مع العلامات/الفروع/مؤسسة الجذع المشتركة.

التطوير المستمر العام يحدث في الجذع.

تتم صيانة الإصدار في الإنتاج في فرع الإصدار المناسب.

يتم دمج التغييرات التي تم إجراؤها على فرع الإصدار والتي لا تزال ذات صلة بالجذع.

عندما يكون الإصدار الجديد جاهزًا للنشر، يتم وضع علامة عليه من قناة الاتصال، ثم يتم إنشاء فرع من تلك العلامة.يتم سحب فرع الإصدار الجديد إلى الخادم، بالتوازي مع الإصدار الحالي.عندما يحين وقت التبديل، يتم تبديل المسارات ("mv appdir appdir.old && mv appdir.new appdir").

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

Answer 4

ثلاثة فروع تبدو وكأنها عمل إضافي.

يمكن التعامل مع الاختلافات البيئية من خلال وجود إصدارات مختلفة من الملفات ذات الصلة في صندوق السيارة.أي.قاعدة البيانات.yml وقاعدة البيانات.yml.prod.يجب أن تكون عملية النشر واعية بيئيًا وأن تقوم ببساطة بنسخ الملفات الخاصة بالبيئة بدلاً من الملفات الافتراضية.

Answer 5

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

Answer 6

نحن لا نستخدم الفروع لتنظيم الأشياء المتعلقة بالويب؛فقط لاختبار الأشياء التجريبية التي ستستغرق وقتًا طويلاً (اقرأ:أكثر من يوم) للاندماج مرة أخرى في صندوق السيارة.يمثل الجذع، بأسلوب "التكامل المستمر"، حالة العمل الحالية (المأمول).

وبالتالي، يتم تنفيذ معظم التغييرات مباشرة في صندوق السيارة.سيتم تحديث خادم CruiseControl.NET تلقائيًا على جهاز يقوم أيضًا بتشغيل IIS ويحتوي على نسخ محدثة من جميع موارد الموقع الإضافية المتاحة، بحيث يمكن اختبار الموقع بشكل كامل ونظيف داخل الشركة.بعد الاختبار، يتم تحميل الملفات إلى الخادم العام.

لا أستطيع أن أقول إنه النهج المثالي، لكنه بسيط (وبالتالي مناسب لموظفينا الصغار نسبيًا) وآمن نسبيًا، ويعمل بشكل جيد.

Answer 7

يحتوي Trunk على قاعدة بيانات التطوير "الأساسية" الحالية.

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

نقوم بإنشاء إصدار موسوم في كل مرة ندفع فيها التعليمات البرمجية إلى الإنتاج.المجلد الموجود في /tags هو ببساطة رقم الإصدار.

للنشر في الإنتاج، نقوم بتصدير SVN إلى التدريج.عندما يكون ذلك مرضيًا، نستخدم rsync بسيطًا ليتم طرحه على مجموعات الإنتاج.

Answer 8

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

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

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

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

Answer 9

نحن نستخدم تفريع الإصدار - ويبدو أن هذا أكثر كفاءة بالنسبة لنا من تفريع الميزات الذي كنا نقوم به.

لا تقم بإنشاء فروع مختلفة لبيئات مختلفة.

Answer 10

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

Answer 11

أنا أعمل مع وضع مماثل لما لديك حاليًا.لقد تم تكليفي بإيجاد حل "أفضل" وتم تنفيذ شيء على غرار ما يلي.

يمثل الفرع المباشر الخوادم في حالتها الحالية.

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

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

من الممكن دمج عدة أجزاء من العمل في إصدار واحد إذا كان ذلك يعمل بشكل أفضل.

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

للتغيير من العمل على مشروع إلى آخر، يمكن للمطور ببساطة تحويل بيئة العمل المحلية الخاصة به إلى فرع مختلف.

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