آیا دستورات Git را یاد گرفته‌اید اما می‌خواهید تصور کنید که چگونه یکپارچه‌سازی پیوسته (CI) در واقعیت کار می‌کند؟ یا شاید می خواهید فعالیت های روزانه خود را بهینه کنید؟ این دوره به شما مهارت های عملی در یکپارچه سازی مداوم با استفاده از مخزن GitHub می دهد. این دوره قصد ندارد جادوگری باشد که بتوانید به سادگی روی آن کلیک کنید، برعکس، شما همان اقداماتی را انجام خواهید داد که افراد در واقع در محل کار انجام می دهند، به همان روشی که آن را انجام می دهند. وقتی مراحل مربوطه را طی می کنید، تئوری را توضیح خواهم داد.

چه کنیم؟

همانطور که پیشرفت می کنیم، به تدریج فهرستی از مراحل CI معمولی ایجاد می کنیم که راهی عالی برای به خاطر سپردن این لیست است. به عبارت دیگر، ما لیستی از اقداماتی را ایجاد خواهیم کرد که توسعه دهندگان در حین انجام یکپارچه سازی مداوم، انجام یکپارچه سازی مداوم انجام می دهند. ما همچنین از مجموعه‌ای از آزمایش‌های ساده استفاده خواهیم کرد تا فرآیند CI خود را به فرآیند واقعی نزدیک‌تر کنیم.

این GIF به صورت شماتیک تعهدات موجود در مخزن شما را در حین پیشرفت در دوره نشان می دهد. همانطور که می بینید، هیچ چیز پیچیده ای در اینجا وجود ندارد و فقط ضروری ترین است.

سناریوهای استاندارد CI زیر را طی خواهید کرد:

• روی یک ویژگی کار کنید؛
• استفاده از تست های خودکار برای اطمینان از کیفیت؛
• اجرای وظیفه اولویت دار؛
• حل تعارض هنگام ادغام شاخه ها (تضاد ادغام);
• یک خطا در محیط تولید رخ می دهد.

چه چیزی یاد خواهید گرفت؟

شما قادر خواهید بود به سوالات زیر پاسخ دهید:

• ادغام پیوسته (CI) چیست؟
• چه نوع تست‌های خودکاری در CI استفاده می‌شوند و در پاسخ به چه اقداماتی راه‌اندازی می‌شوند؟
• درخواست های کششی چیست و چه زمانی به آنها نیاز است؟
• توسعه تست محور (TDD) چیست و چه ارتباطی با CI دارد؟
• آیا باید تغییرات را ادغام کنم یا تغییر پایه دهم؟
• بازگرداندن یا تعمیر در نسخه بعدی؟

در ابتدا چیزهایی مانند "درخواست کشش" را همه جا ترجمه کردم، اما در نتیجه تصمیم گرفتم عباراتی را به زبان انگلیسی در برخی جاها برگردانم تا درجه جنون در متن کاهش یابد. من گاهی اوقات از "programmer surzhik" مانند فعل فوق العاده "commit" استفاده می کنم که در آن مردم واقعاً از آن در محل کار استفاده می کنند.

ادغام پیوسته چیست؟

یکپارچه سازی مداومیا CI، یک روش فنی است که در آن هر یک از اعضای تیم حداقل یک بار در روز کد خود را در یک مخزن مشترک ادغام می کنند و کد حاصل حداقل باید بدون خطا ساخته شود.

در مورد این اصطلاح اختلاف نظر وجود دارد

نقطه اختلاف فراوانی ادغام است. برخی استدلال می کنند که ادغام کد تنها یک بار در روز برای ادغام مداوم کافی نیست. یک مثال از تیمی ارائه شده است که در آن هر کسی کد تازه را در صبح می گیرد و یک بار در شب آن را ادغام می کند. در حالی که این یک اعتراض منطقی است، به طور کلی اعتقاد بر این است که تعریف یک بار در روز به طور منطقی عملی، خاص و مناسب برای تیم هایی با اندازه های مختلف است.

اعتراض دیگر این است که C++ دیگر تنها زبان مورد استفاده در توسعه نیست، و صرفاً نیاز به اسمبلی بدون خطا به عنوان روشی برای اعتبار سنجی ضعیف است. برخی از تست‌ها (به عنوان مثال، تست‌های واحدی که به صورت محلی اجرا می‌شوند) نیز باید با موفقیت کامل شوند. در حال حاضر، جامعه در حال حرکت به سمت این است که این مورد را به یک الزام تبدیل کند، و در آینده احتمالاً «تست‌های ساخت + واحد» به یک روش معمول تبدیل خواهد شد، البته اگر قبلاً چنین نشده است.

