سلسلة رحلة التطوير (1) : تجهيز بيئة التطوير – المبدأ أولًا

كمطورين، أعتقد أن كثيرًا منا مرّ بمرحلة إعداد بيئة التطوير (Development Environment) على جهازه قبل البدء بالبرمجة

(تحميل أطر العمل Frameworks، إعداد متغيرات البيئة Environment Variables، تحميل المكتبات المطلوبة Libraries، التأكد من الإصدارات Versions، وحل التعارضات بين الأدوات القديمة والجديدة، إلخ).

وإذا كان المشروع يضم أكثر من مطور، فإن كل واحد منهم يمر بالتجربة نفسها.

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

في أحد الفيديوهات المنشورة لأحد موظفي GitHub، يذكر أن أفضل يوم يمر عليه كمطور هو اليوم الذي يستلم فيه جهازًا جديدًا — لأنه نظيف.

لكن من جهة أخرى، يعتبره أسوأ يوم، لأنه يعرف أن أمامه ساعات، وربما أيام، وهو يثبت أطر العمل، والمكتبات، والخدمات، ويضبط الإعدادات من جديد.

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

واستطراداً في هذا الموضوع -من زاوية أخرى- يتجه كثير من المطورين إلى ربط مشاريعهم في بيئة التطوير بالخدمات المساندة الموجودة في بيئة الاختبار (Test Environment)، لعدم توفر صلاحية الوصول إليها في بيئاتهم التطويرية.

فعلى سبيل المثال: خدمة A تعتمد على خدمة داخلية B و خدمة خارجية تابعة لإدارة أخرى C وقاعدة بيانات D

• قد يقوم مسؤول قواعد البيانات (Database Admin) بإعداد قاعدة البيانات D (Database) على جهازه ثم رفعها إلى بيئة الاختبار، ويتاح للخدمة المستفيدة A الوصول فقط للبيئة الاختبارية لقاعدة البيانات D - وليس البيئة التطويرية لها

• أو يطوّر مطور الخدمة B (Service B) على جهازه ، ثم ينشرها على بيئة الاختبار , بالتالي الخدمة المستفيدة A تصل لها في بيئة الاختبار فقط

ونتيجة لذلك، لا يمكن الوصول إلى الخدمة X من بيئة التطوير — لأنها موجودة على جهازه — ولا يكون الوصول إليها ممكنًا إلا عبر بيئة الاختبار.

قد يكون هذا الحل ضروريًا في بعض الحالات، لكن إذا أدخل المطور أثناء الاختبارات الأولية (Initial Testing) بيانات إضافية أو تجريبية، فإن ذلك يؤثر على بيئة الاختبار، وقد يسبب مشكلات لفريق الاختبار (QA Team) بسبب تغيّر البيانات لديهم.

وبذلك تختلط بيانات التطوير مع بيئة يُفترض أن تكون مخصصة للاختبار فقط.

القاعدة الذهبية هنا هي:

لكلٍ من التطوير والاختبار غاية مختلفة، ولا ينبغي أن يكون بينهما اعتماد متبادل. Development and testing serve different purposes and must not depend on each other.

.هذه القاعدة تعكس فصلًا واضحًا بين مرحلتين لكلٍ منهما هدف مختلف:

فالتطوير (Development) هو مساحة للتجربة والتغيير السريع، بينما الاختبار (Testing) هو مرحلة للتحقق والاستقرار. وعندما تعتمد إحداهما على الأخرى، تختلط الأدوار، وتفقد كل بيئة هدفها الأساسي.وللتعمق أكثر في هذا المفهوم، يُنصح بالاطلاع على معيار ISO/IEC 27001 والذي يُعد مرجعًا عالميًا في حوكمة وأمن الأنظمة.

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

بمعنى آخر، المعيار لا ينظر إلى بيئة الاختبار كخدمة مشتركة يمكن البناء عليها، بل كمرحلة تحقق مستقلة ضمن خط الانتقال الطبيعي للأنظمة من Dev → Test → Prod، وهو ما يدعم هذه القاعدة الذهبية بشكل مباشر.

طيب، إذا كانت بيئتك الحالية مثل الموضّح في الصورة — خدمة في بيئة التطوير (Service A – Dev) تعتمد على خدمات موجودة في بيئة الاختبار — فماهو الحل ؟

الإجابة تعتمد على نوع الاعتماد نفسه. أحد الاحتمالات العملية هو أن تكون بعض الخدمات متاحة بنسخة تطويرية، بينما خدمات أخرى لا. في هذا السيناريو، يمكن أن تكون Service B متوفرة في بيئة Dev ويمكن الربط معها مباشرة، بينما Service C خدمة خارجية، وقد يكون من الصعب إلزام الفريق المسؤول عنها بتوفير وصول لبيئة تطويرية، أو ربما لا توجد

لديهم بيئة تطوير أصلًا.

في هذه الحالة، يكون الحل العملي هو إنشاء Mock لـ Service C داخل بيئة التطوير.

وبذلك تصبح الصورة كالتالي:Service A (Dev) تعتمد على Service B (Dev)، وعلى Mock Service C (Dev)، مع استخدام Database D (Dev) فقط. هذا الأسلوب يحقق فصلًا واضحًا بين بيئة التطوير والاختبار، ويمنح المطور حرية التجربة دون التأثير على فرق أخرى، وفي الوقت نفسه يخفف الاعتماد على بيئات لا يفترض البناء عليها من الأساس.

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