مسار إصدار يبني مرة واحدة عبر ثلاث بيئات على Azure
تُبنى كل عملية إيداع (commit) مرة واحدة، وتُرقّى الصورة نفسها من بيئة التطوير إلى ما قبل الإنتاج ثم إلى الإنتاج، مع اختبارات وفحوص للجودة والثغرات تمنع الدمج.
- الشريك
- شركة استشارية متعددة الجنسيات
- المدة
- من أكتوبر 2024 إلى يناير 2026
- بناء لكل إيداع
- 1
- الصورة التي تُختبر في بيئة ما قبل الإنتاج هي نفسها التي تُصدَر
- بيئات
- 3
- التطوير وما قبل الإنتاج والإنتاج
- بوابات دمج
- 3
- الاختبارات وبوابة الجودة في SonarQube وTrivy
التحدي
احتاجت منصة تُستخدم على نطاق مؤسسة كبيرة إلى إصدارات يمكن توقعها، وفصل واضح بين البيئات، وفحوص أمنية لا يمكن تجاوزها عند الدمج.
ما بنيناه
عمليات سير عمل في GitHub Actions تبني صورة Docker واحدة لكل إيداع، وتوسمها بمعرّف SHA الخاص بالإيداع، وترفعها إلى Azure Container Registry، ثم ترقّي الصورة نفسها عبر بيئات التطوير وما قبل الإنتاج والإنتاج. ويُمنع قبول طلب الدمج (pull request) عند إخفاق الاختبارات، أو إخفاق بوابة الجودة في SonarQube، أو ظهور نتائج حرجة في فحص Trivy، وتحتاج إصدارات الإنتاج إلى موافقة.
ما تم تسليمه
- صورة واحدة لكل إيداع، تُرقّى إلى الإنتاج دون تغيير
- منع الدمج عند إخفاق الاختبارات أو بوابة الجودة أو وجود ثغرات حرجة
- بيانات سرية تُقرأ من Key Vault، وإصدارات إنتاج بموافقة تُبدَّل دون توقف للخدمة
نبذة عن الشريك
شريكنا شركة استشارية متعددة الجنسيات تتعامل فرقها مع كميات كبيرة من المستندات وجداول البيانات وقواعد البيانات والبريد الإلكتروني. وأراد الشريك منصة داخلية واحدة تبني فيها هذه الفرق خطوط معالجة البيانات والوكلاء الأذكياء بنفسها، بدلًا من التعاقد على تطبيق جديد لكل حاجة. وكان على المنصة أن تعمل داخل بيئة Microsoft 365 وAzure لدى الشريك، وأن تفصل عمل كل فريق عن غيره، وأن تنقل العمل من مرحلة التجربة إلى بيئة الإنتاج عبر بيئات خاضعة للرقابة. وتتناول دراسة الحالة هذه جزءًا واحدًا من تلك المنصة، وتصف تسع دراسات حالة المنصة كاملة.
التحدي
انحراف البيئات
تجعل الإصدارات اليدوية معرفة ما يعمل في كل بيئة أمرًا صعبًا، وتمر فروق الإعدادات بين البيئات دون أن يلاحظها أحد.
ما يُعاد بناؤه لم يُختبر
بناء صورة جديدة لكل بيئة يعني أن بيئة الإنتاج تشغّل صورة لم تُختبر قط في بيئة ما قبل الإنتاج.
بيانات سرية في غير مكانها
يصعب تغيير بيانات الاعتماد المنسوخة في الملفات أو في متغيرات مسار الإصدار أو في إعدادات التطبيق بصورة دورية، ويسهل تسريبها.
نتائج لا يتصرف أحد بشأنها
التقارير الأمنية التي تكتفي بالتنبيه يسهل تجاوزها عند الدمج.
الأهداف
- البناء مرة واحدة وترقية الصورة نفسها إلى كل بيئة
- منع الدمج الذي يُخفق في الاختبارات أو فحوص الجودة أو الثغرات
- إبقاء البيانات السرية خارج المستودع وخارج إعدادات التطبيق
- اشتراط الموافقة على الإصدار إلى الإنتاج، والإصدار دون توقف للخدمة
- اكتشاف مشكلات التنسيق والتدقيق البرمجي قبل إيداع الشيفرة
دورنا
تولّت كارسنترك القيادة التقنية والبنية المعمارية ضمن فريق هندسي متعدد التخصصات، وأسهمت مباشرة في التنفيذ. بُنيت المنصة على مدى 16 شهرًا، من أكتوبر 2024 إلى يناير 2026، بواجهة خلفية مبنية على Python وFastAPI وتعمل على Azure.
النطاق والجدول الزمني
بُنيت عمليات سير العمل الخاصة بالإصدار والفحص بين ديسمبر 2024 ومارس 2025.
المنهجية
البناء مرة واحدة ثم الترقية
ينتج كل إيداع صورة واحدة موسومة بمعرّف SHA الخاص به. والدمج في الفرع dev يبني الصورة وينشرها في بيئة التطوير. ثم تنقل الترقيةُ الفرعين stage وmain بتقديم سريع (fast-forward) إلى ذلك الإيداع الذي بُني مسبقًا، وتنشر بصمة صورته (digest) بدلًا من بناء صورة جديدة، فما يصل إلى الإنتاج هو تمامًا ما اجتاز بيئة ما قبل الإنتاج.
البوابات حيث تُتخذ القرارات
تعمل اختبارات Pytest وبوابة الجودة في SonarQube وفحص Trivy على كل طلب دمج. ويُمنع الدمج إذا أخفق اختبار، أو أخفقت البوابة، أو ظهرت ثغرة حرجة، وتُجمع نتائج Trivy في تعليق واحد يُحدَّث على طلب الدمج.
البيانات السرية بالإحالة
يحفظ Doppler البيانات السرية لكل بيئة، ويكتبها مزوّد Pulumi مخصص في Azure Key Vault. ويقرؤها App Service عبر مراجع Key Vault، فلا تُحفظ البيانات السرية أبدًا في الشيفرة، ولا تحمل إعدادات التطبيق إلا المراجع.
التنفيذ
فحوص الإيداع
تُجري خطافات ما قبل الإيداع التدقيق والتنسيق على الشيفرة المعدّلة فقط، وتفحص ملفات YAML والمسافات الزائدة في نهايات الأسطر والملفات الكبيرة. وتُعاد الفحوص نفسها في CI، فتخطّيها محليًا لا يعني تخطّيها.
البناء
يبني كل إيداع صورة Docker واحدة، توسم بمعرّف SHA الخاص به وتُرفع إلى Azure Container Registry.
النشر
تنشر مهمة مصفوفية (matrix job) الصورة على تطبيقَي الويب الخاصين بواجهة API في كل بيئة. وفي الإنتاج تنشرها في خانة ما قبل الإنتاج (staging slot)، وتنتظر الموافقة في بيئة GitHub، ثم تبدّل الخانة إلى الإنتاج دون توقف للخدمة.
الأدوات والتقنيات
| الأداة | الغرض |
|---|---|
| GitHub Actions | عمليات سير العمل للبناء والاختبار والفحص والنشر |
| Docker | صور التطبيقات |
| Azure Container Registry | تخزين الصور، موسومة حسب الإيداع |
| Azure App Service | الاستضافة مع خانات النشر |
| Doppler وAzure Key Vault | البيانات السرية لكل بيئة، تُقرأ بالإحالة |
| Pytest | اختبارات على كل طلب دمج |
| SonarQube | بوابة جودة الشيفرة |
| Trivy | بوابة الثغرات |
| pre-commit | الفحوص المحلية |
ما تم تسليمه
- بناء لكل إيداع
- 1
- بيئات
- 3
- بوابات دمج
- 3
- إصدارات الإنتاج
- بموافقة
- صورة واحدة لكل إيداع، تُرقّى عبر ثلاث بيئات
- منع الدمج عند إخفاق الاختبارات أو بوابة الجودة أو وجود نتائج حرجة
- بيانات سرية تُقرأ من Key Vault بالإحالة
- إصدارات إنتاج بموافقة، تُبدَّل دون توقف للخدمة
لماذا يهم ذلك
انضباط الإصدار أقل كلفة حين يُرسى مبكرًا. فالبناء مرة واحدة، وترقية الصورة المختبرة، وترك الفحوص تمنع الدمج، أمور تُبقي المنصة المتنامية قابلة للتوقع.
إذا كانت مؤسستكم تخطط لمنصة من هذا النوع، أو تحتاج إلى تصميم جزء محدد منها وتسليمه، يسعدنا أن نناقش ذلك معكم.