هل تعلمت أوامر Git ولكنك تريد أن تفهم كيف يعمل التكامل المستمر (CI) في الواقع؟ أو ربما ترغب في تحسين أنشطتك اليومية؟ ستمنحك هذه الدورة مهارات عملية في التكامل المستمر باستخدام مستودع GitHub. لا يُقصد من هذه الدورة أن تكون معالجًا يمكنك النقر عليه فقط ، بل على العكس من ذلك ، ستفعل نفس الأشياء التي يقوم بها الأشخاص بالفعل في العمل ، بنفس الطريقة التي يقومون بها. سأشرح النظرية وأنت تمر من خلال الخطوات ذات الصلة.

ماذا نفعل؟

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

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

سوف تمر عبر سيناريوهات CI القياسية التالية:

• العمل على ميزة ؛
• تطبيق الاختبارات الذاتية لضمان الجودة ؛
• تنفيذ المهمة ذات الأولوية ؛
• حل الصراع عند دمج الفروع (دمج التعارض) ؛
• حدوث خطأ في بيئة الإنتاج.

ما سوف تتعلم؟

ستتمكن من الإجابة على أسئلة مثل:

• ما هو التكامل المستمر (CI)؟
• ما أنواع الاختبارات التلقائية المستخدمة في CI ، واستجابة للإجراءات التي يتم إجراؤها؟
• ما هو طلب السحب ومتى يحتاجون إليه؟
• ما هو اختبار التطوير المدفوع بالاختبار (TDD) وما علاقته بـ CI؟
• دمج أو تطبيق التغييرات في الأعلى (تغيير الأساسي)؟
• التراجع أو الإصلاح في الإصدار التالي؟

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

ما هو التكامل المستمر؟

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

هناك خلافات حول هذا المصطلح.

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

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

التكامل المستمر يختلف عن العرض المستمر (التسليم المستمر ، قرص مضغوط) من حيث أنه لا يتطلب إصدار مرشح بعد كل دورة تكامل.

قائمة الخطوات التي سنستخدمها خلال الدورة

1. اسحب أحدث رمز. إنشاء فرع من master. بدء العمل.
2. إنشاء التزامات على فرعك الجديد. بناء واختبار محليًا. يمر؟ انتقل إلى الخطوة التالية. يفشل؟ أصلح الأخطاء أو الاختبارات وحاول مرة أخرى.
3. ادفع إلى المستودع البعيد أو الفرع البعيد.
4. قم بإنشاء طلب سحب. ناقش التغييرات ، أضف المزيد من الالتزامات مع استمرار المناقشة. قم بإجراء الاختبارات على فرع الميزات.
5. دمج / إعادة التأسيس من الرئيس. اجعل الاختبارات تمر على نتيجة الدمج.
6. النشر من فرع الميزة إلى الإنتاج.
7. إذا كان كل شيء جيدًا في الإنتاج لبعض الوقت ، فقم بدمج التغييرات لإتقانها.

️ التحضير

تأكد من أن لديك البرنامج الصحيح

لأخذ هذه الدورة سوف تحتاج نود.جي إس и عميل Git.

يمكنك استخدام أي عميل Git ، لكنني سأدرج أوامر سطر الأوامر فقط.

تأكد من تثبيت عميل Git الذي يدعم سطر الأوامر

إذا لم يكن لديك بالفعل عميل Git لسطر الأوامر مثبتًا ، فيمكنك العثور على إرشادات التثبيت هنا. هنا.

جهز المستودع

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

منتهي؟ إذا لم تكن قد قمت بتغيير الإعدادات الافتراضية ، فمن المرجح أن يتم تسمية مستودع المقرر الدراسي الخاص بك continuous-integration-team-scenarios-students، إنه موجود في حساب GitHub الخاص بك ويبدو عنوان URL على هذا النحو

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

سأقوم ببساطة بالاتصال بهذا العنوان <URL репозитория>.

أقواس زاوية مثل <тут> يعني أنه يجب عليك استبدال هذا التعبير بالقيمة المناسبة.

تأكد من أن إجراءات جيثب تم تمكينه لمستودع الدورة التدريبية هذا. إذا لم يتم تمكينها ، فالرجاء تمكينها بالنقر فوق الزر الكبير في منتصف الصفحة ، والذي يمكنك الوصول إليه بالنقر فوق الإجراءات في واجهة GitHub.

