لكل شيء عن كل شيء ، يكفي 50 كوبًا من القهوة.
بالإضافة إلى قاعدة الإبهام الموضحة أعلاه ، ننشر ملاحظة قصيرة حول النقاط التي يجب الانتباه إليها جيدًا حتى لا يكسر أي شيء في المعركة وفي العمليات. تم عمل الملاحظة في السعي الحثيث لإطلاق خدمة الهاتف المحمول التي انتقلت بالكامل إلى .Net Core (تم وضع البداية هنا ). تمكنا من تنفيذ هذه العملية دون أن يلاحظها العميل ، تقريبًا دون إيقاف عملية التطوير الرئيسية.
فيما يلي خطة عمل جاهزة ، ستكون هناك قائمة اختبار قوية للغاية ، وستكون هذه الصورة هنا للمزاج:
لذا ، في الخطوات:
1. التخطيط لسباق طويل مع ميزات كبيرة و / أو الانحدار
مع إعادة كتابة التعليمات البرمجية الأساسية ، ستحتاج الخدمة إلى وقت للإصرار لأطول فترة ممكنة من أجل الحصول على الوقت لإصلاح جميع العيوب في بيئة الاختبار.
2. في العدو السريع لإعادة كتابة الرمز على .Net Core
لماذا من المهم عدم بدء هذا العمل في وقت مبكر؟ نظرًا لأنه يتعين عليك سحب فرعين من الكود مع شبكة .net الجديدة والقديمة ، لأنه في أي وقت يمكن أن يطير طائر من الاستعجال أو ستحتاج إلى إجراء عرض توضيحي للميزات الجديدة ، وبعد ذلك ستحتاج إلى إجراء تغييرات على الفرع الثابت القديم. من أجل تجربة الحد الأدنى من القلق حول هذا ، فمن الأفضل تقصير لحظة الدولة الانتقالية.
بالمناسبة ، عند العمل مع الشفرة ، توصلنا بسرعة إلى استنتاج مفاده أنه من الأفضل الاحتفاظ بنسختين من المستودع محليًا. إنه أسهل وأكثر ملاءمة من تبديل فرعين ضخمين.
- إن أمكن ، أعد كتابة واجهات WCF في webapi في الخدمات المستخدمة
لا يزال تنفيذ .Net Core لعميل WCF بعيدًا عن المثالية. على الرغم من حقيقة أن القروح القديمة تم إصلاحها بطريقة ما ، إلا أنه في الإصدارات الجديدة لا يزال عليك استخدام الحل البديل ( 1 ، 2 ).
للقصة: على .Net Core 2.0 ، إصدار العمل المستقر من WCF هو 4.4.2 من مستودع myget. على سبيل المثال ، ليس لديها مشاكل مع مهلة مبكرة
في بداية الترحيل ، استخدمنا إصدار .Net Core 2.0. وفي الوقت نفسه ، أصدرت Microsoft .Net Core 2.1. من يهتم بالإعجاب بنجاحات فريق Redmond في تحسين النظام الأساسي ، يرجى قراءة التقدم الذي أحرزه محرك بحث Bing عند الترقية إلى الإصدار الجديد (المفسد: latensi انخفض بنسبة 34٪!)
قمنا أيضًا بالترقية إلى .Net Core 2.1 و WCF 4.5.3. ولم ننسى أن نحدد في ملف Dockerfile صورة جديدة لمايكروسوفت / دوت نت: 2.1-aspnetcore-runtime. ما كان المفاجأة عندما رأوا ، بدلاً من 1.4 غيغابايت ، صورة بحجم 0.5 غيغابايت (نتحدث عن صورة Windows ، إذا فجأة).
3. سرج لاختبار وتجربة
لدينا بيئتان تحت تصرفنا. تركنا الإصدار التجريبي مع الإصدار القديم كمرجع. تم نشر خدمة جديدة في بيئة الاختبار - تشغيل على المطورين والمختبرين.
كان هناك بعض الارتباك بسبب حقيقة أن المطورين عادة ما يعملون مع الاختبار ، والمختبرون بشكل رئيسي مع عرض. إذا كان من الضروري تحديث الخدمة القديمة ، فالوضع كان عكس الطبيعي تمامًا. لذلك ، كانت المناقشة وورقة الغش حول أين وما الذي تبحث عنه مفيدًا.
لتشغيل خدمة .Net Core في IIS ، يجب تثبيت الوحدة النمطية التي تأتي مع وقت التشغيل.
التبديل AppPool إلى وقت التشغيل CLR = لا يوجد رمز مُدار.
في الحل في web.config القياسي ، من المهم عدم نسيان تعيين وقت الطلب المطلوب وتعطيل وحدة WebDAV ، إذا كانت هناك طرق DELETE.
علاوة على ذلك ، هناك خياران لنشر خدمة في IIS:
- تقوم بمزامنة MSDeploy - وهذا يعني أنك تحتاج أيضًا إلى مفتاح التبديل -enableRule: AppOffline
- تقوم بنشر الملف - هذا يعني بالضبط قبل النشر أن عليك وضع الملف app_offline.htm في دليل الخدمة ، وبعد النشر ، احذفه
كلاهما ، وآخر يسمح بإيقاف عملية العمل وفتح الملفات القابلة للتنفيذ. خلاف ذلك ، سيحدث خطأ في عدم توفر الملفات للكتابة فوقها.
رفضنا تسجيل الدخول عبر Nlog لصالح Serilog ، وفقدنا الضغط التلقائي للسجلات - في Serilog ببساطة لا توجد مثل هذه الميزة. في هذه الحالة ، يمكنك حفظها باستخدام أدوات Windows العادية وتثبيت ضغط NTFS في خصائص الدليل.
4. الاختبار
فيما يلي أكثر قائمة تحقق تقلصًا للأماكن الأكثر هشاشة:
- تحقق من إرجاع رموز الحالة طلب غير صالح ، غير مصرح به ، لم يتم تعديله ، لم يتم العثور عليه - كل ما يمكن أن تقدمه API
- تحقق من تسجيل الطلب لجميع رموز الحالة
- رسم مخطط التبعيات الخارجية ؛ كقاعدة عامة ، جميع المعلومات الضرورية في إعدادات التطبيقات
- إبعاد الأساليب التي تؤثر على عملهم
- تحقق من تسجيل الطلبات الخارجية
- تحقق من عمل الإعدادات لمعلمات appettings ؛ حاول تغييرها ساخنة
- تحقق من التخزين المؤقت http لرموز الحالة الإيجابية والسلبية
- رأس ETag
- التحكم في ذاكرة التخزين المؤقت لرأس الصفحة
- تحقق من الطلبات الطويلة والمهلة
- تحقق من الطلبات بإجابة فارغة
- تحقق من طرق الحذف (WebDAV معطل أم لا)
- تحقق من العمل مع المحتوى الخام
- تحميل وتنزيل ملف واحد / عدة ملفات
- تحميل الملفات بحجم يتجاوز الحد
- رأس ترتيب المحتوى المحتوى
- تحقق من جميع الرؤوس الأخرى ؛ من السهل جدًا جمعها معًا في التعليمات البرمجية
- تحقق من تنفيذ التعليمات البرمجية الشرطية عند تبديل البيئات
if (env.IsDevelopment()) - تحقق قطع الاتصال من العميل والخادم
- مقارنة مع swagger.json القياسي - سيساعد على اكتشاف الاختلاف في الحقول المرسلة
يستخدم تطبيق الهاتف المحمول الخاص بنا منشئ الكود للعمل مع واجهة برمجة التطبيقات استنادًا إلى وصف swagger.json ، لذا كان من المهم أن يكون الفرق عن الوصف الأصلي ضئيلًا. في أحدث إصدار من Swashbuckle.AspNetCore ، تغيرت الواجهة و swagger.json التي تم إنشاؤها كثيرًا. اضطررت إلى العودة إلى الإصدار المتهالك من Swashbuckle.AspNetCore 1.2.0 وإضافة عدة فلاتر.
5. استعد للقتال أثناء شرب القهوة
في حالتنا ، تتكون البيئة القتالية من عقدتين: نشطة وسلبية.
من أجل أن يتم التحول إلى الخدمة الجديدة بسلاسة ، قمنا بتكرار التجمع والموقع على كل عقدة ، وكتبنا نصًا برمجيًا للتبديل بين الموقع القديم والجديد.
وبالتالي ، في حالة الطوارئ ، تمكنا من التبديل بسرعة إلى الإصدار القديم.
علاوة على ذلك ، بعد الانتشار في المعركة ، في غضون أسبوع ، أصبحنا مقتنعين بجدوى الخدمة وأضاءنا ضوءًا أخضر لإصدار تطبيق الهاتف المحمول. عادت الحياة في المشروع بأمان إلى دورته السابقة.
المجموع الفرعي
الآن خدمتنا جاهزة تمامًا لزراعة حاوية عامل ميناء للتسليم إلى الكتلة. نحن مستعدون للنشر في كل من Kubernetes و Service Fabric.
الآن الاستعدادات جارية لتقديم البنية التحتية الجديدة للعميل. سنخبر عن إنجازاتنا في السلسلة التالية ، ابق إصبعك على النبض ؛)