‏پایان کابوس یک برنچ برای هر مشتری

نویسنده مقاله با یه صحنهٔ آشنا شروع می‌کنه: تازه چند ماهه وارد یه شرکت شدی و یکی خیلی عادی می‌گه «راستی، ما برای مشتری‌هامون دوازده تا برنچ جدا داریم». به گفتهٔ اون همه‌چیز بی‌خطر شروع می‌شه — یه مشتری بزرگ یه «تغییر کوچیک» می‌خواد و شما به‌جای فکر کردن، کد رو برنچ می‌کنین.

مشکل اینه که این قابلیت‌های به‌اصطلاح اختصاصی معمولاً ۹۵ درصد شبیه همن و هر درخواست جدید تبدیل می‌شه به یه حفاری باستان‌شناسی که بفهمی کدوم مشتری چی داره. تو تجربهٔ نویسنده، تیم نزدیک ۴۰ درصد زمان توسعه رو فقط صرف سینک کردن برنچ‌ها می‌کرد و یه پچ امنیتی دوساعته می‌شد یه ماجرای دوروزه.

اولین لایه ویوهاست، چون بیشتر سفارشی‌سازی‌ها در عمل فقط ظاهریه. راه دوم اینه که برای هر مشتری یه پوشهٔ ویوی جدا تعریف کنی و مسیر پیش‌فرض رو ته لیست بذاری؛ انعطافش بیشتره ولی هر به‌روزرسانی باید به پوشه‌های اختصاصی هم کپی شه. ساده‌ترین شکلش هم اینه که اگه ویوی اختصاصی وجود داشت ازش استفاده کنی و وگرنه به نسخهٔ پیش‌فرض برگردی:

return View::first(['custom.dashboard', 'dashboard'], $data);

لایهٔ دوم سرویس‌هاست که نویسنده اسمشو نقطهٔ شیرین ماجرا می‌ذاره. به‌جای سفارشی کردن کل اپلیکیشن، فقط پیاده‌سازی سرویسی که با دنیای بیرون کار می‌کنه رو عوض می‌کنی و کانتینر لاراول بقیه‌شو مدیریت می‌کنه:

$this->app->bind(DeploymentService::class, function ($app) {
    $customer = Customer::from(config('app.customer'));
    return match ($customer) {
        Customer::AcmeCorp => new Vercel,
        Customer::GlobalTech => new AWS,
        default => new Heroku,
    };
});

اپلیکیشن فقط متد deploy رو صدا می‌زنه و کاری نداره پشتش کدوم سرویسه؛ اگه API یکی از اون‌ها عوض شه، یه کلاس رو اصلاح می‌کنی نه دوازده برنچ رو.

لایهٔ سوم عوض کردن کل کنترلره؛ نویسنده اسمشو گزینهٔ هسته‌ای می‌ذاره و فقط برای فلوهای واقعاً متفاوت توصیه‌ش می‌کنه، که تو این حالت روت‌ها باید به‌جای کلاس کانکریت به قرارداد اشاره کنن. به گفتهٔ اون این الگو مخصوص لاراول نیست و تو Go و Rust هم با همون ایدهٔ تزریق پیاده‌سازی‌های مختلف از یه اینترفیس جواب می‌ده؛ فقط کانتینر لاراول اجراش رو تمیزتر می‌کنه. جمع‌بندی مقاله اینه که هدف حذف سفارشی‌سازی نیست، پایدار کردنشه.

نکات کلیدی:

• برنچ جدا برای هر مشتری یعنی هر پچ امنیتی باید تو همهٔ برنچ‌ها تکرار شه
• تو تجربهٔ نویسنده حدود ۴۰ درصد زمان تیم صرف سینک کردن برنچ‌ها می‌شد
• ویوی fallback ساده‌ترین لایه برای تغییرات ظاهریه
• بایند کردن پیاده‌سازی‌های مختلف به یه قرارداد، اینتگریشن‌های اختصاصی رو ایزوله می‌کنه
• کنترلر اختصاصی آخرین گزینه‌ست و فقط برای فلوهای واقعاً متفاوت
• هر سه الگو رو می‌شه همزمان و روی یه کدبیس واحد ترکیب کرد