لن تتمكن من إكمال الدورة التدريبية باتباع إرشاداتي ما لم يتم تمكين إجراءات GitHub.

يمكنك دائمًا استخدام قدرة GitHub على عرض Markdown لمعرفة الحالة الحالية للقائمة التي نؤلفها هنا

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

حول الإجابات

في حين أن أفضل طريقة لإكمال هذه الدورة هي أن تقوم بها بنفسك ، فقد تجد صعوبة في إكمالها.

إذا شعرت أنك لا تفهم ما يجب عليك فعله ولا يمكنك الاستمرار ، يمكنك إلقاء نظرة خاطفة على الخيط solution، الموجود في مستودع البداية الخاص بك.
من فضلك لا تندمج solution в master خلال الدورة. يمكنك استخدام هذا الفرع لمعرفة ما يجب القيام به ، أو لمقارنة التعليمات البرمجية الخاصة بك مع رمز المؤلف ، باستخدام جميع الاحتمالات التي يوفرها لنا Git. في حالة ضياعك تمامًا ، يمكنك استبدال فرعك بالكامل master على فرع solution ثم قم بإعادة تعيين دليل العمل الخاص بك إلى خطوة الدورة التدريبية التي تريدها.

استخدم هذا فقط إذا كنت بحاجة إليه حقًا.

قم بتنفيذ التعليمات البرمجية الخاصة بك

git add .
git commit -m "Backing up my work"

هذه الأوامر

• إعادة تسمية master в master-backup;
• إعادة تسمية solution в master;
• تحويل (الخروج) إلى فرع جديد master والكتابة فوق محتويات دليل العمل ؛
• إنشاء فرع "حل" من "رئيسي" (والذي كان في السابق "حلًا") في حال احتجت إلى فرع "حل" في المستقبل.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

بعد هذه الخطوات ، يمكنك استخدام git log master لمعرفة الالتزام الذي تحتاجه.
يمكنك إعادة تعيين دليل العمل الخاص بك إلى هذا الالتزام كما يلي:

git reset --hard <the SHA you need>

إذا كنت راضيًا عن النتيجة ، فستحتاج في وقت ما إلى نشر نسختك من المستودع إلى مستودع بعيد (بعيد). لا تنس أن تحدد صراحة الفرع البعيد عند القيام بذلك.

git push --force origin master

يرجى ملاحظة أننا نستخدم git push --force. ربما لا ترغب في القيام بذلك كثيرًا ، ولكن لدينا سيناريو محدد للغاية هنا مع مستخدم واحد للمستودع الذي ، بالإضافة إلى ذلك ، يفهم ما يفعله.

بدء العمل

لنبدأ في تجميع قائمة خطوات CI الخاصة بنا. عادةً ما تبدأ هذه الخطوة عن طريق سحب أحدث رمز من مستودع بعيد ، ولكن ليس لدينا مستودع محلي حتى الآن ، لذلك نقوم باستنساخه من مستودع بعيد بدلاً من ذلك.

️ المهمة: تحديث المستودع المحلي وإنشاء فرع من master، بدء العمل

1. استنساخ مستودع الدورة التدريبية من <URL репозитория>.
2. بداية npm install في دليل مستودع الدورة التدريبية ؛ نحتاجه لتثبيت Jest ، والذي نستخدمه لإجراء الاختبارات.
3. قم بإنشاء فرع وقم بتسميته feature. قم بالتبديل إلى هذا الموضوع.

4. أضف رمز الاختبار إلى ci.test.js بين التعليقات التي تطلب منك ذلك.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. أضف نصًا مع أول 4 خطوات للملف ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   الأوامر

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

إنشاء التزامات على فرع جديد ، وبناء واختبار محليًا

سنقوم بإعداد الاختبارات للتشغيل قبل الالتزام ، ثم نلتزم بالكود.

سيناريوهات نموذجية عند إجراء الاختبارات تلقائيًا

• محليا:
  • بشكل مستمر أو استجابة لتغييرات الكود المناسبة ؛
  • عند الحفظ (للغات المترجمة أو المترجمة JIT) ؛
  • عند البناء (عندما يكون التجميع مطلوبًا) ؛
  • عند الالتزام ؛
  • عند النشر إلى مستودع مشترك.

• على خادم البناء أو بيئة البناء:
  • عندما يتم نشر الكود إلى فرع / مستودع شخصي.
  • يتم اختبار الرمز في هذا الموضوع.
  • يتم اختبار نتيجة الدمج المحتملة (عادةً باستخدام master).
  • كخطوة تكامل مستمرة / خط أنابيب تسليم مستمر