یکپارچه سازی مداوم متفاوت از تحویل مداوم (تحویل مستمر، سی دی) به این دلیل که پس از هر چرخه یکپارچه سازی به نامزد انتشار نیاز ندارد.

فهرست مراحلی که در طول دوره استفاده خواهیم کرد

1. آخرین کد را وارد کنید. ایجاد شعبه از master. شروع به کار.
2. در شعبه جدید خود commit ایجاد کنید. به صورت محلی بسازید و آزمایش کنید. عبور؟ به مرحله بعد برو. شکست؟ خطاها یا تست ها را برطرف کنید و دوباره امتحان کنید.
3. به مخزن راه دور یا شعبه راه دور خود فشار دهید.
4. یک درخواست کشش ایجاد کنید. تغییرات را مورد بحث قرار دهید، با ادامه بحث، تعهدات بیشتری اضافه کنید. تست ها را در شاخه ویژگی بگذرانید.
5. Merge/Rebase commits از master. آزمایش ها را روی نتیجه ادغام قبول کنید.
6. استقرار از شاخه ویژگی تا تولید.
7. اگر همه چیز در تولید برای مدتی خوب است، تغییرات را به Master ادغام کنید.

️ آماده سازی

مطمئن شوید که نرم افزار مناسبی دارید

برای گذراندن این دوره به Node.js و и کلاینت Git.

شما می توانید از هر کلاینت Git استفاده کنید، اما من فقط دستوراتی را برای خط فرمان ارائه خواهم کرد.

مطمئن شوید که یک کلاینت Git نصب کرده اید که از خط فرمان پشتیبانی می کند

اگر هنوز یک کلاینت Git ندارید که از خط فرمان پشتیبانی کند، می‌توانید دستورالعمل‌های نصب را پیدا کنید اینجا.

مخزن را آماده کنید

شما باید یک کپی شخصی (چنگال) ایجاد کنید مخزن قالب با کد دوره در GitHub. بیایید موافقت کنیم که این نسخه شخصی را فراخوانی کنیم مخزن دوره.

انجام شده؟ اگر تنظیمات پیش فرض را تغییر نداده اید، به احتمال زیاد مخزن دوره شما فراخوانی می شود continuous-integration-team-scenarios-students، در حساب GitHub شما قرار دارد و URL به این شکل است

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

من به سادگی با این آدرس تماس خواهم گرفت <URL репозитория>.

براکت های زاویه مانند <тут> به این معنی است که شما باید چنین عبارتی را با مقدار مناسب جایگزین کنید.

مطمئن شوید که اقدامات GitHub برای این مخزن دوره گنجانده شده است. اگر آنها فعال نیستند، لطفاً با کلیک کردن روی دکمه بزرگ در وسط صفحه، آنها را فعال کنید، که می توانید با کلیک کردن روی Actions در رابط GitHub به آن دسترسی پیدا کنید.

اگر GitHub Actions فعال نباشد، نمی‌توانید دوره را طبق دستورالعمل‌های من تکمیل کنید.

همیشه می‌توانید از توانایی 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 و محتویات دایرکتوری کاری را بازنویسی کنید.
• در صورتی که در آینده به یک شاخه "راه حل" نیاز دارید، از "master" (که قبلا "راه حل" بود) یک شاخه "راه حل" ایجاد کنید.

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

بعد از این مراحل می توانید استفاده کنید git log master تا بفهمید به کدام تعهد نیاز دارید.
می توانید دایرکتوری کاری خود را به این commit بازنشانی کنید:

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 как описано выше

ایجاد commit در یک شعبه جدید، ساخت و تست به صورت محلی

ما می‌خواهیم تست‌ها را برای اجرا قبل از commit تنظیم کنیم و سپس کد را commit کنیم.

سناریوهای معمولی زمانی که تست ها به طور خودکار اجرا می شوند

• به صورت محلی:
  • به طور مداوم یا در پاسخ به تغییرات کد مناسب؛
  • در ذخیره (برای زبان های تفسیر شده یا JIT-کامپایل شده)؛
  • در طول مونتاژ (زمانی که تدوین مورد نیاز است)؛
  • در تعهد؛
  • هنگام انتشار در یک مخزن مشترک.

