معاينة التغييرات باستخدام helm diff

الترقية دون معاينة أمر مقلق. تعرض إضافة helm diff بالضبط ما ستضيفه الترقية أو تغيّره أو تزيله قبل أن تلمس العنقود. 👀

بخلاف lint أو template، تأتي helm diff على شكل إضافة مجتمعية. تثبّتها مرة واحدة، ثم تتصرف مثل أي أمر فرعي أصلي في Helm.

شغّل helm diff upgrade باستخدام اسم الإصدار نفسه و chart الذي تخطط لنشره. فهو يقارن الإصدار الحالي بما ستنتجه البيانات التعريفية الجديدة.

تظهر الأسطر المضافة باللون الأخضر والمحذوفة باللون الأحمر، تماماً كما في مقارنة Git. وسترى فوراً أن وسم الصورة قد تغيّر أو أن عدد النسخ قد تبدّل.

يطبّق helm upgrade العادي التغييرات ويبلغ عن النجاح فقط. أما إضافة diff فتكشف النية أولاً، مما يتيح اكتشاف المفاجآت أثناء المراجعة.

التقط ناتج diff وأرفقه بوصفه تعليق PR. وهكذا يوافق المراجعون على تغيير البنية التحتية الفعلي، لا على تعديل ملف القيم فقط.

استخدم --detailed-exitcode حتى يعيد الأمر رمز خروج خاصاً عند وجود تغييرات. ويمكن لـ CI عندئذٍ أن يشترط إقرار شخص بالتغيير.

يقارن الأمر الفرعي helm diff revision بين مراجعتين محفوظتين لإصدار، مما يتيح لك تدقيق ما تغيّر فعلياً بين عمليتي نشر.

بالنسبة إلى إصدار غير موجود بعد، مرّر --allow-unreleased حتى يتعامل diff مع كل شيء على أنه مضاف حديثاً بدلاً من الإبلاغ عن خطأ.

يضيف Kubernetes حقولاً لا تهمك. استخدم --suppress أو أعلام التطبيع حتى يركّز diff على التغييرات المهمة فقط.

لأنه يحتاج إلى قراءة الإصدار الحالي، يتصل helm diff بالعنقود باستخدام سياق kubeconfig نفسه الذي يستخدمه kubectl و helm.

تريد من CI أن ينبّهك عندما تؤدي الترقية فعلياً إلى تغيير الموارد. ما العلم الذي يساعدك؟

ثبّت إضافة helm diff، ونفّذ diff مع كل ترقية، وأظهر الناتج في طلب السحب. وهكذا تشحن تغييرات رأيتها ووافقت عليها فعلياً. ✅