بشكل عام ، كلما تم تشغيل مجموعة الاختبار بشكل أسرع ، زادت قدرتك على تشغيلها. قد يبدو التدريج النموذجي هكذا.

• اختبارات الوحدة السريعة - عند البناء ، في خط أنابيب CI
• اختبارات الوحدة البطيئة ، واختبارات المكونات والتكامل السريعة - عند الالتزام ، في خط أنابيب CI
• اختبارات المكونات والتكامل البطيئة - في خط أنابيب CI
• اختبار الأمان واختبار الحمل والاختبارات الأخرى الطويلة أو المكلفة - في خطوط أنابيب CI / CD ، ولكن فقط في أوضاع / مراحل معينة / خطوط أنابيب البناء ، على سبيل المثال ، عند إعداد مرشح الإصدار أو عند البدء يدويًا.

️ كويست

أقترح إجراء الاختبارات يدويًا أولاً باستخدام الأمر npm test. بعد ذلك ، دعنا نضيف git hook لإجراء اختباراتنا عند الالتزام. هناك مشكلة واحدة: لا تعتبر Git hooks جزءًا من المستودع وبالتالي لا يمكن استنساخها من GitHub مع باقي محتوى الدورة التدريبية. لتثبيت هوك تحتاج إلى تشغيل install_hook.sh أو نسخ الملف repo/hooks/pre-commit إلى الدليل المحلي .git/hooks/.
عندما تلتزم ، سترى أن الاختبارات يتم تشغيلها وتتحقق من وجود كلمات رئيسية معينة في القائمة.

1. قم بتشغيل الاختبارات يدويًا عن طريق تشغيل الأمر npm test في مجلد مستودع المقرر الدراسي الخاص بك. تحقق من تشغيل الاختبارات.
2. قم بتثبيت خطاف الالتزام (خطاف التثبيت المسبق) عن طريق التشغيل install_hook.sh.
3. قم بتنفيذ التغييرات على المستودع المحلي.
4. تأكد من تشغيل الاختبارات قبل الالتزام.

يجب أن يبدو المستودع الخاص بك بهذا الشكل بعد إكمال هذه الخطوات.

الأوامر

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

انشر التعليمات البرمجية إلى مستودع بعيد أو فرع بعيد

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

