سؤال

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

نحن ناشئة صغيرة وفي الوقت الحالي سير عملنا من التنمية -> الإنتاج يتضمن FTP-ing في وتحميل رمز DEV.

يقع رمز DEV تحت التحكم في التخريب - على الرغم من أننا لم نستفيد من جذوع/علامات/فروع حيث ليس لدي فكرة جيدة عن أفضل طريقة استخدام هذا الهيكل. أشعر أنه يجب أن يكون هناك تكامل سلس مع الموقع المباشر الذي لا يتطلب مني مجلدات وملفات نسخ.

إليك بعض التفاصيل: - التطوير على CakePhp + MySQL - المستضافة في Media Temple (GS) - يستخدم المطورون كل من Mac OS (CODA) و Windows (DreamWeaver)

لذا فإن أسألني هو: كيف تقوم بإعداد سير عمل مناسب قابل للتطوير؟

هل كانت مفيدة؟

المحلول

يبدو تدفق العمل الخاص بك مناسبًا لمؤسسة صغيرة لا تحتوي على ضمان الجودة. أنصحك أن تستثمر بعض الموارد في

1) بناء إصدارات الإنتاج ولديها نظام الإصدار بحيث يمكنك تتبع إصدارات الإنتاج بدقة. ضع علامة على كل إصدار بحيث يمكنك تتبعه.

2) بناء مثبت. لا تلجأ إلى المجلدات يدويًا لأنك قد ترتكب خطأ. كما يجعل التثبيت من السهل تتبعه عندما يحدث خطأ ما في الإنتاج.

3) قم ببعض ضمان الجودة على الإنتاج قبل النشر. حتى القليل من QA يقطع شوطًا طويلاً. المطورين ليسوا مختبرين جيدين لأنهم قد يكونون متحيزين تجاه "ميزات" البرنامج.

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

نصائح أخرى

إحدى الطرق التي قمت بها في الماضي هي أن يكون رمز الإنتاج في الواقع عميلًا للتخريب المباشر ، مما يؤدي إلى سحب فرع "الإنتاج".

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

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

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

أود أن أوصي بالأشياء التالية:

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

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

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

  4. النسخ الاحتياطي الخاص بك SVN. يجب أن يذهب هذا دون أن أقول ولكني عملت في شركة لم يتم نسخ مستودع مصدرنا لأكثر من عامين. يمكنك النسخ الاحتياطي عن طريق القيام بـ SVNDump ثم نسخ الملف الناتج إلى موقع آخر. يمكنك أيضًا النسخ الاحتياطي للمجلدات حيث يوجد مستودعك ثم استعادة في حالة حدوث مشاكل.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top