کاربر در صحبت ابتدایی خود اشاره کرد:
«تیمهای قدیمی ما همیشه کامیت مستقیم روی برنچ main میزدند و هیچ مشکلی هم نداشتند.
علتش این بود که همه یک سری قوانین را رعایت میکردند. اما الان که پروژهها لایو هستند، یک تغییر اشتباه میتواند به درآمد شرکت ضربه بزند…»
این تجربه کاملاً واقعی است و برای بسیاری از تیمها اتفاق افتاده است.
اما چرا همان روشی که در گذشته «بیضرر» بود، امروزه «خطرناک» شده است؟
در این مقاله به شکل بخشبندیشده و پرسشمحور به این موضوع میپردازیم.
در گذشته بسیاری از تیمها مستقیماً روی main کار میکردند، زیرا:
پروژه هنوز لایو نبود،
کاربری وجود نداشت که آسیب ببیند،
SLA و تعهدات رسمی نبود،
درآمدی در خطر نبود.
به همین دلیل یک باگ معمولاً «کشف» میشد، نه «فاجعهبار».
اما امروز؟
امروز همان باگ کوچک، میتواند در یک سرویس لایو:
پرداخت مشتری را مختل کند،
سفارش را خراب کند،
دیتای حساس را تغییر دهد،
یا هزاران کاربر را گرفتار کند.
پروژهها بزرگتر، عمومیتر، وابستهتر و پولسازتر شدهاند.
این یعنی قوانین توسعه هم باید به همان نسبت ارتقا پیدا کند.
هیچ کاربری وجود نداشت که از باگ آسیب ببیند.
همه اعضا رفتارهای هم را میدانستند و نوعی Code Review طبیعی وجود داشت.
چند فیچر محدود و بدون وابستگی زیاد.
نه دیتابیس بزرگ بود، نه سیستم پیچیده.
نتیجه؟
ریسک خیلی کم بود.
و هر روشی در ریسک پایین جواب میدهد—even bad practices.
وقتی سرویس شما اینترنتی، پرکاربر و درآمدزا است:
دیگر "کشف باگ" نیست؛ "رخداد حادثه" است.
نمیتوان به «حس مشترک» تکیه کرد.
فرآیند لازم است، نه خاطرههای خوب گذشته.
مایکروسرویس، Gateway، SSO، پرداخت، کش، صف، دیتابیس…
یک تغییر اشتباه میتواند زنجیرهای از خطاها ایجاد کند.
دیگر مثل گذشته نیست که یک دیتابیس ساده را برگردانی!
پس طبیعی است که امروز:
Merge Request از یک گزینه اختیاری به یک ضرورت حیاتی تبدیل شده است.
MR علاوه بر merge کردن کد، وظایف زیر را هم دارد:
کد یک نفر دیگر توسط فردی دیگر بررسی میشود.
قبل از رسیدن به main باید pipeline، تست خودکار و lint همه تأیید شوند.
انتشار در main همیشه قابل ردگیری و قابل rollback است.
چندین کامیت مرتبط کنار هم قرار میگیرند و معنای واحد میسازند.
این چیزی است که کاربر هم در متن اولیهاش اشاره کرد:
«اگر همه یک بستهی مرج ریکویست بشن هم راحتتر مرج میشن هم اینکه بعدا میشه برشون گردوند.»
کاملاً درست؛ MR تغییرات را قابل فهم و قابل بازگشت میکند.
کامیتهای کوچک و زیاد خوب هستند، اگر مرتبط باشند.
اشتباه اینجاست:
کامیتهای پراکنده
بدون پیام واضح
بدون وابستگی
روی main
اینها debug و rollback را کابوسوار میکنند.
MR این مشکل را حل میکند:
تغییرات را در یک بسته واحد قرار میدهد.
چرا؟
گذشته امروز پروژههای کوچک و بدون مشتری محصول لایو با هزاران کاربر تیم کوچک تیمهای گسترده و متنوع وابستگی کم معماری پیچیده و حساس ریسک پایین ریسک مالی / امنیتی بالا rollback ساده rollback دشوار و پرخطر
بنابراین:
کامیت مستقیم روی main در پروژههای لایو یک خطر بالقوه است.
Merge Request یک ابزار ضروری برای کنترل ریسک، کیفیت و پایداری سیستم است.
اگر پاسخ به اینها «نه» است، پس MR دیگر یک انتخاب نیست—یک ضرورت است.
تجربههایی که در گذشته برای تیمها بدون مشکل بوده، به معنی درست بودنشان نیست.
محیط توسعه تغییر کرده، ریسکها بزرگتر شده، و فشار روی کیفیت بسیار بیشتر است.
امروز Merge Request ستون فقرات توسعه حرفهای است و هر تیمی که محصول لایو دارد باید آن را جدی بگیرد.