• باستخدام forks ، يقوم المطور باستنساخ المستودع المشترك عن بُعد ، مما يؤدي إلى إنشاء نسخة شخصية بعيدة منه ، تُعرف أيضًا باسم fork. بعد ذلك ، يقوم باستنساخ هذا المستودع الشخصي حتى يتمكن من العمل معه محليًا. عند الانتهاء من العمل وإنشاء الالتزامات ، يضعها في مفترقته ، حيث تكون متاحة للآخرين ويمكن دمجها في مستودع مشترك. يستخدم هذا النهج بشكل شائع في مشاريع مفتوحة المصدر على GitHub. يتم استخدامه أيضًا في الدورة التدريبية المتقدمة [Team Work and CI with Git] (http://devops.redpill.solutions/).
• طريقة أخرى هي استخدام مستودع بعيد واحد فقط وعد الفرع فقط master المستودع المشترك "محمي". في هذا السيناريو ، ينشر المطورون الأفراد التعليمات البرمجية الخاصة بهم إلى فروع المستودع البعيد حتى يتمكن الآخرون من رؤية هذا الرمز ، إذا كان كل شيء على ما يرام ، فقم بدمجها مع master المستودع المشترك.

في هذه الدورة التدريبية بالذات ، سنستخدم سير عمل يستخدم الفروع.

دعونا ننشر الكود الخاص بنا.

️ كويست

• انشر التغييرات إلى فرع بعيد بنفس اسم فرع عملك

الأوامر

git push --set-upstream origin feature

قم بإنشاء طلب سحب

قم بإنشاء طلب سحب بعنوان مراجعة الخطوات... تثبيت feature باسم "الفرع الرئيسي" و master باسم "الفرع الأساسي".

تأكد من أنك قمت بتثبيت master في تقريرها شوكة المستودع بصفتي "فرعًا أساسيًا" ، لن أرد على طلبات التغيير إلى مستودع محتوى الدورة التدريبية.

في GitHub العامية ، "الفرع الأساسي" هو الفرع الذي تستند إليه في عملك ، و "الفرع الرئيسي" هو الفرع الذي يحتوي على التغييرات المقترحة.

ناقش التغييرات ، أضف التزامات جديدة مع استمرار المناقشة

طلب سحب (العلاقات العامة)

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

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

• مناقشات منظمة تتعلق بتغييرات محددة في الكود ؛
• كمكان لعرض التعليقات على العمل الجاري من الاختبارات التلقائية والأقران ؛
• إضفاء الطابع الرسمي على الشيكات البرمجية ؛
• حتى تتمكن لاحقًا من معرفة الأسباب والاعتبارات الكامنة وراء هذا الجزء أو ذاك من التعليمات البرمجية.

عادةً ما تقوم بإنشاء طلب سحب عندما تحتاج إلى مناقشة شيء ما أو الحصول على تعليقات. على سبيل المثال ، إذا كنت تعمل على ميزة يمكن تنفيذها بطرق متعددة ، فيمكنك إنشاء طلب سحب قبل كتابة السطر الأول من التعليمات البرمجية لمشاركة أفكارك ومناقشة خططك مع المتعاونين. إذا كان العمل أكثر بساطة ، يتم فتح طلب سحب عندما يكون هناك شيء قد تم إنجازه بالفعل والتزامه ويمكن مناقشته. في بعض السيناريوهات ، قد ترغب في فتح PR فقط لأسباب تتعلق بمراقبة الجودة: لإجراء اختبارات آلية أو بدء مراجعات الكود. مهما كان ما تقرره ، لا تنس الإشارة إلى @ الأشخاص الذين تريد الموافقة عليهم في طلب السحب الخاص بك.

عادة ، عند إنشاء العلاقات العامة ، تقوم بما يلي.

• حدد ما تقترح تغييره وأين.
• اكتب وصفًا يشرح الغرض من التغيير. قد ترغب:
  • أضف شيئًا مهمًا غير واضح من الكود ، أو شيئًا مفيدًا لفهم السياق ، مثل #bugs وأرقام الالتزام ؛
  • @ أذكر أي شخص تريد العمل معه ، أو يمكنك الإشارة إليه باستخدام @ في التعليقات لاحقًا ؛
  • اطلب من الزملاء المساعدة في شيء ما أو تحقق من شيء محدد.

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

يرجى الانتظار حتى تكتمل الاختبارات. يمكنك رؤية حالة الاختبارات أسفل سلسلة العلاقات العامة في واجهة GitHub. تواصل عند الانتهاء من الاختبارات.

️ أضف ملاحظة حول اعتباط قائمة خطوات CI

القائمة المستخدمة في هذه الدورة تعسفية وذاتية ، يجب أن نضيف ملاحظة حول هذا الموضوع.

️ التحدي: قم بإنشاء طلب سحب لهذه الملاحظة

1. قم بالتبديل إلى الفرع master.
2. قم بإنشاء فرع مسمى bugfix.
3. أضف نص الملاحظة إلى نهاية الملف ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. التزم بالتغييرات.
5. نشر فرع bugfix إلى مستودع بعيد.
6. قم بإنشاء طلب سحب مسمى إضافة ملاحظة مع الفرع الرئيسي bugfix وفرع القاعدةmaster.

تأكد من أنك قمت بتثبيت master في تقريرها شوكة المستودع بصفتي "فرعًا أساسيًا" ، لن أرد على طلبات التغيير إلى مستودع محتوى الدورة التدريبية.

هذا ما يجب أن يبدو عليه المستودع الخاص بك.

الأوامر

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

الموافقة على طلب السحب "إضافة ملاحظة"

️ كويست

1. قم بإنشاء طلب سحب.
2. انقر على "طلب سحب الدمج".
3. انقر فوق "تأكيد الدمج".
4. انقر فوق "حذف الفرع" ، لسنا بحاجة إليه بعد الآن.

هذا رسم تخطيطي للالتزامات بعد الدمج.

استمر في العمل وإضافة الاختبارات

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

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

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

التطوير المدفوع بالاختبار (TDD)

توصي TDD بكتابة الاختبارات قبل الكود. يبدو سير العمل النموذجي باستخدام TDD هكذا.

1. أضف اختبارًا.
2. قم بتشغيل جميع الاختبارات وتحقق من فشل الاختبار الجديد.
3. اكتب الكود.
4. قم بإجراء الاختبارات ، وتأكد من اجتياز جميع الاختبارات.
5. أعد بناء الكود الخاص بك.
6. يكرر.

نظرًا لأن نتائج الاختبار التي تفشل تظهر باللون الأحمر عادةً ، وتظهر الاختبارات التي نجحت باللون الأخضر ، تُعرف الدورة أيضًا باسم red-green-refactor.

️ كويست

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

1. قم بالتبديل إلى الفرع feature.

2. أضف هذه الاختبارات إلى ci.test.js بعد آخر مكالمة it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. حاول إجراء الاختبارات. لو pre-commit تم تعيين الخطاف ، ستفشل محاولة الالتزام.
4. ثم أضف هذا النص إلى ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. قم بإجراء التغييرات وتنفيذها محليًا.
6. انشر التغييرات في الفرع feature.

الآن يجب أن يكون لديك شيء مثل هذا

الأوامر

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

دمج الصراع

انتقل إلى طلب التغيير مراجعة الخطوات.

على الرغم من أننا لم نفعل شيئًا خاطئًا واجتازت اختبارات الكود الخاص بنا ، ما زلنا لا نستطيع دمج الفرع feature и master. هذا لأن الخيط الآخر bugfix تم دمجه مع master بينما كنا نعمل على هذا العلاقات العامة.
هذا يخلق حالة يكون فيها الفرع البعيد master إصدار أحدث من الإصدار الذي أسسنا الفرع عليه feature. لهذا السبب ، لا يمكننا فقط إرجاع الرأس master حتى نهاية الفرع feature. في هذه الحالة ، نحتاج إما إلى الدمج أو تطبيق الالتزامات feature أكثر من (تغيير الأساس) master. يمكن لـ GitHub في الواقع إجراء دمج تلقائي في حالة عدم وجود تعارضات. للأسف ، في حالتنا ، كلا الفرعين لهما تغييرات متنافسة في الملف ci.md. يُعرف هذا الموقف باسم تعارض الدمج ونحتاج إلى حله يدويًا.

دمج أو تغيير الأساسي

دمج

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

ريباسي

• عمليات الإعادة من الفرع الحالي أعلى القاعدة واحدة تلو الأخرى.
  • يتم إنشاء التزامات جديدة باستخدام SHAs الجديدة ، مما يتسبب في مطابقة التزامات GitHub لطلبات السحب الأصلية ولكن ليس التعليقات المقابلة.
  • يمكن إعادة توحيد الالتزامات وتغييرها في العملية ، أو حتى دمجها في واحدة.
• قد تحتاج إلى حل نزاعات متعددة.
• يسمح لك بالحفاظ على تاريخ خطي.
  • قد تكون القصة أسهل في القراءة ، طالما أنها ليست طويلة جدًا دون سبب وجيه.
  • التصحيح التلقائي واستكشاف الأخطاء وإصلاحها أسهل إلى حد ما: يجعل ذلك ممكنًا git bisect، يمكن أن تجعل عمليات التراجع التلقائية أكثر وضوحًا وقابلية للتنبؤ بها.
• يتطلب نشر فرع مع الارتباطات المعادة بعلامة --force عند استخدامها مع طلبات التغيير.

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

هنا سوف نستخدم الدمج.

️ كويست

1. تأكد من وجود الرمز في الفرع المحلي master محدث من مستودع بعيد.
2. قم بالتبديل إلى الفرع feature.
3. بدء الدمج مع فرع master. سيتم الإبلاغ عن تعارض الدمج بسبب التغييرات المتنافسة في ci.md.
4. قم بحل التعارض بحيث تظل قائمة خطوات CI وملاحظة حولها في النص.
5. انشر التزام دمج إلى فرع بعيد feature.
6. تحقق من حالة طلب السحب في واجهة مستخدم GitHub ، وانتظر حتى يتم حل الدمج.

الأوامر

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

عمل رائع!

لقد انتهيت من القائمة والآن تحتاج إلى الموافقة على طلب السحب master.

️ المهمة: الموافقة على طلب السحب "مراجعة الخطوات"

1. افتح طلب سحب.
2. انقر على "طلب سحب الدمج".
3. انقر فوق "تأكيد الدمج".
4. انقر فوق "حذف الفرع" لأننا لم نعد بحاجة إليه.

هذا هو مستودعك في الوقت الحالي

خطأ في المنتج

يقولون أنه "يمكن استخدام الاختبار لإظهار وجود أخطاء ، ولكن لا يظهر أبدًا غيابها". على الرغم من حقيقة أن لدينا اختبارات ولم تظهر لنا أي أخطاء ، تسلل خطأ ماكر إلى الإنتاج.

في مثل هذا السيناريو ، نحتاج إلى الاهتمام بما يلي:

• يتم نشره على المنتج ؛
• رمز الفرع master مع وجود خطأ ، يمكن للمطورين من خلاله بدء عمل جديد.

التراجع أو الإصلاح في الإصدار التالي؟

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

نظرًا لأن التراجع لا ينطوي على أي مخاطر في حالتنا ، فسوف نسير على هذا النحو ، لأنه يسمح لنا بذلك

• إصلاح الخلل في الإنتاج في أسرع وقت ممكن ؛
• قم بعمل كود في master جاهز على الفور لبدء عمل جديد.

️ كويست

1. قم بالتبديل إلى الفرع master محليا
2. قم بتحديث المستودع المحلي من المستودع البعيد.
3. التراجع عن التزام دمج العلاقات العامة مراجعة الخطوات в master.
4. نشر التغييرات إلى مستودع بعيد.

هذا هو تاريخ المستودع مع إرجاع التزام الدمج

الأوامر

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ الفحص الذاتي

تأكد من أن ci.md لم يعد يحتوي على النص "خطأ خادع" بعد التراجع عن التزام الدمج.

أصلح قائمة خطوات CI وارجع إلى إتقانها

لقد قمنا بإرجاع التزام دمج الفرع بالكامل feature. النبأ السار هو أننا الآن ليس لدينا خطأ في master. النبأ السيئ هو أن قائمتنا الثمينة لخطوات التكامل المستمر قد اختفت أيضًا. لذلك ، من الناحية المثالية ، نريد تطبيق الإصلاح على الالتزامات من feature وإعادتهم إلى master مع الإصلاح.

يمكننا التعامل مع المشكلة بطرق مختلفة:

• التراجع عن الالتزام ، والذي يعيد الدمج feature с master;
• يهاجر يرتكب من السابق feature.

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

️ كويست

1. إنشاء فرع يسمى feature-fix والتبديل إليه.

2. ترحيل كافة الالتزامات من الفرع السابق feature إلى موضوع جديد. حل تعارضات الدمج التي حدثت أثناء الترحيل.

   

3. أضف اختبار الانحدار إلى ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. قم بتشغيل الاختبارات محليًا للتأكد من أنها لم تكتمل بنجاح.
5. احذف النص "مع وجود خطأ متستر" في ci.md.
6. أضف تغييرات الاختبار والتغييرات إلى قائمة الخطوات إلى الفهرس وقم بتنفيذها.
7. انشر الفرع إلى المستودع البعيد.

يجب أن ينتهي بك الأمر بشيء مثل

الأوامر

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

قم بإنشاء طلب سحب.

قم بإنشاء طلب سحب بعنوان إصلاح الميزة... تثبيت feature-fix باسم "الفرع الرئيسي" ، و master باسم "الفرع الأساسي".
يرجى الانتظار حتى تكتمل الاختبارات. يمكنك رؤية حالة الاختبارات في الجزء السفلي من مناقشة العلاقات العامة.

تأكد من أنك قمت بتثبيت master في تقريرها شوكة المستودع بصفتي "فرعًا أساسيًا" ، لن أرد على طلبات التغيير إلى مستودع محتوى الدورة التدريبية.

الموافقة على طلب السحب "إصلاح الميزة"

شكرا للتصحيح! الرجاء الموافقة على التغييرات في master من طلب السحب.

️ كويست

1. انقر على "طلب سحب الدمج".
2. انقر فوق "تأكيد الدمج".
3. انقر فوق "حذف الفرع" لأننا لم نعد بحاجة إليه.

هذا ما يجب أن يكون لديك الآن.

تهانينا!

لقد أكملت جميع الخطوات التي يتخذها الأشخاص عادةً في عملية تكامل مستمرة.

إذا لاحظت أي مشاكل في الدورة التدريبية أو كنت تعرف كيفية تحسينها ، فيرجى إنشاء مشكلة في مستودعات محتوى الدورة. هذه الدورة أيضا نسخة تفاعلية باستخدام GitHub Learning Lab كمنصة.

المصدر: www.habr.com