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