• در سرور ساخت یا محیط ساخت:
  • زمانی که کد در یک شعبه/مخزن شخصی منتشر می شود.
  • کد موجود در این تاپیک در حال آزمایش است.
  • نتیجه بالقوه ادغام آزمایش می شود (معمولاً با master).
  • به عنوان یک مرحله ادغام پیوسته / خط لوله تحویل مداوم

به طور معمول، هر چه یک مجموعه آزمایشی سریعتر اجرا شود، بیشتر اوقات می توانید آن را اجرا کنید. یک توزیع مرحله معمولی ممکن است شبیه این باشد.

• تست های سریع واحد - در حین ساخت، در خط لوله CI
• تست‌های واحد آهسته، تست‌های کامپوننت سریع و یکپارچه‌سازی - در حال انجام، در خط لوله CI
• قطعات آهسته و تست های یکپارچه سازی - در خط لوله CI
• تست امنیتی، آزمایش بار و سایر آزمایش‌های زمان‌بر یا گران قیمت - در خطوط لوله CI/CD، اما فقط در حالت‌ها/مراحل/خطوط لوله‌های خاص ساخت، به عنوان مثال، هنگام آماده‌سازی یک نامزد انتشار یا هنگام اجرای دستی.

️تکلیف

پیشنهاد می کنم ابتدا با استفاده از دستور تست ها را به صورت دستی اجرا کنید npm test. پس از آن، بیایید یک git hook اضافه کنیم تا تست های خود را در commit اجرا کنیم. یک نکته وجود دارد: قلاب‌های Git بخشی از مخزن در نظر گرفته نمی‌شوند و بنابراین نمی‌توان آن‌ها را از GitHub همراه با بقیه مطالب دوره کلون کرد. برای نصب هوک باید اجرا کنید install_hook.sh یا فایل را کپی کنید repo/hooks/pre-commit به دایرکتوری محلی .git/hooks/.
وقتی commit می کنید، می بینید که تست ها اجرا می شوند و بررسی می کنند که آیا کلمات کلیدی خاصی در لیست وجود دارند یا خیر.

1. با اجرای دستور، تست ها را به صورت دستی اجرا کنید npm test در پوشه مخزن دوره شما. بررسی کنید که تست ها کامل شده اند.
2. با دویدن یک قلاب commit (قلاب پیش از ارتکاب) تنظیم کنید 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، این معمولاً با انتشار کار در یک نسخه شخصی از مخزن (چنگال شخصی) یا یک شعبه شخصی به دست می آید.

