ما هي القطع الأثرية التي يجب حفظها من أجل البناء الليلي؟

Question

لنفترض أنني قمت بإعداد البناء الليلي التلقائي.ما هي القطع الأثرية للبناء التي يجب أن أحفظها؟

على سبيل المثال:

• إدخال كود المصدر
• ثنائيات الإخراج

وأيضاً كم من الوقت يجب أن أحفظهم وأين؟

هل تتغير إجاباتك إذا قمت بالتكامل المستمر؟

Answer 1

فيما يلي بعض القطع الأثرية/المعلومات التي اعتدت الاحتفاظ بها في كل إصدار:

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

اسأل نفسك هذا السؤال:"إذا كان هناك شيء ما يدمر بيئة البناء/التطوير الخاصة بي بالكامل، فما هي المعلومات التي سأحتاجها لإنشاء بيئة جديدة حتى أتمكن من إعادة البناء رقم 6547 وينتهي الأمر بنفس النتيجة التي حصلت عليها في المرة الأولى؟"

إجابتك هي ما يجب عليك الاحتفاظ به في كل بناء وسيكون مجموعة فرعية أو مجموعة شاملة من الأشياء التي ذكرتها بالفعل.

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

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

ولا، لا أعتقد أن الأمر يتغير إذا قمت بالتكامل المستمر.

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

هذه هي الطريقة الوحيدة التي يمكنك من خلالها التحقق من إعدادات المترجم وخطوات البناء وما إلى ذلك.

وأيضاً ما هي مدة حفظها وأين يتم حفظها؟

احفظها حتى تعلم أن هذا الإصدار لن يتم إنتاجه، طالما أن لديك الأجزاء المجمعة.

أحد الأماكن المنطقية لحفظها هو نظام SCM الخاص بك.هناك خيار آخر وهو استخدام أداة تقوم بحفظها لك تلقائيًا، مثل AnthillPro وأمثاله.

Answer 7

نحن نقوم بشيء قريب من التطوير "المضمن" هنا، ويمكنني أن أخبركم بما قمنا بحفظه:

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

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

• إجمالي ودلتا حجم نظام الملفات، مقسمة حسب نوع الملف و/أو الدليل
• إجمالي ودلتا أحجام قسم التعليمات البرمجية (.text، .data، .rodata، .bss، .sinit، إلخ)

عندما يكون لدينا اختبارات الوحدة أو الاختبارات الوظيفية (على سبيل المثال.اختبارات الدخان) تظهر هذه النتائج في سجل البناء.

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

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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