يا عناء. Visual Studio 2003 وCruise Control.NET. بسيطة وأنيقة. برنامج نصي أساسي لـ NAnt لبناء الحل وأنت على ما يرام. قم بتشغيل NUnit، وسينتقل الإخراج إلى تنسيق يمكن لـ CC فهمه وعم بوب. اسمحوا لي أن أحدد هذا. يحتوي خادم الرحلات البحرية الخاص بنا على عميل تخريبي (سطر الأوامر) و.NET 1.1 SDK. لم يتم تثبيت Visual Studio لأنه خادم وتحتاج الرحلة فقط إلى شيء لبناء النظام به.
أدخل Visual Studio 2005. لقد قمت مؤخرًا بإعداد CI لمشاريعنا لعام 2005 ولكنه مجرد قبيح، من نواحٍ عديدة. في البداية كانت هناك محاولة لجعل النظام يبني باستخدام MSBuild. كان ذلك جيدًا لأنه يمكنك ببساطة إدخال هذا:
msbuild /t:rebuildsolutionname.sln
(أو أي هدف تريده مثل Debug أو Release)
كما قلت، إذا كان هذا كل ما في الأمر، فلن تكون هناك مشكلة ولكنه يصبح قبيحًا للغاية بسرعة.
أولاً هناك مشاريع اختبار وحدة VSTS. تم تجهيز الفريق بالكامل ببرنامج Visual Studio Team Suite. اقتراح باهظ الثمن، لكنه طرح منذ فترة طويلة من قبل شخص أكثر حكمة مني. لا توجد مشكلة بالرغم من ذلك. نحن لا نستخدم مدير الاختبار كثيرًا، ولا توجد اختبارات ويب آلية، لذلك نكتب فقط اختبارات الوحدة (ونقوم بتشغيلها باستخدام TestDriven.NET الممتاز لجيمي كانسدال). ومع ذلك، عندما يحصل MSBuild على حل يحتوي على مشروع اختبار وحدة VS، فإنه يحتاج إلى مجموعة إضافية من التجميعات (التجميعات المدفونة في GAC_MSIL وأماكن أخرى). كان المقتطف الموجود في ملف ccnet.config لبدء تشغيل MSBuild واضحًا ومباشرًا:
<msbuild>
<executable>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</executable>
<workingDirectory>D:ccnetprojectsProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>إنشاء</targets>
<مهلة>600</مهلة>
<logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
من خلال القوة الغاشمة (قم بتشغيل MSBuild، واكتشف التجميع الذي يحتاجه، وابحث عنه، ثم اغسله، ثم اشطفه، ثم كرره) تمكنت من الحصول على حل عام 2005 (مع مشاريع اختبار الوحدة) لتجميعه. لكن إجراء الاختبارات في الواقع قصة أخرى. مرة أخرى، سادت القوة الغاشمة هنا بينما كنت أمضي ساعة أو ساعتين في تشغيل MSTest.exe لمحاولة إقناع بضع مئات من اختبارات الوحدات للتشغيل. يبدو إدخال cc.config للحصول على بعض اختبارات الوحدة كما يلي:
<exec>
<executable>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</executable>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
تذكر أنني قلت أن هذا الخادم لم يتم تثبيت Visual Studio عليه. بالنسبة لحلول VS2005، قمت للتو بتثبيت .NET SDK 2.0 وكان ذلك جيدًا بما فيه الكفاية. على الرغم من عدم تضمين MSTest.exe، فقد قمت بإخراج الملف (وهي مجموعة مجنونة من ملفات DLL الإضافية المنتشرة في جميع أنحاء القرص الصلب) من نظام آخر وألصقته في مكان ملف EXE لذا سيكون الأمر سعيدًا.
لا توجد نرد عند تشغيل MSTest مقابل مشروع اختبار الوحدة. لقد بدأ في مسار تشغيل الاختبار، ولكن بعد ذلك حدث خطأ COM مجنون (CLSID غير مسجل) وكان ذلك كافيًا بالنسبة لي. بأي حال من الأحوال سأقوم بتعقب كافة إعدادات تسجيل COM الغبية لبرنامج Visual Studio 2005. وماذا كان هذا بحق الجحيم؟ كوم؟ اعتقدت أننا تخلصنا من ذلك منذ حوالي 3 مترجمين؟
لذلك كنت عالقًا في تثبيت Team Suite الكامل على الخادم. حسنًا، سأعض. أعني أنني لا أحتاج إلى كل شيء لذا سيكون الأمر على ما يرام (أظل أقول لنفسي وأنا أشاهد ملء مليون إدخال تسجيل). بعد بضع ساعات وأنا أحدق في موجه الأوامر الخاص بي مرة أخرى وأكتب الأمر MSTest.exe. وينبثق مربع حوار. نعم، مربع حوار مشروط يخبرني بوجود خطأ ما (لا أتذكر التفاصيل ولكنه لم يكن مفيدًا جدًا).
تم تثبيت Visual Studio بشكل جيد وكان بإمكاني تجميع الحل الذي كنت أحاول تنفيذه وتشغيله وإنشائه، ولكن الاختبار من سطر الأوامر باستخدام MSTest.exe كان أمرًا محظورًا. بغض النظر عن مدى صعوبة محاولتي، أو مقدار التنظيف الذي قمت به، أو عدد العذارى الذين ضحيت بهم، فلن ينجح الأمر. وهناك مشكلة أخرى. مع عام 2003 واختبارات NUnit لدينا، نحصل على بعض الإحصائيات الرائعة. المواعيد، والرسائل الإعلامية، وكل تلك الأشياء الجيدة. مع MSTest، لا نحصل على أي شيء (بخلاف عدد x من الاختبارات التي تم إجراؤها وربما الفشل، لكنني لم أستطع الوصول إلى هذا الحد لمعرفة ما إذا كان سيعطي تفاصيل الفشل). علاوة على ذلك، فإن مسجل MSBuild يعض وينتج حوالي 10000 سطر من gobbly-gook التي ليست مفيدة جدًا. نعم، يمكنني قضاء وقتي في كتابة ملف xslt جديد لجعله جميلًا، وإزالة سطور "كل شيء على ما يرام" التي تملأ مسجل مهام MSBuild ولكني أعتقد أن هذه ليست ذات قيمة مضافة بأسعاري.
إليك نموذج بريد إلكتروني حصلت عليه من الإصدار والذي يمنحك فكرة عن مدى عدم فائدة مجموعة CC.NET/MSBuild/MSTest:
BUILD SUCCESSFUL
المشروع: PROJECTNAME
تاريخ الإنشاء: 12/8/2006 8:08:30 صباحاً
وقت العرض: 00:00:55
طلب التكامل: أدى الفاصل الزمني إلى إنشاء (ForceBuild)
أخطاء (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): خطأ MSB4041: يجب أن تكون مساحة اسم XML الافتراضية للمشروع هي مساحة اسم MSBuild XML. إذا تم تأليف المشروع بتنسيق MSBuild 2003، فيرجى إضافة xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " إلى <Project> عنصر. إذا تم تأليف المشروع بالتنسيق القديم 1.0 أو 1.2، فيرجى تحويله إلى تنسيق MSBuild 2003.
تحذيرات (1)
SourceReportsServerReportsServerReports.rptproj (,): تحذير MSB4122: فشل فحص تبعيات المشروع للمشروع "SourceReportsServerReportsServerReports.rptproj". يجب أن تكون مساحة اسم XML الافتراضية للمشروع هي مساحة اسم MSBuild XML. إذا تم تأليف المشروع بتنسيق MSBuild 2003، فيرجى إضافة xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " إلى <Project> عنصر. إذا تم تأليف المشروع بالتنسيق القديم 1.0 أو 1.2، فيرجى تحويله إلى تنسيق MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
تشغيل الاختبارات: 0، حالات الفشل: 0، عدم التشغيل: 0، الوقت: 0 ثانية
لا توجد اختبارات تشغيل
هذا المشروع ليس لديه أي اختبارات
التعديلات منذ البناء الأخير (0)
انها قبيحة. قبيحة حقا. ينتج MSBuild الكثير من المخرجات المجنونة. إن كتابة ملف MSBuild جديد ليس بالأمر السهل، وحتى بالنسبة لشخص مثلي يعرف NAnt جيدًا، ما زلت أفكر في كيفية عمل MSBuild للأشياء. اضطررت إلى إنشاء تكوين خاص داخل Visual Studio لحذف مشروع التقرير الخاص بنا لأن MSBuild لا يمكنه إنشاءه (وبالتالي فإن AutomatedBuild المستهدف أعلاه ليس هو نفس التكوين الذي يستخدمه مطورونا وهو شيء لا أحب القيام به لأنه أحد هذه التكوينات) نقطة خادم CI، تصميمات متسقة للجميع).
من الناتج أعلاه، قال كروز إن البناء كان على ما يرام ولكن هناك رسالة خطأ خرجت من مسجل MSBuild (مشروع تقريرنا). هذا مشروع عام 2005، لذا فإن المعلومات غير منطقية (أعتقد أنه خطأ تم تسجيله ولكن من يدري متى يمكن إصلاحه). وأنا حقًا لا أستطيع دمج مخرجات MSTest في البريد الإلكتروني، لأنه لا يوجد شيء. هناك مائة اختبار أو نحو ذلك في هذا المشروع ولكن المسجل لا ينتج أي شيء.
بالإضافة إلى ذلك، هناك بعض أنواع المشاريع التي لا يستطيع MSBuild التعامل معها، ومرة أخرى، يتطلب الأمر عالم صواريخ لإنشاء ملف MSBuild (حتى باستخدام شيء رائع مثل MSBuild Sidekick) يمكنه استدعاء مهمة MSBuild أخرى واستبعاد مشاريع معينة. من المؤكد أن هذا ليس سهلاً كما كان في عام 2003 حيث قمت للتو بإنشاء قائمة استبعاد (لقد استبعدنا تطبيق العميل الخاص بنا لأنه لم يكن هناك ترخيص إضافي للتحكم في الشبكة وظهر مربع حوار مشروط عندما تم فحص الإصدار التجريبي من قبل المترجم).
حسنًا، هذا غالبًا ما يكون صراخًا ولكن هناك بعض الحكمة هنا. التكامل المستمر لا يجب أن يكون بهذه الصعوبة. تعد CruiseControl.NET أداة ممتازة ومرنة للغاية مع الأدوات الجديدة ودمج المخرجات من تلك الأدوات. ومع ذلك، عندما تتطلب هذه الأدوات مليونًا من إعدادات التسجيل والمزيد من ملفات DLL (ضعها في أماكن محددة جدًا، ثق بي، لا يمكنك فقط رميها في GAC وإيقافها يوميًا) وتفريغ كميات كبيرة من XML التي ليست مجرد بشر (حسنًا ربما يستطيع DonXml) أن يكون قادرًا على الترجمة، فهذا خطأ. وفيما يتعلق بـ Team Build المدمج الذي يمكنك تقديمه لنا، فهو عديم الفائدة بنفس القدر مثل أ) لا يمكنك جدولة عمليات الإنشاء لبدء عمليات التحقق من التعليمات البرمجية و ب) مرة أخرى، يتطلب الأمر تثبيت عميل Team Suite كامل على الخادم . أسوأ سيناريو عندما بدأت في إعداد خوادم CC.NET لأول مرة، استغرق الأمر 4 ساعات. يمكنني الآن إنجاز ذلك خلال ساعة (والذي يتضمن اختبار إنشاء المشروع الأول). لقد أمضيت يومًا جيدًا بالفعل في محاولة تجميع شيء ما. إنه يتم التجميع الآن ولكن الإخراج سيء ولا يوجد أي اختبارات وهذا ليس جيدًا بما يكفي بالنسبة لي. يمكنك تشغيل MSBuild و(ربما) MSTest مع CruiseControl.NET. هذا ليس مستحيلا. إذا قمت بتثبيت العميل الكامل وكانت مشاريعك "صحيحة تمامًا" فسوف تعمل ولكن الإخراج ليس بهذه السرعة وستشاهد ضربة قوية لوحدة المعالجة المركزية لخادمك عند حدوث عمليات التحويل البرمجي.
نصيحتي، تجنب محاولة الجمع بين MSBuild وMSTest وCruiseControl والالتزام بـ NAnt وNUnit (استخدم MSBuild إذا كان عليك ذلك عند إنشاء حلول 2005).
وغني عن القول أنني أبحث في خيار واحد الآن. تفريغ تثبيت VS2005 على الخادم، وتغيير جميع اختبارات الوحدة لدينا مرة أخرى إلى NUnit واستخدام NAnt للقيام بكل شيء (ومجرد استدعاء MSBuild كمهمة تنفيذية لمشاريع VS2005). ما زلت بحاجة إلى تشغيل مشاريع 2003، لذا سيبدو خادم CI الخاص بنا مثل وحش Frankenstein بحلول الوقت الذي أنتهي منه، حيث أقوم ببناء مشاريع VS2003 وVS2005، وتشغيل NUnit وMSBuild وNAnt وSimian وFxCop وأي شيء آخر لدينا في موقعنا مزج. حتى مع الأخذ في الاعتبار أن استخدام NAnt سيكون الناتج أبسط (ويتكامل بشكل جيد مع CC.NET)، وستكون نتائج الاختبار مفيدة وغنية بالمعلومات، ولست بحاجة إلى تثبيت برنامج بقيمة 15000 دولار على خادم يتمتع بإمكانية واضحة لإنشاء مربع حوار مشروط منبثق يومًا ما عندما لا يتمكن من العثور على بعض مفاتيح التسجيل.
جرر. ارغ.