استراتيجية إصدار المشروع / التعليمات البرمجية

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

يبدو أن المطورين بحاجة إلى استخدام "فروع الاختبار" واحترام "فرع الإنتاج المستقر / الإنتاج" أكثر قليلا.

بيع في مفهوم "القيام بأشياءك الغربية البرية في هذا الفرع"، وعندما تكون سعيدا بالنتائج، يمكنك دمجها في هذا "فرع الإنتاج المستقر الممل" .... (أو شيء من هذا القبيل)

Answer 4

هناك كتب مكتوبة حول الموضوع العام؛ يقوم Amazon Search حتى بإرجاع ثلاثة عناوين للحصول على "تحكم الإصدار" المتخصص "مع GIT."

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

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