تصور کنید یک حلقه توسعه را در نظر بگیرید که در آن هر عامل کدنویس هوش مصنوعی (AI Coding Agent) و هر درخواست تغییر کد (Pull Request)، در دیتابیس Postgres موقت و کاملاً مجزای خود عمل میکند. Databricks در ۸ اکتبر ۲۰۲۶ از این رویکرد پرده برداشت تا گلوگاه «دیتابیس مشترک» را بشکند و تضمین کند که عاملهای کدنویس موازی، به اندازه محیطهایی که در آن حضور دارند، مؤثر عمل کنند.
در گردشکارهای توسعه سنتی، برنامهنویسان به دیتابیسهای مشترک در محیطهای Staging یا Development تکیه میکنند. وقتی چندین توسعهدهنده انسانی — و اکنون عاملهای هوش مصنوعی با سرعت بالا — بهطور همزمان فعالیت میکنند، اغلب بر سر تغییرات طرحواره (Schema) با یکدیگر تداخل پیدا میکنند یا به مدلهای شبیهسازیشدهای (Mocks) متکی میشوند که در بازتاب واقعیت محیط تولید (Production) شکست میخورند. این اصطکاک در محیطهای عاملمحور (Agentic) که سرعت و حجم عملیات در آنها بسیار بیشتر از انسان است، تشدید میشود. عاملها به محیطهای امنی نیاز دارند که از به خطر افتادن دادههای تولید یا افشای اطلاعات حساس جلوگیری کند. این نیاز به امنیت دادهها در محیطهای عاملمحور، یادآور رویکرد شرکت Decagon است که برای افزایش حاکمیت دادهها، استراتژی حذف کپی دادهها را پیادهسازی کرد.
مکانیسمهای شاخهبندی در Lakebase
Lakebase یک سرویس Postgres کاملاً مدیریتشده و بدون سرور (Serverless) است که بهجای استفاده از یک نسخه تغییریافته (Fork)، از موتور متنباز Postgres استفاده میکند. نوآوری اصلی آن در «شاخهبندی کپی-در-زمان-نوشتن» (Copy-on-Write Branching) نهفته است که به کاربر اجازه میدهد یک دیتابیس کامل را، بدون توجه به حجم کل دادهها، در کمتر از یک ثانیه شاخه (Branch) کند.
جزئیات فنی این سیستم به شرح زیر است:
- بهینگی ذخیرهسازی: شاخههای جدید، طرحواره و دادههای والد را ارثبری میکنند. آنها در لایههای زیرین از فضای ذخیرهسازی مشترک استفاده میکنند و تنها زمانی که دادهها واگرا شوند و تغییر کنند، فضای اضافی اشغال میکنند.
- ایزولاسیون کامل: جداسازی تا سطح وضعیتهای نقشهای Postgres (Role States) گسترش مییابد. نقشها و دیتابیسهای ایجاد شده، دستورات GRANT و REVOKE اعمال شده، یا تغییر در ویژگیهای نقش در یک شاخه، هیچ تأثیری بر سایر شاخهها ندارند.
- مقیاسپذیری محاسبات: هر شاخه دارای منابع محاسباتی (Compute) اختصاصی است که در زمان بیکاری به صفر میرسد (Scale to Zero). این امر تضمین میکند که هزینهها تنها در ساعات فعال بودن اعمال شوند.
- منطق صورتحساب: شاخههای دارای تاریخ انقضا تنها برای دادههای تغییریافته هزینه دارند، در حالی که شاخههای دائمی (بدون انقضا) مشابه یک دیتابیس مستقل، برای کل حجم خود صورتحساب میشوند.
- سلسلهمراتب شاخهها: هر پروژه با یک شاخه پیشفرض به نام "production" آغاز میشود. هر شاخه بهجز ریشه (Root)، یک والد دارد و تغییرات در یک شاخه فرزند هرگز بر والد آن تأثیر نمیگذارد.
- بازیابی و بازنشانی: بازنشانی یک شاخه (Branch Reset)، فرزند را از والد بهصورت یکطرفه بهروزرسانی میکند. بازیابی در نقطه زمانی (Point-in-time recovery) یک شاخه ریشه جدید از دادههای تاریخی در یک پنجره بازگردانی ایجاد میکند، در حالی که شاخه اصلی همچنان فعال میماند.
گردشکار «یک شاخه برای هر عامل»
Databricks برای حذف تداخلات در سطح فایل و دیتابیس، Git Worktrees را با شاخههای Lakebase جفت میکند. یک Worktree به هر عامل دایرکتوری اختصاصی خود را میدهد که شاخه مربوطه در آن Checkout شده است. در یک مثال عملی با استفاده از Claude Code، عامل دستور claude -worktree feature-123 را اجرا میکند. در این لحظه، Git یک Worktree میسازد و یک قلاب (Hook) پس از Checkout بهطور خودکار یک شاخه دیتابیس متناظر را در Lakebase فعال میکند. این قابلیت در راستای تحولاتی است که آنتروپیک با بازطراحی Projects برای تبدیل دستیار چت به یک موتور ارکستراسیون ایجاد کرده است.
برای هدایت رفتار عامل، این گردشکار از فایلهای دستورالعمل مخزن مانند AGENTS.md یا CLAUDE.md استفاده میکند. هنگامی که عامل تسک خود را به پایان رساند، یک Pull Request باز میکند. در این نقطه، هم Git Worktree و هم شاخه دیتابیس Lakebase بازنشسته و حذف میشوند.
از آنجایی که تطبیق دادههای واگرا اغلب غیرعملی است، شاخههای Lakebase به شاخه اصلی ادغام (Merge) نمیشوند. در عوض، تغییرات طرحواره بهعنوان کد و از طریق ابزارهای مهاجرت (Migration) مانند Drizzle، Flyway، Liquibase یا Alembic ردیابی میشوند. در مثال Drizzle، عامل مهاجرت را به کدبیس اضافه میکند و اتوماسیون استقرار، آن را ابتدا روی اپلیکیشن پیشنمایش و سپس هنگام ادغام تغییرات در شاخه main اعمال میکند.
یکپارچگی CI/CD و Pull Request
برای یکپارچگی مداوم، Databricks یک گردشکار GitHub Actions را پیادهسازی کرده است. باز کردن یک Pull Request علیه شاخه main، باعث میشود CLIِ Lakebase یک شاخه فرزند موقت از دیتابیس تولید بسازد که نام آن بر اساس نام Pull Request تعیین میشود.
سپس اتوماسیون، مهاجرتهای لازم را روی این شاخه اعمال کرده و یک اپلیکیشن پیشنمایش (Preview App) را که به رشته اتصال (Connection String) این شاخه اشاره میکند، مستقر میسازد. یک تفاوتسنج (Diff) از طرحواره بهطور خودکار تولید شده و بهعنوان کامنت در Pull Request درج میشود تا دقیقاً مشخص شود کدام جداول، ستونها یا ایندکسها پیش از رسیدن کد به محیط تولید تغییر کردهاند.
اگرچه در این مثال از Databricks Apps استفاده شده است، اما شرکت اشاره میکند که این سیستم با سایر پلتفرمهای میزبانی مانند Vercel، Netlify یا Cloudflare نیز سازگار است. در مورد ساختار محیط، یک پیکربندی رایج استفاده از یک Workspace دیتابریکس برای هر محیط (توسعه، Staging و تولید) است، هرچند در این راهنما برای سادگی از یک Workspace واحد استفاده شده است.
اعتبارسنجی تولید و شکار باگها
فراتر از حلقههای عاملمحور، سیستم شاخهبندی امکان عیبیابی ایمنتر در محیط تولید را فراهم میکند. توسعهدهندگان میتوانند یک شاخه ایزوله از محیط تولید در یک نقطه زمانی خاص — معمولاً درست قبل از ظهور یک باگ — ایجاد کنند تا مشکل را با دادههای واقعی بازتولید و بررسی کنند، بدون اینکه محیط زنده را به خطر اندازند.
تیمها همچنین میتوانند از این شاخهها برای تأیید مهاجرتهای طرحواره استفاده کنند. با اعمال یک مهاجرت روی شاخهای مشتق شده از تولید و اجرای تستها، آنها میتوانند رفتار اپلیکیشن را پیش از ارتقای نهایی اعتبارسنجی کنند. برای محافظت از اطلاعات حساس (PII)، Databricks پیشنهاد میکند بهجای دیتابیس تولید، از یک دیتابیس Seed شده (دادههای مصنوعی) یا ماسکگذاری Unity Catalog استفاده شود.
این تغییر، صنعت را از مدل «دیتابیس توسعه مشترک» به سمت مدل «زیرساخت یکبارمصرف» (Disposable Infrastructure) سوق میدهد. با تبدیل دیتابیس به یک آرتیفکت نسخهبندیشده مشابه کد، Databricks اصلیترین مانع همگامسازی در مهندسی نرمافزار عاملمحور را حذف کرده است. این رویکرد در مقیاس وسیعتر با چشمانداز آنتروپیک برای هماهنگی هزاران عامل هوش مصنوعی در گردشکارهای پویا همسو است. این «حلقه توسعه Lakebase» شامل یک شاخه برای هر عامل، یک شاخه برای هر Pull Request و شاخههای ایزوله برای اعتبارسنجی تولید است.
برای کسانی که قصد پیادهسازی این سیستم را دارند، نمونههای کامل پیادهسازی در دایرکتوری Lakebase-Agentic-CI در مخزن گیتهاب databricks/tmm در دسترس است.




گفتگو