Motoshub · Delivery Process

فرآیند تحویل، تست و کیفیت — از develop تا Product Owner

خط لوله‌ی الزامی برای هر تسکِ هر دو تیم — به همراه محیط‌ها، نقش‌ها و قواعد ریلیز. مرجع تسک‌ها: Front · Backend

✓

پایپ‌لاین تحویل و کیفیت (الزامی برای هر دو تیم)

هیچ تسکی «انجام‌شده» نیست مگر از همه‌ی این گیت‌ها عبور کند. هدف: کارِ اضافه نه، اما هر کاری که انجام می‌شود چندبار و در چند لایه تست شده باشد. هر گیت مسئول مشخص دارد و هیچ مرحله‌ای «به عهده‌ی بعداً» نیست.

◆ مسیر عبور هر تسک (Front و Backend یکسان)

#	گیت	مسئول	معیار عبور (بدون ابهام)
۱	آماده‌ی شروع (DoR)	PO	تسک شماره‌ی issue دارد؛ User Story + معیارهای پذیرش در همین صفحه/ایشو مشخص است؛ وابستگی‌هایش باز نیست. تسکِ بدون معیار پذیرش شروع نمی‌شود.
۲	توسعه روی برنچ ایشو	Dev	برنچ `issue-N` از `main`؛ کامیت‌ها با پیشوند `#N`. مستقیم روی main کامیت ممنوع (CI هم بلاک می‌کند).
۳	تستِ لایه‌ی ۱ — واحد	Dev	Backend: تست pytest/Pest برای هر endpoint جدید (سناریو موفق + ۴۰۱/۴۰۳/۴۲۲ + یک edge). Front: تست کامپوننت برای منطق غیربدیهی + `tsc` و ESLint سبز. کدِ بدون تستِ همراه، merge نمی‌شود.
۴	Self-review + چک‌لیست MR	Dev	قالب MR پر شده: «چه چیزی، چرا، چطور تست شد» + برای Front اسکرین‌شات/فیلم قبل‌وبعد (لایت و دارک، دسکتاپ و ۳۷۵px) + برای Backend نمونه‌ی curl درخواست/پاسخ.
۵	CI سبز — لایه‌ی ۲	خودکار	lint + type-check + کل تست‌ها + build + (Backend: تستِ قرارداد علیه OpenAPI؛ Front: build بدون warning جدید). قرمز = merge غیرممکن.
۶	Code review همتا	Dev دوم	حداقل ۱ تایید از غیرنویسنده؛ SLA بررسی ۲۴ ساعت کاری. تمرکز review: درستی، امنیت (IDOR/مجوز)، سازگاری با قراردادِ پاکت پاسخ.
۷	Merge به main → دیپلوی staging خودکار	خودکار	Front: motonextfront.shub.ir · Backend: motonext staging. دیپلوی شکسته = بازگردانی فوری (revert اول، دیباگ بعد).
۸	تستِ لایه‌ی ۳ — پذیرش روی staging	PO / QA	اجرای معیارهای پذیرش روی staging: Front در دو مرورگر + موبایل واقعی؛ Backend با کالکشن Postman ماژول (همه‌ی حالت‌ها). فقط بعد از این تیک، وضعیت تسک «انجام‌شده» می‌شود.
۹	رگرسیون هفتگی	تیم (چرخشی)	پایان هر هفته: چک‌لیست ۳۰ دقیقه‌ای مسیرهای حیاتی (ورود، فید، ایجاد محتوا، چت، آپلود، اعلان) روی staging. شکستِ رگرسیون = اولویت P1 هفته‌ی بعد.

◆ قواعد مکمل کیفیت

هشدارِ اجراییِ گیت‌های ۷ و ۸ (۱۴۰۵/۰۵/۱۱). دو مقصدِ staging که در این خط لوله آمده‌اند — motonextfront.shub.ir و staging Django — امروز رکورد DNS ندارند. تا ساخته‌نشدنشان، «دیپلوی خودکار پس از merge» و «پذیرش PO روی staging» قابلِ اجرا نیستند و عملاً تسک‌ها بدونِ گیتِ پذیرش بسته می‌شوند. راستی‌آزمایی: وضعیت زنده.

قانون باگ. هر باگی که پیدا شد، اول یک تستِ بازتولیدکننده نوشته می‌شود که قرمز شود، بعد فیکس — تا همان باگ هیچ‌وقت برنگردد.

تعریفِ «انجام‌شده» (DoD). کد merge شده + تست‌های هر سه لایه پاس + روی staging توسط PO پذیرفته + بدون TODO/console.log باقی‌مانده + مستند (endpoint جدید در Swagger / کامپوننت جدید با props مستند).

بدون کار اضافه. هر چیزی خارج از معیارهای پذیرشِ تسک = تسک جدید برای PO؛ داخل همان MR نمی‌آید. MRهای بزرگ‌تر از ~۴۰۰ خط تغییر باید شکسته شوند.

ادغام مکرر. برنچ ایشو بیش از ۳ روز کاری زنده نمی‌ماند؛ کار بزرگ‌تر از آن یعنی تسک درست شکسته نشده (برگشت به گیت ۱).

⇄

جریان کامل: از develop تا تحویل به Product Owner

محیط	چه چیزی آنجاست	چه کسی/چه زمانی
لوکال توسعه‌دهنده	برنچ issue-N + تست‌های واحد سبز	Dev — حین توسعه
CI (هر push)	lint + type + کل تست‌ها + build + تست قرارداد	خودکار — گیت merge
Staging	Front: motonextfront.shub.ir · API: motonext staging — دیپلوی خودکار از main	خودکار بعد از merge
پذیرش PO	اجرای معیارهای پذیرش روی staging؛ فقط بعد از این تیک، تسک «انجام‌شده» است	PO/QA — حداکثر ۴۸ ساعت بعد از merge
Production	ریلیز برچسب‌خورده؛ سوییچ Gateway برای مسیرهای Django-آماده	DevOps — پس از تایید PO، پنجره‌ی هفتگی

نقش‌ها. مالک هر workstream ثابت است (جدول در صفحه‌ی تسک‌ها)؛ QA مالک گیت‌های ۸-۹؛ DevOps مالک CI/استقرار/سوییچ Gateway؛ PO مالک DoR و پذیرش نهایی.

ریلیز و برگشت. هر ریلیز production یک tag دارد؛ رول‌بک = برگرداندن tag قبلی + برگرداندن سوییچ‌های Gateway. هیچ hotfix بدون تست بازتولیدکننده merge نمی‌شود.