UPD: الجزء الثاني من المقالة جاهز .مرحبا يا هبر! اسمي ألكسندر إزمايلوف. في Badoo ، أقود فريقًا من مهندسي التحرير. أعلم أنه في العديد من الشركات يمكنك إرسال تغييرات التعليمات البرمجية إلى شخص مدرب بشكل خاص ، فهو ينظر إليهم ويضيفهم إلى المكان الذي يجب عليهم (على سبيل المثال ، هذا هو بالضبط ما يحدث مع رمز Git). وأود أن أتحدث عن كيفية أتمتة هذه العملية معنا.
تتكون قصتي من جزئين. في هذا الجزء ، سأتحدث عما أردنا تحقيقه من النظام الجديد ، وكيف بدا في نسخته الأولى ، ولماذا اضطررنا في النهاية إلى إعادة تصميمه. في الجزء الثاني ، سنتحدث عن عملية إعادة تشكيل النظام وعن المكافآت غير المتوقعة التي جلبتها لنا.
الصورة:
المصدرذات مرة في شركتنا ، يمكن للجميع إجراء تغييراتهم مباشرة على الفرع الرئيسي ووضعها بأيديهم. للقيام بذلك ، كتبنا أداة MSCP خاصة عملت بشكل بدائي تمامًا: لقد نسخت التغييرات من جهاز إلى آخر وتعيين الحقوق اللازمة.
مع مرور الوقت ، نمت الشركة - وكان علينا أن نفكر في أتمتة العمليات ، بما في ذلك عملية وضع التغييرات الصغيرة. لذا توصلنا إلى فكرة إنشاء نظام رقعة. بادئ ذي بدء ، أردنا أن يسمح لأي مطور بإرسال تغييراته إلى Git ووضعها على الخوادم. من جانبنا ، طالبنا بأن يطلع مطور آخر على التغييرات وأن تكون مرتبطة بالمهمة من نظام تتبع الأخطاء (نستخدم Jira).
جامع التصحيح 6000يجب أن أقول أن هذه المتطلبات لم تروق لجميع المطورين. بدا لنا أن قضاء بضع دقائق على إنشاء مهمة ليس شيئًا ، ولكن بالنسبة لنا هذا يعني استخدامًا أكثر تعمدًا للنظام. لكن المطورين بدأوا في المقاومة ، بحجة أن وضع التغييرات يستغرق عدة مرات أقل من إنشاء تذكرة جديدة. ونتيجة لذلك ، لا يزال لدينا مهام "عالمية" ، يتم إرفاق مئات التصحيحات بها.
بالإضافة إلى ذلك ، تم تصميم النظام بهدف إصلاح المشكلات العاجلة ، وقد يكون من الصعب العثور على مراجع لمراجعة التصحيح في الثالثة صباحًا.
ماذا نحتاج؟
نعم ، مجرد ضوء في النافذة ... يمكن تقسيم مشكلتنا إلى جزأين: كنا بحاجة إلى طريقة ما لقبول التغييرات في المستودع وطريقة لوضع هذه التغييرات.
لقد قررنا السؤال الأول بسرعة كافية: لقد صنعنا نموذجًا كان علينا إرفاق التغييرات به وتوضيح التفاصيل (المراجع والمهمة).
في الصفحة الثانية ، يمكنك رؤية التغييرات أو رفضها أو قبولها.
بعد التأكيد ، سقطت التغييرات في سيد.
السؤال الثاني: كيف يمكن تسليم هذه التغييرات إلى الخوادم بسرعة؟ اليوم ، يستخدم الكثيرون التكامل المستمر ، ويمكنه أن يؤدي المهمة بشكل جيد إذا لم يستغرق بناء وتخطيطنا "الصادق" الكثير من الوقت.
التجمع العادل
كان مجلسنا دائمًا معقدًا للغاية. كان المبدأ العام هو: في دليل منفصل ، قمنا بوضع الملفات كما هي على خوادم الوجهة ؛ ثم حفظنا هذه الحالة في لقطة (لقطة من نظام الملفات) ووضعناها.
نضع كود PHP في الدليل ، الذي أخذناه من المستودع كما هو ، وأضفنا الملفات التي تم إنشاؤها (على سبيل المثال ، القوالب والترجمات) إليه. وضعنا الإحصائيات بشكل منفصل. هذه عملية معقدة إلى حد ما ، ويمكنك تخصيص مقال كامل لها ، ولكن نتيجة لذلك ، كان لدينا خريطة إصدار لإنشاء روابط ملفات للمستخدمين الذين تركوا مع الكود الرئيسي.
بعد ذلك ، يجب حفظ حالة الدليل في مكان ما. للقيام بذلك ، استخدمنا
جهاز كتلة ، والذي أطلقنا عليه حلقة. تم نسخ الدليل بأكمله إلى جهاز فارغ ، ثم تم أرشفته وتسليمه إلى خوادم "رئيسية" منفصلة. من هذه الخوادم أخذنا أرشيفًا في عملية التخطيط. كان حجم كل أرشيف 200 ميجابايت ، وعند فتحه ، كانت الحلقات تزن 1 جيجابايت. استغرق بنا حوالي خمس دقائق للبناء بدون ثابت.
تخطيط عادل
في البداية كنا بحاجة إلى تسليم الأرشيف إلى خوادم الوجهة. لدينا الآلاف منهم ، لذلك كان سؤال التسليم بالنسبة لنا دائمًا مشكلة كبيرة: لدينا العديد من المنصات (مراكز البيانات) ، وعلى "الخوادم" الأكثر سمكًا التي تحتوي على رمز. في محاولات تحقيق أداء أفضل (الحد الأدنى من الوقت والموارد) ، جربنا طرقًا مختلفة: من SCP بسيط إلى السيول. في النهاية ، استقرنا على استخدام UFTP. كانت الطريقة سريعة (في الطقس الجيد - دقيقة) ، ولكن للأسف ، لم تكن خالية من المشاكل. بشكل دوري ، حدث شيء ما ، وكان علينا أن نركض للمشرفين والشبكات.
بعد أن وجد الأرشيف (بطريقة أو بأخرى) نفسه على الخوادم ، يجب تفكيكه ، وهو ليس مجانيًا أيضًا. يبدو هذا الإجراء مكلفًا بشكل خاص إذا كنت تتذكر أنه يتم تنفيذه آلاف المرات ، وإن كان بالتوازي على أجهزة مختلفة.
لا يوجد تجميع
لذلك ، استغرق نشر التغييرات بصراحة الكثير من الوقت ، وكانت سرعة التسليم مهمة جدًا لنظام التصحيح ، لأنه كان من المفترض أنها ستستخدمها عندما لا يعمل شيء ما. لذلك ، عدنا إلى فكرة استخدام MSCP: سريع وسهل التنفيذ. وبالتالي ، بعد ظهور التغييرات في المعالج ، كان من الممكن في صفحة منفصلة تحليل الملفات التي تم تغييرها بدورها.
إنه حي
يعمل النظام. على الرغم من بعض عدم الرضا عن الأشياء الصغيرة ، يمكن للمطورين القيام بعملهم ، ولهذا لم يكونوا بحاجة إلى الوصول إلى السيد أو الوصول إلى الخوادم.
ولكن ، بالطبع ، مع طريقة التخطيط هذه ، كانت لدينا مشاكل. كان بعضها متوقعًا ، بل قررنا البعض بطريقة أو بأخرى. كان معظمها متعلقًا بتحرير الملفات بالتوازي.
تصحيح واحد لملفات متعددة
مثال لمشكلة يمكن التنبؤ بها. تم وضع ملفات جديدة بدورها. ماذا تفعل إذا كنت بحاجة إلى تغيير عدة ملفات والتغييرات المتعلقة بها؟ على سبيل المثال ، أريد إضافة طريقة جديدة في ملف واحد واستخدامها على الفور في ملفات أخرى. طالما لا يوجد استرجاع باستخدام الأساليب (انظر
التكرار المتبادل ) ، يكفي تذكر ترتيب تخطيط الملف الصحيح.
قرار صادقلحل المشكلة ، كنا بحاجة إلى استبدال العديد من الملفات تلقائيًا. في حالة ملف واحد ، يكون الحل معروفًا: تحتاج إلى استخدام إعادة تسمية عملية الملف. لنفترض أن لدينا ملف F ، ونحتاج إلى استبدال محتوياته. للقيام بذلك ، قم بإنشاء ملف TMP ، واكتب المعلومات اللازمة إليه ، ثم قم بإعادة تسمية TMP F.
دعونا نعقد المهمة. لنفترض أن لدينا دليل D ، ونحتاج إلى استبدال محتوياته. لن تساعدنا عملية إعادة التسمية ، لأنه لا يمكن استبدال دليل غير فارغ. ومع ذلك ، هناك حل بديل: يمكنك استبدال دليل D مسبقًا بما يسمى ارتباط رمزي (ارتباط رمزي). بعد ذلك ، سيقع المحتوى نفسه في مكان آخر ، على سبيل المثال ، في الدليل D_1 ، وسيكون D رابطًا إلى D_1. في الوقت الذي يُطلب فيه استبدال ، تتم كتابة المحتوى الجديد إلى دليل D_2 ، حيث يتم إنشاء ارتباط TMP جديد. ستعمل إعادة تسمية TMP D الآن لأنه يمكن تطبيق هذه العملية على الروابط.
يبدو هذا الحل مناسبًا: يمكنك تغيير الدليل بأكمله باستخدام الرمز ، ونسخ الملفات القديمة وكتابة ملفات جديدة في الأعلى. المشكلة هي أن نسخ كل الكود طويل ومكلف. يمكنك استبدال الدليل الفرعي فقط حيث تم تغيير الملفات ، ولكن بعد ذلك يجب أن تكون جميع الأدلة الفرعية بالرمز روابط ، لأنه لا يمكننا استبدال الدليل المعبأ بأي شيء أثناء عملية التخطيط. لا يبدو هذا الحل معقدًا للغاية فقط - يجب أن تتذكر إضافة بعض القيود حتى لا تتمكن العمليتان من تغيير نفس الدليل أو الدليل في نفس الوقت وأدلةه الفرعية.
ونتيجة لذلك ، لم نتمكن من العثور على حل تقني ، لكننا اكتشفنا كيفية تبسيط الحياة قليلاً: لقد قمنا بتصميم العديد من الملفات بإجراء واحد في الواجهة. حدد المطور تخطيط الملفات ، وقام النظام بتسليمها.
تصحيحات متعددة لكل ملف
سيكون الأمر أكثر صعوبة إذا كان هناك ملف واحد ، وهناك العديد من المطورين الذين يريدون تغييره. قمنا بتطبيق التصحيح الأول ، لكننا لم نحلله. عند هذه النقطة ، يصل التصحيح الثاني ويطلب منه أن يتحلل. ماذا تفعل أكثر إثارة للاهتمام ، إذا تم تطبيق التصحيح الثاني ، وفي هذه اللحظة يُطلب منا تحليل الأول.
ربما ، نحتاج إلى توضيح أننا دائمًا نرسم أحدث إصدار فقط من المعالج. خلاف ذلك ، يمكن أن تنشأ مشاكل أخرى. على سبيل المثال ، وضع النسخة القديمة فوق النسخة الجديدة.
لم نتوصل إلى حل جيد لهذه المشكلة. أظهرنا للمطورين الفرق بين ما يخططونه وما هو موجود على الآلات في وقت معين ، لكن هذا لم ينجح دائمًا. على سبيل المثال ، قد يكون هناك الكثير من التغييرات ، وقد يكون المطور في عجلة من أمره أو يكون كسولًا فقط (يمكن أن يحدث أي شيء).
الكثير من التصحيحات ، ويغير الجميع نفس الملفات
هذا هو الخيار الأسوأ الذي لا تريد التفكير فيه. إذا أثرت تغييرات العديد من المطورين على العديد من نفس الملفات ، فلن يتمكن نظام التصحيح لدينا من المساعدة بشكل خاص - فقد ظل يعتمد على انتباه المطورين وقدرتهم على التواصل مع بعضهم البعض. ولكن من الناحية النظرية ، من الممكن تمامًا الحصول على "سمكة" عندما يكون هناك ، في أي مرحلة من مراحل التخطيط ، كود مكسور جزئيًا.
الصورة:
المصدرمشاكل الحديد
نشأت مشكلة أخرى عندما أصبح أحد الخوادم غير متاح لسبب ما. كانت لدينا آلية لاستبعاد مثل هذه الخوادم من التخطيط ، والتي عملت بشكل جيد ؛ ظهرت الصعوبات بعد عودتهم إلى العمل. والحقيقة هي أن إصدارات التكوين والرمز على الخوادم العاملة يتم التحقق منها معنا (هناك قسم مراقبة كامل!) ، ونتأكد من أن جميع الإصدارات محدثة عندما يعود الخادم للعمل. ولكن لم يكن لدينا أي إصدارات من التصحيحات - قمنا فقط بنسخ ملفات جديدة إلى الرمز الحالي.
لم نتوصل إلى طريقة دقيقة لإصدار البقع المتحللة ، لكننا حاولنا حل المشكلة عن طريق الحلول. على سبيل المثال ، rsync من جهاز مجاور في نهاية عملية التخطيط. ولكن بطريقة ما لم نتمكن من التحقق بطريقة ما.
لقد راجعنا عدة حلول لهذه المشكلة ، على سبيل المثال ، أردنا تطبيق التصحيحات على الخوادم "الرئيسية" أيضًا (من المهم أن نتذكر أننا نقوم بنشر الإصدار المعبأ ، أي أننا بحاجة إلى تطبيق التصحيح وحزم الإصدار مرة أخرى) ، ولكن كان من الصعب جدًا تنفيذه.
ملعقة عسل
ولكن ، بالإضافة إلى المشاكل ، كانت هناك جوانب إيجابية.
أولاً ، اكتشف المطورون بسرعة أنه ، بالإضافة إلى إصلاح الأشياء ، بمساعدة نظام التصحيح ، يمكنك أحيانًا تحميل وظائف جديدة ، على سبيل المثال ، عندما تحتاج إليها بشكل عاجل. كما هو الحال في أي شركة ، لدينا قوة قاهرة. ولكن إذا كان علينا في وقت سابق إنشاء بنية استثنائية ، حيث تم تشتيت المختبرين ومهندسي الإصدار ، فيمكن للمطور الآن تحليل بعض التغييرات بمفرده.
ثانيًا ، لم تعد هناك حاجة إلى شخص مميز لديه حقوق لإصلاح شيء ما. يمكن لأي مطور بنفسه أن ينشر تعديلاته. لكن هذا ليس كل شيء: أصبحت البنيات بشكل عام أسهل ، والآن تم تقسيم المشاكل إلى حرجة وتلك التي يمكن إصلاحها باستخدام التصحيحات. هذا جعل من الممكن التراجع في كثير من الأحيان واتخاذ قرار أسرع حول ما إذا كنا ناجحين.
ببساطة ، أحببنا النظام واكتسبنا شعبية. واصلنا محاولة تحسينه ، ولكن مع المشاكل الموصوفة كان علينا أن نعيش بضع سنوات أخرى. وكيف قررناها ، وكيف يعمل النظام الآن ، وكيف كادنا أن نقتل عطلة رأس السنة الجديدة أثناء عملية التحديث ، سأخبر في الجزء الثاني من المقالة.