الخلاصة

  • تحصل بيئة Codespaces على مدة الاحتفاظ عند إنشائها. تعديل سياسة المؤسسة أو حذفها لاحقاً لا يغير المدة الممنوحة للبيئات القائمة.
  • تواصل البيئة المتوقفة استهلاك التخزين، ويجري الحذف الآلي حتى مع وجود تعديلات لم تُرسل إلى المستودع البعيد. خفض التكلفة يحتاج إلى إخراج العمل قبل إخلاء مكانه.

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

هذا مثال افتراضي على تغيير الإعداد. القاعدة نفسها منشورة في وثائق GitHub الخاصة بسياسة الاحتفاظ: تُحدد المدة عند إنشاء البيئة، ولا تتبدل للبيئات القائمة عند تعديل السياسة. حتى حذف السياسة لا يمحو المدد التي سبق تخصيصها.

للقاعدة ميزة واضحة؛ فهي تحافظ على الوقت الذي حصلت عليه بيئة العمل عند إنشائها. ولها ثمن إداري واضح أيضاً: صاحب الميزانية لا يستطيع تكليف إعداد جديد بإخلاء مخزون قديم لم يشمله التغيير.

من يدفع، ومن يبقى؟

تتيح Codespaces الاحتفاظ ببيئة تطوير في السحابة والعودة إليها بعد إيقافها، مع الملفات المحفوظة فيها. هذه الراحة تستهلك مورداً حتى حين لا يعمل المعالج.

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

هكذا يمكن أن تعرض المؤسسة سياسة مقتصدة وأن تحمل في الوقت نفسه عدداً من البيئات بمدد قديمة. لا تناقض في النظام؛ هناك فرق بين شروط الإنشاء وشروط الإقامة التي مُنحت سابقاً.

ثم إن نطاق السلطة يتبع جهة الدفع. سياسة المؤسسة تخص البيئات التي تمولها المؤسسة. امتلاكها للمستودع لا يجعل بيئة يدفع ثمنها المستخدم شخصياً خاضعة للسياسة بمجرد ذلك. وعند الإنشاء تُختار أقصر مدة من القيود المنطبقة، بما فيها إعدادات المؤسسة والمستودع والمستخدم.

لذلك يحتاج الجرد إلى أكثر من أسماء المستودعات: من يدفع لكل بيئة، وما المدة المخصصة لها فعلاً؟ الوثائق العامة لا تعرض قائمة بيئات عميل بعينه أو مددها أو العمل غير المرسل فيها أو فاتورته؛ وحساب الوفر أو الخسارة يحتاج إلى تلك البيانات. أما سبب بقاء موارد قديمة بعد تعديل السياسة، فقد شرحته القاعدة بالفعل.

ساعة الحذف لا تعرف قيمة المسودة

حفظ ملف داخل البيئة يضعه على الآلة الافتراضية. إيداع التعديلات ثم دفعها إلى المستودع البعيد خطوة أخرى. قد يرى المطور عمله محفوظاً، بينما يظل وجوده معلقاً ببقاء تلك الآلة.

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

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

لهذا قد تبقى بيئة أقدم من بيئة أخرى ثم تُحذف الأحدث أولاً. الأولى عادت إليها يد مستخدم فأعادت تشغيل عدادها، والثانية أخذت مدة أقصر. كما تسمح بعض البيئات الشخصية بخيار إبقائها حتى الحذف اليدوي، مع استمرار استهلاك التخزين. هذا الخيار غير متاح لبيئات المؤسسة التي تخضع لسياسة احتفاظ مؤسسية.

تاريخ الإنشاء، والمدة الممنوحة، وآخر نشاط، ثلاث معلومات مختلفة. اختصارها في خانة واحدة يريح التقرير ويضعف قرار التنظيف.

الباب الذي يخرج منه العمل

توفر GitHub وسيلة لتصدير التغييرات إلى فرع من دون تشغيل البيئة. وقد تنفع عندما يمنع حد الإنفاق إعادة فتحها. لكن التصدير يشمل الفرع المحدد حالياً فقط، ولا يحمل معه الفروع الأخرى. كذلك تمنع الملفات الأكبر من 100 MiB عملية الدفع المعنية والتصدير المرتبط بها.

النتيجة العملية أن نجاح الضغط على التصدير ليس نهاية التسليم. ينبغي فحص محتوى الفرع في وجهته، وتحديد ما بقي من عمل مستقل في الفروع الأخرى، ومعرفة طريقة إعادة بناء بيئة التطوير. نقل فرع له نطاق معلوم؛ الورشة بكاملها قد تحتوي على أشياء أخرى.

يمكن عندئذ اتخاذ قرار اقتصادي مفهوم: هل يستحق هذا المشروع الاحتفاظ ببيئة جاهزة للعودة، أم يكفي إخراج نتائجه وإخلاء المساحة؟ السياسة الجديدة تنظم ما سيُنشأ لاحقاً. الإجابة عن هذا السؤال لكل بيئة قائمة هي التي تجعل التقشف يصل إلى المخزن.