• با استفاده از فورک‌ها، یک توسعه‌دهنده یک مخزن مشترک از راه دور را شبیه‌سازی می‌کند و یک کپی از راه دور شخصی از آن ایجاد می‌کند که به آن فورک نیز می‌گویند. سپس این مخزن شخصی را شبیه سازی می کند تا به صورت محلی با آن کار کند. هنگامی که کار کامل شد و تعهدات انجام شد، او آنها را به چنگال خود فشار می دهد، جایی که در دسترس دیگران هستند و می توانند در مخزن مشترک ادغام شوند. این رویکرد معمولا در پروژه های متن باز در GitHub استفاده می شود. همچنین در دوره پیشرفته من [Team Work and CI with Git] استفاده می شود (http://devops.redpill.solutions/).
• روش دیگر استفاده از تنها یک مخزن راه دور و شمارش شعبه است master مخزن مشترک "محافظت شده". در این سناریو، توسعه دهندگان فردی کد خود را در شاخه های یک مخزن راه دور منتشر می کنند تا دیگران بتوانند به این کد نگاه کنند، اگر همه چیز درست است، آن را با master مخزن مشترک

در این دوره خاص، ما از یک گردش کاری استفاده خواهیم کرد که از شاخه ها استفاده می کند.

بیایید کد خود را منتشر کنیم.

️تکلیف

• تغییرات را در یک شعبه راه دور با همان نام شعبه کاری خود منتشر کنید

تیم

git push --set-upstream origin feature

یک درخواست کشش ایجاد کنید

یک درخواست کشش با عنوان ایجاد کنید بررسی مراحل... نصب feature مانند «شاخه سر» و master مانند "شاخه پایه".

مطمئن شوید که نصب کرده اید master در او مخزن را چنگال کنید من به عنوان یک "شاخه پایه" به درخواست های تغییر در مخزن مواد درسی پاسخ نخواهم داد.

در زبان GitHub، "شاخه پایه" شاخه ای است که کار خود را بر اساس آن قرار می دهید، و "شاخه سر" شاخه ای است که شامل تغییرات پیشنهادی است.

تغییرات را مورد بحث قرار دهید، با ادامه بحث، commit های جدید اضافه کنید

درخواست کشش (PR)

درخواست کشش (PR) راهی برای بحث و مستندسازی کد و همچنین انجام بررسی کد است. درخواست‌های کششی بر اساس روش کلی ادغام تغییرات فردی در کد کلی نامگذاری می‌شوند. به طور معمول، شخصی مخزن رسمی پروژه از راه دور را شبیه سازی می کند و روی کد به صورت محلی کار می کند. پس از این، او کد را در مخزن از راه دور شخصی خود قرار می دهد و از مسئولین مخزن رسمی می خواهد که آن را دریافت کنند (کشیدن) کد آن در مخازن محلی خود، جایی که آنها بررسی و احتمالاً یکپارچه می شوند (ادغام کردن) خود. این مفهوم با نام های دیگری نیز شناخته می شود، به عنوان مثال، درخواست ادغام.

در واقع لازم نیست از ویژگی درخواست کشش GitHub یا پلتفرم های مشابه استفاده کنید. تیم‌های توسعه ممکن است از روش‌های ارتباطی دیگر، از جمله ارتباط رو در رو، تماس‌های صوتی یا ایمیل استفاده کنند، اما هنوز دلایل زیادی برای استفاده از درخواست‌های جذب به سبک انجمن وجود دارد. در اینجا به برخی از آنها اشاره می کنیم:

• بحث های سازماندهی شده مربوط به تغییرات کد خاص؛
• به‌عنوان مکانی برای مشاهده بازخورد در مورد کارهای در حال انجام از سوی تست‌کنندگان خودکار و همتایان؛
• رسمی کردن بررسی کد؛
• تا بعداً بتوانید دلایل و ملاحظات پشت این یا آن کد را دریابید.

معمولاً زمانی که نیاز به بحث در مورد چیزی یا دریافت بازخورد دارید، یک درخواست کشش ایجاد می کنید. برای مثال، اگر روی یک ویژگی کار می‌کنید که می‌تواند به بیش از یک روش پیاده‌سازی شود، می‌توانید قبل از نوشتن اولین خط کد، یک درخواست کشش ایجاد کنید تا ایده‌های خود را به اشتراک بگذارید و در مورد برنامه‌هایتان با همکارانتان بحث کنید. اگر کار ساده‌تر باشد، زمانی که کاری قبلاً انجام شده باشد، تعهد شده باشد و بتوان در مورد آن بحث کرد، درخواست کشش باز می‌شود. در برخی از سناریوها، ممکن است بخواهید یک PR را فقط به دلایل کنترل کیفیت باز کنید: برای اجرای آزمایش‌های خودکار یا شروع بررسی کد. هر تصمیمی که می‌گیرید، فراموش نکنید که در درخواست pull خود، افرادی را که می‌خواهید تأییدشان را @ ذکر کنید.

به طور معمول، هنگام ایجاد یک روابط عمومی، موارد زیر را انجام می دهید.

• مشخص کنید چه چیزی را برای تغییر پیشنهاد می کنید و کجا.
• توضیحی بنویسید که هدف از تغییرات را توضیح دهد. ممکن است بخواهید:
  • هر چیزی مهم که از کد مشخص نیست، یا چیز مفیدی برای درک زمینه، مانند #اشکالات و اعداد commit مربوطه اضافه کنید.
  • @هرکسی را که می‌خواهید با او شروع به کار کنید نامگذاری کنید، یا می‌توانید بعداً در نظرات آنها را @منشن کنید.
  • از همکاران بخواهید در موردی کمک کنند یا موضوع خاصی را بررسی کنند.

هنگامی که 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. روی "حذف شاخه" کلیک کنید، دیگر به آن نیاز نداریم.

این نموداری از commit ها پس از ادغام است.

️ به کار خود ادامه دهید و تست ها را اضافه کنید

همکاری در یک درخواست کشش اغلب منجر به کار اضافی می شود. این معمولاً نتیجه یک بررسی یا بحث کد است، اما در دوره آموزشی ما قصد داریم با افزودن موارد جدید به لیست مراحل CI خود، این را مدل کنیم.

ادغام مداوم معمولاً شامل برخی از پوشش های آزمایشی است. الزامات پوشش آزمون متفاوت است و معمولاً در سندی به نام چیزی مانند "راهنمای مشارکت" یافت می شود. ما آن را ساده نگه می داریم و برای هر خط یک تست در چک لیست خود اضافه می کنیم.

هنگام اجرای تکالیف، ابتدا تست ها را انجام دهید. اگه درست نصب کردی pre-commit زودتر قلاب کنید، تست جدید اضافه شده اجرا خواهد شد، ناموفق خواهد بود و هیچ چیزی متعهد نخواهد شد. توجه داشته باشید که از این طریق می‌دانیم که آزمایش‌های ما واقعاً چیزی را آزمایش می‌کنند. جالب اینجاست که اگر قبل از تست‌ها با کد شروع می‌کردیم، گذراندن تست‌ها می‌تواند به این معنی باشد که کد آن‌طور که انتظار می‌رفت کار می‌کرد یا اینکه تست‌ها در واقع چیزی را آزمایش نمی‌کردند. به علاوه، اگر از ابتدا تست ها را نمی نوشتیم، ممکن بود آنها را به کلی فراموش کنیم، زیرا هیچ چیز آن را به ما یادآوری نمی کرد.

توسعه آزمایش محور (TDD)

TDD نوشتن تست ها را قبل از کد توصیه می کند. یک گردش کار معمولی با استفاده از TDD به این شکل است.

1. یک تست اضافه کنید.
2. همه تست ها را اجرا کنید و مطمئن شوید که تست جدید ناموفق است.
3. کد رو بنویس
4. تست ها را اجرا کنید، مطمئن شوید که تمام تست ها قبول شده اند.
5. کد خود را اصلاح کنید
6. تکرار.

از آنجایی که نتایج آزمایش‌هایی که ناموفق هستند معمولاً با رنگ قرمز نشان داده می‌شوند و آزمایش‌هایی که رد می‌شوند معمولاً با رنگ سبز نشان داده می‌شوند، این چرخه به عنوان یک فاکتور قرمز-سبز نیز شناخته می‌شود.

️تکلیف

ابتدا سعی کنید تست ها را انجام دهید و اجازه دهید آنها با شکست مواجه شوند، سپس متن خود لیست گام های CI را اضافه و commit کنید. خواهید دید که آزمون ها در حال گذراندن هستند ("سبز").
سپس کد جدید را در مخزن راه دور منتشر کنید و آزمایش‌ها را در رابط 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 قلاب نصب شده است، تلاش 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

تضاد را ادغام کنید

به Change Request بروید بررسی مراحل.

با وجود اینکه ما هیچ اشتباهی انجام ندادیم و تست های کد ما با موفقیت انجام شد، هنوز نمی توانیم شاخه را ادغام کنیم feature и master. این به دلیل موضوع دیگر است bugfix با ادغام شد master در حالی که ما روی این روابط عمومی کار می کردیم.
این وضعیتی را ایجاد می کند که در آن شاخه از راه دور master دارای نسخه جدیدتر از نسخه ای است که ما شعبه را بر اساس آن ساخته ایم feature. به همین دلیل ما نمی توانیم فقط HEAD را به عقب برگردانیم master تا انتهای موضوع feature. در این شرایط یا باید ادغام کنیم یا commit ها را اعمال کنیم feature تغییر پایه master. GitHub در واقع می تواند ادغام خودکار را در صورت عدم وجود تداخل انجام دهد. افسوس، در شرایط ما، هر دو شعبه تغییرات رقابتی در پرونده دارند ci.md. این وضعیت به عنوان تضاد ادغام شناخته می شود و ما باید آن را به صورت دستی حل کنیم.

ادغام یا تغییر پایه

ادغام کردن

• یک commit اضافی ایجاد می کند و سابقه کار را ذخیره می کند.
  • تعهدات اصلی شعب را با مهرهای زمانی و نویسندگان اصلی آنها حفظ می کند.
  • SHA commit ها و پیوندها به آنها را در بحث های درخواست تغییر ذخیره می کند.
• نیاز به حل تعارض یکباره دارد.
• داستان را غیر خطی می کند.
  • خواندن داستان ممکن است به دلیل تعداد زیاد شاخه ها (یادآور کابل IDE) دشوار باشد.
  • اشکال زدایی خودکار را دشوارتر می کند، به عنوان مثال. git bisect کمتر مفید - فقط commit ادغام را پیدا می کند.

بازگرداندن

• تکرارها از شاخه فعلی در بالای شاخه پایه یکی پس از دیگری انجام می شود.
  • commit های جدید با SHA های جدید ایجاد می شوند و باعث می شوند که commit ها در GitHub با درخواست های اصلی مطابقت داشته باشند، اما نه با نظرات مربوطه.
  • commit ها را می توان در این فرآیند دوباره ترکیب و اصلاح کرد یا حتی در یکی ادغام کرد.
• تعارض های متعدد ممکن است نیاز به حل و فصل داشته باشد.
• به شما امکان می دهد یک داستان خطی را حفظ کنید.
  • تا زمانی که بدون دلیل منطقی طولانی نباشد، خواندن داستان ممکن است آسان تر باشد.
  • اشکال زدایی و عیب یابی خودکار کمی ساده تر است: آن را ممکن می کند git bisect، می تواند بازگشت خودکار را واضح تر و قابل پیش بینی تر کند.
• نیاز به انتشار یک شعبه با کامیت های مهاجرت شده با پرچم دارد --force هنگامی که با درخواست های کشش استفاده می شود.

به طور معمول، تیم ها توافق می کنند که همیشه از یک استراتژی استفاده کنند که نیاز به ادغام تغییرات دارند. این می تواند یک ادغام "خالص" یا یک commit "خالص" در بالا، یا چیزی در این بین باشد، مانند انجام یک commit در بالا به صورت تعاملی (git rebase -i) به صورت محلی برای شعبه هایی که در مخزن عمومی منتشر نشده اند، اما برای شاخه های "عمومی" ادغام می شوند.

در اینجا از merge استفاده خواهیم کرد.

️تکلیف

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 با یک خطا، که از آن توسعه دهندگان می توانند کار جدید را شروع کنند.

آیا باید به عقب برگردم یا در نسخه بعدی درستش کنم؟

بازگشت به عقب فرآیند استقرار یک نسخه شناخته شده قبلی خوب برای تولید و برگرداندن commit هایی است که حاوی خطا هستند. "تثبیت رو به جلو" اضافه شدن یک اصلاح به است master و در اسرع وقت نسخه جدید را اجرا کنید. از آنجایی که APIها و طرح‌واره‌های پایگاه داده با استفاده از کد برای تولید تغییر می‌کنند، با تحویل مداوم و پوشش آزمایشی خوب، برگشت به عقب معمولاً بسیار دشوارتر و پرخطرتر از اصلاح آن در نسخه بعدی است.

از آنجایی که عقب نشینی در مورد ما خطری ندارد، ما این مسیر را طی خواهیم کرد، زیرا به ما اجازه می دهد

• رفع خطا در محصول در اسرع وقت؛
• ایجاد کد در master بلافاصله برای شروع یک کار جدید مناسب است.

️تکلیف

1. تغییر به شاخه master به صورت محلی
2. مخزن محلی را از مخزن راه دور به روز کنید.
3. تعهد ادغام روابط عمومی را برگردانید بررسی مراحل в master.
4. تغییرات را در یک مخزن راه دور منتشر کنید.

این تاریخچه یک مخزن با ادغام commit برگردانده شده است

تیم

# Переключитесь на ветку 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. خبر بد این است که فهرست ارزشمند مراحل ادغام مداوم ما نیز از بین رفته است. بنابراین، در حالت ایده‌آل، باید اصلاح را در commits از اعمال کنیم feature و آنها را به master همراه با تعمیر

ما می‌توانیم به روش‌های مختلف به مشکل برخورد کنیم:

• commitی را برگردانید که ادغام را خنثی می کند feature с master;
• حرکت از سابق متعهد می شود feature.

تیم های توسعه مختلف در این مورد از رویکردهای متفاوتی استفاده می کنند، اما ما commit های مفید را به یک شعبه جداگانه منتقل می کنیم و یک درخواست کشش جداگانه برای این شاخه جدید ایجاد می کنیم.

️تکلیف

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. متن "with a sneaky bug" را حذف کنید 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