بيئة النشر

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

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

تهدف بيئة الاختبار إلى تمكين المختبرين البشريين من اختبار التعليمات البرمجية الجديدة والمعدلة باستخدام عمليات فحص آلية أو تقنيات يدوية. بعد أن يقبل المطور التعليمات البرمجية الجديدة والتكوينات من خلال اختبار الوحدات في بيئة التطوير، تُنقل العناصر إلى بيئة اختبار واحدة أو أكثر. ^{[ 3 ]} في حال فشل الاختبار، تستطيع بيئة الاختبار إزالة التعليمات البرمجية المعيبة من منصات الاختبار، والتواصل مع المطور المسؤول، وتوفير سجلات مفصلة للاختبار والنتائج. إذا اجتازت جميع الاختبارات بنجاح، تستطيع بيئة الاختبار أو إطار عمل التكامل المستمر الذي يتحكم في الاختبارات ترقية التعليمات البرمجية تلقائيًا إلى بيئة النشر التالية.

تتطلب أنواع الاختبارات المختلفة بيئات اختبار متنوعة، بعضها أو كلها يمكن محاكاتها افتراضياً ^{[ 4 ]} لإجراء اختبارات سريعة ومتوازية. على سبيل المثال، قد تُجرى اختبارات واجهة المستخدم الآلية ^{[ 5 ]} عبر عدة أنظمة تشغيل وشاشات افتراضية (حقيقية أو افتراضية). قد تتطلب اختبارات الأداء تكوينًا أساسيًا موحدًا للأجهزة المادية، بحيث يمكن مقارنة نتائج اختبار الأداء بمرور الوقت. قد تعتمد اختبارات التوافر أو المتانة على محاكيات الأعطال في الأجهزة والشبكات الافتراضية.

قد تكون الاختبارات متسلسلة (واحدة تلو الأخرى) أو متوازية (بعضها أو كلها في آن واحد) حسب مدى تطور بيئة الاختبار. يتمثل أحد الأهداف الرئيسية لمنهجيات تطوير البرمجيات الرشيقة وغيرها من ممارسات تطوير البرمجيات عالية الإنتاجية في تقليل الوقت المستغرق من تصميم البرمجيات أو تحديد مواصفاتها إلى تسليمها في بيئة الإنتاج. ^{[ 6 ]} تُعد بيئات الاختبار المؤتمتة والمتوازية بدرجة عالية من العوامل المهمة في تسريع عملية تطوير البرمجيات.

بيئة ما قبل الإنتاج هي بيئة اختبار تحاكي بيئة الإنتاج بدقة. ^{[ 7 ]} وهي تسعى إلى محاكاة بيئة الإنتاج الفعلية بأكبر قدر ممكن من الدقة، وقد تتصل بخدمات وبيانات إنتاجية أخرى، مثل قواعد البيانات. على سبيل المثال، تُشغَّل الخوادم على أجهزة بعيدة، بدلاً من تشغيلها محليًا (كما هو الحال على محطة عمل المطور أثناء التطوير، أو على جهاز اختبار واحد أثناء الاختبار)، مما يختبر تأثيرات الشبكة على النظام.

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

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

تستخدم بعض المؤسسات أيضًا بيئة الاختبار لمعاينة الميزات الجديدة لعملاء محددين أو للتحقق من صحة عمليات التكامل مع الإصدارات الحية من التبعيات الخارجية.

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

يُعدّ نشر النظام في بيئة الإنتاج الخطوة الأكثر حساسية؛ ويمكن إجراؤها إما بنشر الكود الجديد مباشرةً (باستبدال الكود القديم، بحيث لا توجد سوى نسخة واحدة في كل مرة)، أو بنشر تغيير في الإعدادات. ويمكن أن يتخذ هذا أشكالًا مختلفة: نشر تثبيت متوازٍ لإصدار جديد من الكود، والتبديل بينهما بتغيير في الإعدادات؛ أو نشر إصدار جديد من الكود مع السلوك القديم وعلامة ميزة ، والتبديل إلى السلوك الجديد بتغيير في الإعدادات يُفعّل العلامة؛ أو بنشر خوادم منفصلة (أحدها يُشغّل الكود القديم، والآخر يُشغّل الجديد) وإعادة توجيه حركة البيانات من القديم إلى الجديد بتغيير في الإعدادات على مستوى توجيه حركة البيانات. ويمكن تنفيذ كل هذه الخطوات دفعة واحدة أو تدريجيًا على مراحل.

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

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