منذ وقت ليس ببعيد ، في أحد مشاريع شركتنا ، تقرر التخلي نهائيًا عن استخدام Subversion لتخزين وإصدار التعليمات البرمجية لصالح Git.
كانت الأهداف الرئيسية للانتقال على النحو التالي:
- تحسين شفافية عملية التطوير.
- تنفيذ إجراء مراجعة الكود الإلزامي قبل تحديث التحديثات لبيئات الاختبار.
- تنفيذ التكامل المستمر لإنشاء تحديثات بعد مراجعة التعليمات البرمجية وتثبيتها في بيئات الاختبار.
كان الشرط المسبق لتحقيق هذه الأهداف هو استخدام GitLab (تم استخدام خادم Git هذا بالفعل من قبل العميل وكان هناك بالفعل رمز هناك ينتمي إلى مقدمة الحل) و Jira (تم استخدامه بالفعل من قبل العميل).
تم اقتراح استخدام Git Flow كنموذج التطوير المستهدف ، مع إضافة رمز مراجعة إليه. أصبح نموذج التطوير الفعلي هذا هو المعيار في تطوير البرمجيات مفتوحة المصدر ويستخدمه معظم عمالقة الصناعة. هذا هو السبب في أن دعمها مدمج في العديد من الأدوات الشائعة للعمل مع Git. تم كتابة عدد كبير من المواد حول موضوع استخدامه ؛ وسوف أشير إلى أنجحها للتعريف الأولي: واحد واثنان .
في حد ذاته ، يقدم هذا النموذج فقط المبادئ العامة للحفاظ على التعليمات البرمجية ، مع استبعاد العمليات المصاحبة لكتابتها. لذلك ، يعتمد تنفيذ كل شيء آخر ، بما في ذلك رمز المراجعة ، على خادم Git المحدد. في هذا الصدد ، يعد GitHub هو الأكثر ملاءمة: فقد تم بناؤه في الأصل كمنصة لتعاون عدد كبير من المطورين المستقلين ويسمح لك بتحديد حقوق إرسال الالتزامات (Push) في المستودع مع القدرة على إنشاء طلبات لإرسال التعليمات البرمجية. بالإضافة إلى ذلك ، يقدم GitLab سير العمل الخاص به للحفاظ على التعليمات البرمجية المسماة GitLab Flow ، المصممة لاستخدام GitLab CI. لذلك ، في GitLab ، لا يتم تنفيذ وظيفة إنشاء طلبات إرسال التعليمات البرمجية ويقترح استخدام طلبات دمج الفروع لمراجعة رمز التغيير. لبناء وتثبيت القطع الأثرية في المشروع ، تم استخدام Jenkins بالفعل ، مما يسمح لك بإنشاء وتكوين مهام التجميع والنشر بمرونة ، وتقرر عدم التبديل إلى GitLab CI ، ورفض في نفس الوقت فكرة استخدام GitLab Flow.
وألاحظ أيضًا أن المشروع قد تم تكوين عمليات الدمج في Jira و Git. في Jira ، في المكوّن الإضافي Git ، تمت إضافة مستودع تم إنشاؤه لتخزين شفرة المصدر للتتبع ، وفي GitLab تم تكوين هذا المستودع للتكامل مع Jira في قسم "التكامل" في المستودع.
لحل هذه المشكلة ، تم تطوير سير عمل للعمل مع التعليمات البرمجية يكون مشابهًا في البنية لـ Git Flow ، ولكنه يسمح بإجراء مراجعات التعليمات البرمجية في كل مرة يتم فيها إجراء تغييرات على فروع العملية الرئيسية (التطوير ، والإصدار - n والماجستير) باستخدام GitLab. بعد ذلك ، سيتم وصف العملية الناتجة ، وكذلك مراحل التكامل المستمر وتسليم البرمجيات إلى السلاسل المجاورة لها. بين قوسين هي الأوامر المقابلة للتنفيذ.
يتم تحميل المستودع الذي تم إنشاؤه لتخزين شفرة المصدر إلى المستودع المحلي (git clone) ويتم تهيئة Git Flow (git flow init) - بالإضافة إلى الفرع الرئيسي (لإنشاء العلامات من أجل تخزين الإصدارات المستقرة) ، يتم إنشاء فرع التطوير (فرع التطوير الرئيسي ، في الذي يدمج فروع الوظائف والإصدارات والإصلاحات) ، يتم تعيين أقنعة لفروع الوظائف والإصدارات والإصلاحات ، ويتم أيضًا الانتقال إلى فرع التطوير.
بعد ذلك ، يتم نقل فرع رمز المصدر الحالي من Subversion إلى نسخة العمل ، ويتم الالتزام بالرمز (git add -A + git الالتزام -m "Commit message") إلى فرع تطوير المستودع المحلي وتحميله إلى المستودع البعيد (تطوير أصل git push). بعد ذلك ، يمكنك البدء في تطوير وظائف جديدة باستخدام Git لإصدار الكود.
أثناء التطوير ، يتم تنزيل الإصدار الحالي من فرع التطوير ويتم إنشاء الفروع منه لتطوير وظائف جديدة (ميزة تدفق git تبدأ MYFEATURE) وفقًا لرموز مهام Jira التي يتم فيها إجراء التطوير.
يتم تنفيذ الانتقال إلى الفرع الذي تم إنشاؤه (git checkout MYFEATURE) تلقائيًا ، ويتم تطوير الوظائف المخططة وتلتزم التغييرات بفرع MYFEATURE المحلي (git الالتزام - m "Commit message"). لاحظ أنه من أجل التكامل الصحيح لـ Git و Jira ، يجب الإشارة إلى رمز الالتزام في Jira الذي ينطبق عليه هذا الإصلاح في رسائل الالتزام. ثم سيتم عرض هذه الالتزامات في المهام المناظرة لها ، وكذلك في قسم "عمليات تنفيذ Git" في المشروع ، والتي يمكنك من خلالها تحديد ما هو مدرج في إصدار معين.
عندما يتم تطوير وظيفة المهمة المحددة وتكون جاهزة لتقديمها إلى بيئة الاختبار ، يتم تحميل الالتزامات التي تم إنشاؤها إلى الفرع البعيد بنفس الاسم (git push -u origin MYFEATURE) ويتم تقديم طلب لدمج الفرع الذي تم تنزيله مع فرع التطوير لقائد الفريق أو واجباته بالنيابة.
لطلب الدمج ، يحل المطور تعارضات الدمج (إن وجدت) ويؤدي قائد فريق التطوير (أو التمثيل) إلى مراجعة الكود ، يمكن من خلاله إنشاء التزامات إضافية (git -mit -m “Commit message”) مع تصحيحات على التعليقات المستلمة أثناء مراجعة التعليمات البرمجية ، في فرع بوظائف جديدة وإرسالها إلى المستودع المركزي (git push -u Origin MYFEATURE). بعد الانتهاء بنجاح من المراجعة ، يؤكد قائد الفريق (أو التمثيل) اندماج الفروع. هنا ليس من غير الضروري تعيين العلم لحذف الفرع بعد الدمج - وإلا يمكن أن ينمو عدد الفروع بسرعة إلى مقاييس غير لائقة.
لضمان التكامل المستمر في مستودع GitLab ، تم تكوين خطاف الويب في قسم "التكامل" ، والذي يستدعي مهام Jenkins لبناء وظائف جديدة وتثبيتها في بيئة الاختبار. تقوم Jenkins ، باستخدام مكون إضافي للعمل مع Git ، بتنزيل كود المصدر ، والحصول على اسم المهمة منه واستخدام واجهة برمجة تطبيقات Jira لطلب قائمة بالمكونات التي تم تغييرها وتحتاج إلى تجميعها ، وبدء عملية البناء ، وتشغيل اختبارات الوحدة ، وتحميل العناصر التي تم إنشاؤها إذا مرت بنجاح في Sonatype Nexus وتثبيتها على بيئة اختبار. إذا حدث فشل في إحدى المراحل أو فشلت اختبارات الوحدة ، فسيتم إعلام فريق التطوير بمساعدة مكون البرنامج الإضافي Telegram بشأن نتيجة البناء. إذا كان التثبيت ناجحًا ، فسيتم إخطار فريق QA بأن المهمة جاهزة للاختبار.
في حالة ظهور عيوب ، يتم تنزيل الإصدار الحالي من فرع التطوير ومن التزام الدمج لفرع MYFEATURE مع فرع التطوير يتم إنشاء فرع الإصلاح العاجل MYFEATURE (git checkout [BASECOMMIT] -b الإصلاحات السريعة - MYFEATURE).
عند الإنشاء ، يتم إجراء السحب تلقائيًا للفرع الذي تم إنشاؤه ، ويتم إجراء التصحيحات والتغييرات التي يتم إجراؤها على الإصلاح العاجل للفرع المحلي - MYFEATURE (git الالتزام الإصلاح - MYFEATURE - m "Commit message"). عندما يكتمل التصحيح ويصبح جاهزًا لتقديمه إلى بيئة الاختبار ، يتم دفعهم إلى فرع بعيد يحمل نفس الاسم (git push -u أصل الإصلاح- MYFEATURE) ويتم إنشاء طلب دمج مع فرع التطوير.
لطلب الدمج ، يحل المطور تعارضات الدمج (إن وجدت) ويقوم بمراجعة التعليمات البرمجية ، حيث من الممكن إنشاء التزامات إضافية بتصحيحات على التعليقات المستلمة. بعد اكتمال المراجعة بنجاح ، تندمج الفروع. فور نقل التصحيح إلى فرع التطوير ، يعمل Web Hook أيضًا على استدعاء المهمة في Jenkins لإنشاء اختبارات الوحدة وتشغيلها وتحميل العناصر التي تم إنشاؤها في Sonatype Nexus وتثبيت التصحيح على بيئة الاختبار. تعمل آلية إخطار مماثلة للتصحيحات.
إذا تم إصلاح جميع العيوب ، يتم تنزيل الإصدار الحالي من فرع التطوير ومن الالتزام بدمج فرع الإصلاح العاجل MYFEATURE إلى فرع التطوير ، يتم إنشاء فرع الإصدار - mn (يبدأ إصدار تدفق التدفق RELEASENAME [BASECOMMIT]).
يؤدي إنشاء فرع الإصدار أيضًا إلى تهيئة إطلاق Web Hook لاستدعاء مهمة في Jenkins ، التي تقوم بتنزيل شفرة المصدر من Git ، وتحصل على اسم فرع الإصدار منه ، وباستخدام واجهة برمجة تطبيقات Jira ، تستعلم قائمة المكونات التي تم تغييرها كجزء من مهام الإصدار ، وتقوم بتنزيل الإصدارات الحالية من Sonatype Nexus ويضعهم في بيئة اختبار الانحدار. بعد تثبيت الإصدار على بيئة اختبار الانحدار ، يتم تشغيل البرامج النصية لإعداد البيئة للاختبار (إعادة تشغيل التطبيق ، وتنظيف قاعدة البيانات ، وما إلى ذلك) ويتم تشغيل الاختبارات الذاتية للانحدار للتحقق من تشغيل وظائف النظام الرئيسية ، والتي ينتج عنها تقرير باستخدام البرنامج المساعد Allure Reports لـ Jenkins. بعد التثبيت ، يتم إخطار فريق QA في Telegram بنتائج تشغيل الاختبار التلقائي واستعداد الإصدار لاختبار الانحدار اليدوي.
في حالة ظهور عيوب أثناء اختبار الانحدار ، يتم تنزيل الإصدار الحالي من فرع الإصدار - mn ، ومن آخر التزام ، يتم إنشاء فرع الإصلاح العاجل / BUGNAME باسم العيب في Jira (git checkout -b الإصلاح العاجل / BUGNAME [BASECOMMIT]).
يتم إجراء الدفع تلقائيًا للفرع الذي تم إنشاؤه ، ويتم إجراء التصحيحات اللازمة والتغييرات التي يتم إجراؤها على الإصلاح العاجل للفرع المحلي / BUGNAME (git ارتكاب الإصلاح / BUGNAME - m "Commit message"). عندما يكتمل التصحيح ويصبح جاهزًا لتقديمه إلى بيئة اختبار الانحدار ، يتم دفعهم إلى فرع بعيد يحمل نفس الاسم (git push -u أصل الإصلاح العاجل / BUGNAME) ويتم إنشاء طلب دمج مع فرع الإصدار- mn
لطلب الدمج ، يحل المطور تعارضات الدمج (إن وجدت) ويقوم بمراجعة التعليمات البرمجية ، والتي من خلالها يمكن إنشاء التزامات إضافية بتصحيحات على التعليقات التي تم تلقيها أثناء مراجعة الكود. يتم إجراء هذه الالتزامات أيضًا إلى الإصلاح العاجل للفرع المحلي / BUGNAME (git الالتزام الإصلاح العاجل / BUGNAME -m "رسالة الالتزام") ويتم دفعها إلى فرع بعيد بنفس الاسم (git push -u أصل الإصلاح العاجل / BUGNAME). بعد اكتمال المراجعة بنجاح ، تندمج الفروع. يعمل الدمج على تهيئة إطلاق Web Hook لاستدعاء مهمة في Jenkins ، على غرار المهمة السابقة ، ولكنه يختلف في أنه يقوم بتنزيل الرمز من Git ، ويحصل على اسم العيب منه ، ويستخدم Jira API لطلب قائمة بالمكونات التي تم تغييرها كجزء من الإصلاح ، وجمع هذه المكونات ، التنزيلات إلى Sonatype Nexus وتثبيتها على بيئة اختبار الانحدار. علاوة على ذلك ، عن طريق القياس ، يتم تحضير البيئة للاختبار الذاتي ، ويتم تشغيل اختبارات الانحدار الذاتي ، ويتم إبلاغ نتائجها.
عندما يتم إصلاح جميع العيوب ، يتم تثبيت الإصدار على بيئة إنتاجية. للقيام بذلك ، قم بدمج فرع release-mn مع الفروع الرئيسية والمتطورة ، وقم أيضًا بإنشاء علامة إصدار.
عند إنشائه ، يبدأ في إطلاق ربط الويب لاستدعاء المهمة في Jenkins ، التي تقوم بتنزيل كود المصدر من Git ، وتحصل على رقم الإصدار منه ، وباستخدام واجهة برمجة تطبيقات Jira ، تستعلم قائمة المهام التي تم تضمينها في الإصدار والمكونات التي تم تغييرها كجزء من هذه المهام ، بعد الذي يضخ النسخة الحالية من القطع الأثرية من Sonatype Nexus ويثبتها في بيئة إنتاجية.
مع الإصلاحات العاجلة للمبيعات ، تقرر استخدام عملية مشابهة للإصدار - وإلا ستفقد مراحل اختبار التغييرات التي تم إجراؤها.
عند تنفيذ العملية ، تم أيضًا إجراء تدريب للموظفين الذين ليس لديهم خبرة في العمل مع Git و GitLab ، والتي تم تطوير برنامج تدريبي مناسب لها. باستخدامه ، ستتمكن بنفسك من إجراء تدريب على استخدام Source Tree و Intellij IDEA للعمل مع Git ، بالإضافة إلى GitLab لإجراء مراجعات الكود. في المنشور التالي سأعطيها ، مع استكمال الرسوم التوضيحية.