انتقل إلى المحتوى
خبراتنا

CI/CD وDevOps

خطوط نشر تبني تخصيصات Windchill وإعداداته وتختبرها وتنشرها، فيصبح الإصدار مهمة مجدولة في يوم عمل عادي لا مشروعًا لعطلة نهاية الأسبوع.

لماذا يحتاج Windchill إلى خط نشر

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

ما الذي تفعله خطوط النشر لدينا

  1. البناء. تجميع التخصيصات وتحزيمها انطلاقًا من commit موسوم.
  2. الاختبار. تشغيل اختبارات الوحدات، ثم النشر على بيئة جديدة وتشغيل اختبارات API والتحقق السريع عليها.
  3. التحزيم. إنتاج حزمة واحدة بإصدار محدد، أو صورة Docker واحدة، تُرقّى بين البيئات دون أي تغيير.
  4. الترقية. النشر على بيئة الاختبار ثم الإنتاج، مع خطوة موافقة وقرار مسجّل.
  5. التحقق. فحص نقاط الصحة (health endpoints) وتدفقات العمل الأساسية بعد النشر.
  6. التراجع. العودة إلى الإصدار السابق بإجراء واحد، يُختبر بانتظام بدل أن يُفترض نجاحه.

البنية التحتية كشيفرة

تُوصف الخوادم والشبكات وقواعد البيانات والعناقيد بلغة Terraform أو Bicep، وتُهيّأ باستخدام Ansible. وإنشاء بيئة اختبار جديدة هو تشغيل لخط النشر، لا تذكرة تُرسل إلى فريق آخر.

لا حاجة إلى الحاويات

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

الخطوة التالية

أرونا منظومة Windchill لديكم، وسنريكم خط النشر الآلي.

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