يشبه خط النشر الخاص بـ Windchill خط النشر لأي تطبيق مؤسسي آخر، مع فارقين: التطبيق ضخم وبطيء في الإقلاع، وإعداداته لا تقل أهمية عن شيفرته. وإليكم البنية التي نعتمدها، والترتيب الذي نبنيها به.
1. إدارة المصدر لكل شيء
التخصيصات، وسكربتات البناء، وسكربتات النشر، وأكبر قدر ممكن من الإعدادات القابلة للتصدير، كلها في Git. وتصل التغييرات عبر طلبات دمج (pull requests) يراجعها مهندس ثانٍ. وما ليس في Git لا يستطيع خط النشر نشره، وهذا هو المقصود تحديدًا.
2. البناء مرة واحدة
يجمّع خط النشر التخصيصات انطلاقًا من commit موسوم، وينتج حزمة واحدة بإصدار محدد: حزمة للأجهزة الافتراضية أو صورة Docker لـ Kubernetes. وتُرقّى هذه الحزمة دون أي تغيير من الاختبار إلى الإنتاج. فإعادة البناء لكل بيئة هي الطريقة التي تتسلل بها الفروقات.
3. الاختبار على ثلاث طبقات
- اختبارات الوحدات لمنطق الأعمال، وتعمل في ثوانٍ دون خادم Windchill.
- اختبارات API تستدعي نقاط REST وخدماتكم على نسخة منشورة حديثًا.
- اختبارات التحقق السريع تمرّ على عدد قليل من التدفقات الحرجة: إنشاء قطعة، وإيداع مستند، واعتماد تغيير.
يقلع Windchill ببطء، ولذلك نُبقي مرحلة الاختبار على البيئة المنشورة مركّزة. فحزمة قصيرة تعمل عند كل دمج أثمن من حزمة طويلة تعمل مرة في الشهر.
4. الترقية بقرار
ينتظر النشر على بيئة الإنتاج موافقةً، وتُسجَّل الموافقة مع ملاحظات الإصدار التي ولّدها خط النشر. وهذا يرضي المدققين، ويرضي المهندسين أيضًا، لأن سؤال ما الذي تغيّر ومن وافق عليه يجد إجابته في مكان واحد.
5. التحقق والإبقاء على طريق للعودة
بعد النشر، يفحص خط النشر نقاط الصحة ويعيد تشغيل اختبارات التحقق السريع. ويعيد التراجع نشر الحزمة السابقة. ونختبره بانتظام، لأن تراجعًا لم يُنفَّذ قط مجرد أمنية، لا خطة.
من أين تبدأون
إن كانت إصداراتكم يدوية اليوم، فابدأوا بالمرحلتين 1 و2: Git والبناء الآلي. فهما تزيلان أكبر قدر من المخاطر بأقل جهد، وتُبنى عليهما كل المراحل اللاحقة.