في هذه المقالة ، أود أن أشارك تجربتي في كيفية حل مشكلة "تجميد" المهام في شركتنا.
أعمل في شركة ناشئة ، مثلها مثل جميع الشركات الناشئة ، تشهد مرحلة نمو من 10 أشخاص قبل عام إلى 35 شخصًا اليوم ، وزاد عدد المبرمجين خلال هذا الوقت من 5 إلى 25 شخصًا وجاء معظمهم في الأشهر الستة الماضية.
هيكل الشركة ، على الرغم من شبابها ، أود أن أسميه الطراز القديم ، حيث لم يشارك أحد في عمليات البناء. مع النمو ، انقسمنا إلى فريق تطوير وفريق اختبار وفريق devops ، وعمل كل شيء أكثر أو أقل.
كانت عملية التطوير ، إذا كان يمكن تسميتها "عملية" ، كما يلي:
انتهى عمل المطوّر بمجرد اجتياز الكود لمراجعة الكود ورهنه قيد التطوير.
انتهى عمل الفاحص عندما اختبر و smerzhil في الفرع الرئيسي.
ينقر Devops أحيانًا على الزر "Deploy to Prod" ، بعد أن قال مدير المشروع اليومي: "لم يتم نشرها لفترة طويلة ، ربما سيتم إلغاؤها اليوم؟"
ما جيد:
- تتم مزامنة الكثير من الأتمتة ، على سبيل المثال ، الحالات في جيرا مع تسميات فرعية في GitLab ، يتم إغلاق مهمة في جيرا بعد النشر إلى prod ، يتم نشر الرمز تلقائيًا لاختبار البيئات المرحلية والتدريج مع دمج في التطوير والماجستير ، على التوالي.
- يتم تغطية كل شيء صعودا وهبوطا مع الاختبارات.
- المبرمجين كتابة خطط الاختبار أنفسهم واختبار الوظيفة الرئيسية.
المشاكل:
- يمكن للمختبرين ألا يفعلوا شيئًا لمدة أسبوع ، لأن شنق المهام في الحالة code_review. في نهاية الأسبوع ، لا يزال المبرمجون يقومون بهذا الاستعراض ، وفي يوم الاثنين ، يكون لدى المختبرين الكثير من العمل.
- لأنه بعد مراجعة الشفرة ، يتم إصلاح كل شيء في التطوير وإذا كان هناك شيء ما يحتوي على خطأ ، فلا يمكننا نشر أي شيء. بينما يقوم أحد مطوري البرامج بإصلاح هذا الخطأ ، إلا أن الآخر قد ينتن ميزة أخرى تحتوي أيضًا على خطأ. وبسبب هذا ، اعتدنا على الانتظار لمدة أسبوع أو أسبوعين حتى يستقر هذا الغداء ويكون لدى المختبر الوقت لدوسه بشكل رئيسي قبل أن يلتزم أحد المطورين بشيء آخر لتطويره.
- نشر الميزات في حزم كبيرة ، مما يضيف مخاطر إلى اختبار أو التقاط شيء أثناء النشر بشكل سيئ.
سوف أصف حالتين أوضحت لنا أنه من المستحيل العمل أكثر.
لذلك ، على سبيل المثال ، في أحد أيام الجمعة ، كان لدينا 15 وجبة خفيفة في كود الحالة_العرض ، وفي يوم الاثنين قاموا جميعًا بتغيير الحالة إلى ready_for_test. وقال اختبار لصحيفة ديلي كم هم يحبوننا. ولمدة ثلاثة أشهر لم نتمكن من بيع ، لأسباب مختلفة ، عدة ميزات كبيرة إلى حد ما.
بادئ ذي بدء ، اكتشفنا الكثير من code_review. اتضح أنه يمكن حل هذه المشكلة بكل بساطة بفضل القواعد التالية:
- يمكن أن تكون ثلاث مهام فقط في حالة code_review. هذه هي القاعدة الأكثر أهمية التي لا يمكن انتهاكها.
- إذا كان المبرمج قد انتهى من التطوير وأراد ترجمة المهمة إلى code_review ، فإنه يتطلع إلى معرفة ما إذا كان يمكنه القيام بذلك (راجع القاعدة 1).
- إذا كانت هناك بالفعل ثلاث مهام في معاينة الحالة code_review ، فسيساعد أولاً زميله في مراجعة الكود. وإذا كان في عملية المراجعة تعليقات أو اقتراحات للتغيير ، فحينئذٍ يقوم بالاقتران مع البرمجة مع زميل له يقوم بمراجعته.
الفكرة الرئيسية هي عدم السماح للتجميد بالتشفير عندما يكون مكتوبًا بالفعل ، وتزويد المختبرين بتدفق متساوٍ للعمل لمدة أسبوع.
قمنا بتنفيذ هذا في غضون ساعة واحدة: التقينا ، وناقشنا وذهبنا لإجراء مراجعة ونقوم بالبرمجة المزدوجة.
إذا حدث أن أحدهم نسي (وأحيانًا نسي شخص ما بالضرورة) القاعدة الأولى ، فحينئذٍ تنتقل العبارة "لدينا أكثر من 3 علاقات عامة في code_review" إلى غرفة الدردشة على الفور. دعنا نراجع !!! في الوقت نفسه ، لا يوجد شخص مميز يضمن عدم وجود أكثر من ثلاثة طلبات سحب ، ويتم ذلك بواسطة المطورين أنفسهم.
على الرغم من أن هذه التغييرات حالت دون تجميد المهام ، إلا أننا لا نزال نواجه مشكلات في عمليات النشر وتسرب الأخطاء في التطوير. نظرًا لأننا بعد مراجعة الكود ، تم دمجنا دائمًا في فرع التطوير ، وتم نشره تلقائيًا في بيئة الاختبار للاختبار.
كان هذا الحل نوعًا من الإصلاحات العاجلة ، ثم كان من الضروري إجراء تغييرات أساسية على العمليات.
الشيء الرئيسي الذي قررنا القيام به هو تحريك مجالات المسؤولية. الآن ليس لدى الشركة فريق تطوير منفصل ، أو فريق اختبار ، أو فريق devops ينقل المهام إلى بعضهم البعض ويكون مسؤولاً فقط عن جانبهم.
قمنا بتنظيم المطورين في عدة فرق: واحد لكل عميل ، نظرًا لأن لدينا منتجًا رئيسيًا ، ولكن تم تخصيصه لكل عميل لفترة طويلة إلى حد ما (نحن مزيج من شركة منتج وخدمة). الآن شحن الميزات إلى prod هي مسؤولية الفريق. لا توجد فرق اختبار مألوفة و devops ، ولكن هناك QA كخدمة ، و DevOps كخدمة.
ضمان الجودة كخدمة هو فريق لا يختبر ، لكنه يضمن جودة المنتجات. يساعد مهندسو ضمان الجودة المطورين في كتابة خطط الاختبار والمشاركة في جلسات الاختبار. لذلك قمنا بتحريرهم من الاختبار اليدوي ، وكان لديهم وقت لكتابة اختبارات نهاية إلى نهاية وتطوير أدوات للمساعدة في الاختبار. نحن أيضا تنفيذ نظام الرصد.
DevOps كخدمة هي فريق يقوم بتطوير البرامج النصية للنشر ، ويدعم عمل بيئات الاختبار ، ويقوم بأتمتة العديد من المهام.
عملية التطوير الجديدة هي:
- هناك مهمة ، من العميل ، مدير المنتج أو أحد القمم.
- في مرحلة التخطيط السريع ، نأخذها في التطوير.
- يقوم المطور بكتابة الكود في فرع منفصل للمهمة وعند الانتهاء من ترجمته إلى الحالة code_review.
- أحد الزملاء يقوم بمراجعة.
- عندما تنجح المهمة في المراجعة ، يندمج المطور في الفرع مع المهمة وكل شيء ملتزم بتطويره وينشر هذا الفرع في بيئة الاختبار.
- ثم يخطط لحشد نسميه جلسة اختبار ويدعو مهندس ضمان الجودة وزملائه إليه إذا لزم الأمر.
- يقوم مهندس ضمان الجودة بفحص خطة الاختبار وتحسينها قبل جلسة الاختبار.
- في جلسة الاختبار ، يمر المطور عبر خطة الاختبار بالكامل كعرض توضيحي. في بعض الأحيان تنقسم خطة الاختبار إلى أجزاء ثم نختبرها بالتوازي. الشيء الرئيسي هو أن يتم ذلك معًا في غرفة منفصلة للاجتماعات.
- إذا لم يتم العثور على الأخطاء بعد اختبارها ، عندها يقوم المطور بدمج الكود الخاص به في فرع التطوير وعلى الفور في الفرع الرئيسي (هذا شيء لم نتغيره بعد ، حيث لا نزال بحاجة إلى تحديث البرامج النصية للنشر). في المستقبل نخطط لمغادرة الفرع الرئيسي فقط.
- بعد ذلك ، يبدأ المطور عملية النشر على مراحل ، فقط للتحقق من أن النشر لا يزال يعمل على بيئة مماثلة للمنتج.
- إذا كان كل شيء على ما يرام ، ثم نشر على الفور إلى همز. يتم اتخاذ قرار النشر أو عدمه بواسطة فريق التطوير ، لكن ضمان الجودة له الحق في إيقاف عمليات النشر إذا رأى أن إجراء اختبارات إضافية ضروري ، أو أنه من الضروري الانتظار إذا كان من الضروري إصلاح بعض الأخطاء الهامة في المنتج.
ومن المثير للاهتمام ، أن هذا التحول أطلق بعض التغييرات الإضافية ، ليس في عملية التطوير ، ولكن في التخطيط وتغيير الموضوعات التي نتحدث عنها في اليومية.
الآن ، لأن المطور هو المسؤول عن تقديم قصة المستخدم إلى المنتج ، عند التخطيط ، بدأنا في كتابة قصة المستخدم بطريقة تجعل كل منها مستقلًا عن الآخرين ، ويمكن أيضًا نشره بشكل مستقل ، مثل هذه الوحدة القابلة للنشر. قصة المستخدم أصبحت أكبر ، لكنها أصبحت أصغر.
أيضًا في التخطيط ، لا نقيم وقت التطوير ، ولكن نتحدث عن عندما نخطط لنشر ميزة.
في Daily ، لا نقول "لقد انتهيت من التطوير" ، لكننا نقول "اليوم سأقوم بنشر الميزة X" ، أو "اليوم أقوم بنزع بيئة الاختبار ، من لديه الوقت لمساعدتي في جلسة الاختبار؟"
نتيجة لذلك ، قمنا بتطوير فرق تطوير مستقلة تمتلك بيئات اختبار خاصة بها وتخطط لما يجب نشره وموعد نشره.