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