شاردینگ زمانمحور Pest رو توی Bitbucket Pipelines راه بندازیم
تست
پیاچپیخلاصهٔ کاملتر
اپلیکیشن اصلی این تیم بیش از ۱۵۰۰ تست و ۲۰۰+ مایگریشن داره و اجرای کامل سوئیت توی CI روی رانرهای دو-هستهای پیشفرض Bitbucket حدود ۲۴ دقیقه طول میکشه؛ یعنی ۲۴ دقیقه انتظار برای یه تیک سبز. وقتی Pest 4.6 با توزیع شارد زمانمحور اومد، تیم سریع سراغش رفت و این مقاله نتیجهی اون نیمروز کشمکش با مشکلات مخصوص Bitbucketه که هیچجا مستند نشده (داکیومنت Pest روی GitHub Actions تمرکز داره).
مسئله این بود: قبل از ۴.۶، پرچم --shard تستها رو بر اساس تعداد فایل تقسیم میکرد. چهار شارد، چهل فایل تست، هر شارد ده فایل. تا وقتی نفهمی یه فایل یه تست یکپارچهی ۱۸۰ ثانیهای داره و اون نُهتای دیگه دو ثانیهای تموم میشن، عادلانه به نظر میرسه. نتیجه: یه شارد سه دقیقه میدوه و سهتای دیگه بیست ثانیهای تموم میشن.
شاردینگ زمانمحور این رو حل میکنه. زمان واقعی اجرا رو توی یه فایل tests/.pest/shards.json ثبت میکنی، commitش میکنی، و Pest از این زمانبندیها استفاده میکنه تا شاردها رو بر اساس مدتزمان دیواری (wall-clock) متوازن کنه نه تعداد فایل. نتیجه اینه که همهی شاردها تقریباً همزمان تموم میشن.
برای تولید دادهی زمانبندی، سوئیت رو یه بار با پرچم --update-shards اجرا میکنی:
./vendor/bin/pest --parallel --update-shardsاین یه فایل shards.json تولید میکنه که داخلش یه آبجکت timings با زمان اجرای هر بخش هست. باقی مقاله قدمبهقدم راهاندازی و تکتک تلههایی که تیم توی Bitbucket Pipelines بهشون خورده رو شرح میده تا تو مجبور نباشی همون مسیر رو دوباره بری.
نکات کلیدی:
- Pest 4.6 شاردها رو بر اساس زمان واقعی اجرا متوازن میکنه، نه تعداد فایل
- مشکل قبلی: یه فایل کند کنار چند فایل سریع، شاردها رو نامتوازن میکرد
- زمانبندیها توی tests/.pest/shards.json ثبت و commit میشن
- داکیومنت Pest روی GitHub Actions تمرکز داره؛ این مقاله تلههای Bitbucket رو پر میکنه
