سؤال

أو، في الواقع، إنشاء عملية بناء عندما لا يكون هناك الكثير منها للبدء بها.

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

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

الأدوات ذات الصلة:Safe Build Source Safe 6.0 (أعرف ، لكن لا يمكنني فعل أي شيء بشأن ما إذا كنا نستخدم المصدر الآمن في هذا الوقت أم لا.قد تكون هذه هي المعركة التالية التي أخوضها.)

مبدئيًا، لدي مشروع Visual Build الذي يقوم بما يلي:

  1. احصل على المصدر وضعه في الدليل المحلي، بما في ذلك ملفات DLL الضرورية للمشروع.
  2. احصل على ملفات التكوين وأعد تسميتها حسب الحاجة (نقوم بتخزينها في دليل فرعي خاص ليس جزءًا من التطبيق الفعلي، ويتم تسميتها وفقًا للاستخدام).
  3. البناء باستخدام Visual Studio
  4. قم بالترجمة المسبقة باستخدام سطر الأوامر، والنسخ إلى ما سيكون دليل "الإنشاء".
  5. نسخ إلى الوجهة.
  6. احصل على أي موارد إضافية ضرورية - معظمها أشياء مثل المستندات والصور والتقارير المرتبطة بالمشروع (ووضعها في الدليل من الخطوة 5).هناك الكثير من هذه الأشياء، ولم أرغب في تضمينها سابقًا.ومع ذلك، سأقوم فقط بنسخ العناصر التي تم تغييرها، لذلك ربما يكون الأمر غير ذي صلة.لم أكن متأكدًا مما إذا كنت أرغب حقًا في تضمين هذه الأشياء في الخطوات السابقة.

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

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

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

المحلول

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

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

أتمنى أن يساعدك هذا.

نصائح أخرى

لدي مجموعة من نصوص Powershell التي تقوم بكل هذا من أجلي.

السيناريو 1:البناء - هذا بسيط، ويتم التعامل معه في الغالب من خلال استدعاء msbuild، كما أنه يقوم بإنشاء البرامج النصية لقاعدة البيانات الخاصة بي.

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

السيناريو 3:النشر - يتم تشغيله على كل جهاز فردي من داخل المجلد الذي تم إنشاؤه بواسطة البرنامج النصي للحزمة (يتم نسخ البرنامج النصي للنشر كجزء من الحزمة)

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

بالنسبة لملفات web.config، أستخدم الملف

<appSettings file="Local.config">

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

[تحرير] ما يعادل ملف appSettings= لقسم التكوين هو configSource="Local.config"

لقد تحولنا من استخدام البرنامج النصي Perl إلى MSBuild منذ عامين ولم ننظر إلى الوراء.يمكن إنشاء حلول الاستوديو المرئي بمجرد تحديدها في ملف xml الرئيسي.

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

هناك مقدمة جيدة جدًا هنا:مقدمة

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

ومع ذلك، فإن أي بناء آلي أفضل من عدم البناء الآلي.

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

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

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

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

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

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

إذا كانت هذه الفكرة لا تخيف القارئ، إذن (إما أنهم مجانين أو) فمن المحتمل أن يحصلوا على عمل + "مدير الأوتار المفضل لديك" للعمل معهم.

نحن نستخدم UppercuT.يستخدم UppercuT NAnt للبناء وهو سهل الاستخدام للغاية.

http://code.google.com/p/uppercut/

بعض التفسيرات الجيدة هنا: UppercuT

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