الهندسة والجودة
أطلق التغييرات أسرع وبإخفاقات أقل
نُعد مسارات CI/CD في Jenkins لبرمجيات SAP وغيرها، والحاويات باستخدام Docker وتنسيقها عبر Kubernetes، والمراقبة والتنبيه والتراجع الآلي، ليكون كل إصدار صغيراً ومُختبراً وقابلاً للتراجع.
مدى سرعة وأمان إصدارك للبرمجيات يحدد اليوم مدى سرعة تغيّر أعمالك. ويجعل DevOps كل إصدار صغيراً ومُختبراً وقابلاً للتراجع.
كل تغيير بالطريقة نفسها
البرمجة، والبناء، والتحزيم، والاختبار، والنشر، والمراقبة: مسار واحد لتغييرات SAP وغيرها.
مسار التسليم لدينا: كل تغيير يُبنى ويُختبر ويُنشر بالطريقة نفسها.
ما نُعده
مسارات CI/CD
المشكلة
- عمليات بناء ونشر تتم يدوياً
- إصدارات كبيرة تفشل في عطلة نهاية الأسبوع
- لا سجل لما تغيّر ومتى
ما نقدمه
- مسارات Jenkins من الإيداع (Commit) حتى الإنتاج
- بناء واختبار وفحوص أمنية آلية
- موافقات مدمجة في المسار
- سجل كامل لكل إصدار
النتيجة: إصدارات صغيرة ومتكررة ويمكن التنبؤ بها.
Jenkins · Git · GitHub Actions · GitLab CI
DevOps لـ SAP
المشكلة
- نقل التغييرات (Transports) يدوياً
- تطبيقات BTP تُنشر بطريقة مختلفة في كل مرة
- تغييرات SAP تُختبر يدوياً
ما نقدمه
- نقل آلي للتغييرات وضبط التغيير
- CI/CD لتطبيقات SAP BTP وCAP
- اختبار انحدار آلي باستخدام Tosca ضمن المسار
- تتبع التغييرات باستخدام SAP Cloud ALM
النتيجة: إصدار تغييرات SAP بالانضباط نفسه المطبق على أي برمجيات أخرى.
SAP Cloud ALM · gCTS · SAP BTP · Tosca
الحاويات وKubernetes
المشكلة
- تطبيقات تعمل على خادم وتفشل على آخر
- التوسع يتم بشراء خوادم أكبر
- تعافٍ بطيء بعد الأعطال
ما نقدمه
- تطبيقات مُحزّمة في حاويات Docker
- عناقيد Kubernetes تتوسع وتتعافى ذاتياً
- مخططات Helm وقوالب نشر قياسية
- صور حاويات وسجلات آمنة
النتيجة: تطبيقات تعمل بالطريقة نفسها في كل مكان، وتتوسع عند الطلب.
Docker · Kubernetes · Helm · SAP BTP Kyma
البنية التحتية كرمز
المشكلة
- خوادم تُبنى يدوياً ولا تتطابق أبداً
- لا طريقة لإعادة بناء بيئة بسرعة
- أسئلة تدقيق حول من غيّر ماذا
ما نقدمه
- بيئات مُعرّفة كرمز
- بيئات اختبار وإنتاج قابلة للتكرار
- فحوص السياسات قبل تطبيق التغييرات
- سجل إصدارات لكل تغيير في البنية التحتية
النتيجة: بيئات يمكنك إعادة بنائها وتدقيقها والوثوق بها.
Terraform · Ansible · Microsoft Azure · Git
المراقبة والتراجع
المشكلة
- المستخدمون يبلغون عن المشكلات قبل أن تعلم بها تقنية المعلومات
- لا رؤية واضحة لسلامة الأنظمة
- إصدارات فاشلة يستغرق التراجع عنها ساعات
ما نقدمه
- لوحات معلومات للتطبيقات والبنية التحتية
- تنبيهات قبل أن يتأثر المستخدمون
- تراجع آلي عندما يفشل الإصدار في الفحوص
- السجلات والتتبعات في مكان واحد
النتيجة: اكتشاف المشكلات مبكراً، والتراجع عن الإصدارات السيئة بسرعة.
Prometheus · Grafana · ELK stack · SAP Cloud ALM
كيف ننفذ
- التقييممراجعة كيفية بناء البرمجيات واختبارها وإصدارها اليوم. تحصل على: رؤية لمستوى نضج DevOps.
- التصميمالمسارات والأدوات والمعايير المستهدفة. تحصل على: مخطط DevOps.
- البناءالمسارات والحاويات والبنية التحتية كرمز. تحصل على: مسارات عاملة.
- التبنيتدريب فرقك ونقل التطبيقات إلى المسار. تحصل على: فرق تُصدر بالطريقة الجديدة.
- التشغيلالمراقبة والدعم والتحسين. تحصل على: إصدارات تزداد أماناً باستمرار.
قبل وبعد
الإصدارات اليوم
- بناء ونشر يدوي
- إصدارات كبيرة ومحفوفة بالمخاطر
- مشكلات يبلغ عنها المستخدمون
- ساعات للتراجع
الإصدارات مع INK DevOps
- مسارات آلية من الإيداع حتى الإنتاج
- إصدارات صغيرة ومتكررة ومُختبرة
- مراقبة وتنبيهات قبل أن يلاحظ المستخدمون
- تراجع آلي
ذو صلة
- هندسة الجودة وأتمتة الاختبار
- الترحيل إلى السحابة والتحديث
- التطوير المتكامل والخدمات المصغرة
- وظّف مهندسي DevOps
اجعل الإصدارات روتينية من جديد
أخبرنا كيف تبني وتُصدر اليوم، وسنريك الخطوات الأولى نحو إصدارات أسرع وأكثر أماناً.
الأسئلة الشائعة
هل يصلح DevOps لـ SAP؟
نعم. نؤتمت نقل التغييرات (Transports)، ونشر SAP BTP، واختبار الانحدار، ونتتبع التغييرات في SAP Cloud ALM.
هل نحتاج إلى Kubernetes؟
ليس دائماً. تفيد الحاويات أكثر ما تفيد في التطبيقات التي تحتاج إلى التوسع أو الإصدار المتكرر. ونوصي بما يناسب تطبيقاتك.
ما الأدوات التي تستخدمونها؟
Jenkins أو GitHub Actions أو GitLab CI للمسارات، وDocker وKubernetes للحاويات، وTerraform وAnsible للبنية التحتية، وأدوات المراقبة القياسية.
هل يمكنكم تدريب فريقنا؟
نعم. نبني المسارات الأولى مع فريقك ونرافقه حتى يتمكن من تشغيلها وتوسيعها بنفسه.
تحدّث مع خبير SAP
أخبرنا بما تعمل عليه. يرد عليك استشاري أول خلال يوم عمل واحد.