Databricks Chi Tiết Về Phân Nhánh Lakebase cho Các Agent Lập Trình Song Song

Vào ngày 8 tháng 10 năm 2026, Databricks đã công bố một bài đăng trên blog chi tiết quy trình phát triển trong đó mỗi agent lập trình song song và mỗi pull request đều chạy trên một cơ sở dữ liệu Postgres riêng biệt, tạm thời, được tạo thông qua cơ chế phân nhánh copy-on-write được tích hợp trong dịch vụ cơ sở dữ liệu Lakebase của nó.

Trong bài đăng, Databricks mô tả cơ sở dữ liệu như một phần thường bị bỏ qua trong quy trình phát triển vào thời điểm các agent lập trình đang đảm nhận ngày càng nhiều công việc phát triển và việc chạy nhiều agent song song đang trở thành tiêu chuẩn. Với các môi trường chia sẻ truyền thống, chẳng hạn như một cơ sở dữ liệu phát triển hoặc staging duy nhất, các agent đồng thời có thể xung đột về thay đổi schema, can thiệp lẫn nhau, hoặc dựa vào các mock không phản ánh dữ liệu thực tế. Những vấn đề này đã là nỗi đau cho các nhà phát triển, bài đăng cho biết, nhưng các agent làm chúng trở nên tồi tệ hơn vì chúng di chuyển nhanh hơn, hoạt động song song và cần một môi trường an toàn để tránh đặt dữ liệu sản xuất vào nguy cơ hoặc lộ dữ liệu nhạy cảm.

Cơ Chế Phân Nhánh

Databricks cho biết tính năng phân nhánh Lakebase cho phép người dùng tạo một nhánh cho toàn bộ cơ sở dữ liệu trong chưa đầy một giây, bất kể kích thước. Các nhánh dựa trên lưu trữ copy-on-write: một nhánh mới kế thừa schema và dữ liệu của nhánh cha đồng thời chia sẻ lưu trữ nền, chỉ tiêu thụ thêm dung lượng khi nó phân kỳ. Theo tài liệu phân nhánh Lakebase của Databricks, mỗi dự án được tạo với một nhánh mặc định có tên là production, và mọi nhánh ngoại trừ nhánh gốc đều có một nhánh cha. Các thay đổi trong một nhánh con không bao giờ ảnh hưởng đến nhánh cha, và mức độ cô lập mở rộng tới trạng thái role của Postgres: các role và cơ sở dữ liệu được tạo, GRANT và REVOKE được áp dụng, và các thuộc tính role được sửa đổi trên một nhánh sẽ không ảnh hưởng đến các nhánh khác.

Mỗi nhánh có bộ tính toán riêng, tự thu nhỏ về zero khi không hoạt động và chỉ bị tính phí cho giờ tính toán thực tế, tài liệu cho biết. Việc tính phí lưu trữ phụ thuộc vào việc nhánh có hết hạn hay không: một nhánh sắp hết hạn chỉ bị tính phí cho dữ liệu đã thay đổi trên nó, trong khi một nhánh vĩnh viễn không có thời gian hết hạn sẽ bị tính phí cho toàn bộ dung lượng dữ liệu, giống như một cơ sở dữ liệu độc lập. Việc đặt lại nhánh, tức là làm mới một nhánh con từ nhánh cha, chỉ hoạt động theo một chiều, từ cha sang con. Khôi phục theo thời điểm tạo ra một nhánh gốc mới từ dữ liệu lịch sử trong khoảng thời gian khôi phục, đồng thời giữ nguyên nhánh gốc ban đầu không thay đổi và vẫn hoạt động.

Trên trang sản phẩm của nó, Databricks mô tả Lakebase là một dịch vụ Postgres được quản lý hoàn toàn, không máy chủ, chạy engine Postgres mã nguồn mở thay vì một nhánh fork.

Một Nhánh Cho Mỗi Agent

Quy trình trong bài đăng kết hợp các worktree của Git với các nhánh Lakebase. Một worktree cung cấp cho mỗi agent một thư mục riêng với nhánh riêng đã được checkout, loại bỏ xung đột ở mức tệp giữa các agent, và một hook sau khi checkout sẽ tự động tạo một nhánh cơ sở dữ liệu cho mỗi worktree mới. Trong ví dụ, được xây dựng bằng Claude Code, một agent chạy claude -worktree feature-123, Git tạo ra worktree, hook được kích hoạt, và agent có được thư mục mã riêng và cơ sở dữ liệu hoàn toàn cô lập của mình. Các tệp hướng dẫn repository như AGENTS.md hoặc CLAUDE.md hướng dẫn hành vi của agent, và khi agent hoàn thành, nó mở một pull request, sau đó cả worktree và nhánh cơ sở dữ liệu đều có thể được gỡ bỏ.

Một điểm khác so với Git, bài đăng lưu ý, là các nhánh Lakebase không được hợp nhất lại vào nhánh chính, vì cả nhánh cha và nhánh con đều có thể thay đổi độc lập và việc đồng bộ dữ liệu của chúng có thể nhanh chóng trở nên không thực tế. Thay vào đó, các thay đổi schema được theo dõi trong mã cùng với logic ứng dụng và được đưa lên nhánh cha thông qua các migration, sử dụng các công cụ như Drizzle, Flyway, Liquibase hoặc Alembic. Ví dụ sử dụng Drizzle: khi cần thay đổi schema, agent thêm migration tương ứng vào codebase, và tự động triển khai áp dụng nó khi triển khai ứng dụng preview và lại khi thay đổi được hợp nhất vào main.

Một Nhánh Cho Mỗi Pull Request

Đối với tích hợp liên tục, bài đăng mô tả một quy trình GitHub Actions trong đó việc mở một pull request đối với nhánh main kích hoạt Lakebase CLI tạo một nhánh tạm thời, đặt tên theo pull request, như một nhánh con của nhánh production, và nhánh này trở thành môi trường cơ sở dữ liệu cho pull request. Công cụ migration chạy trên nhánh mới, một ứng dụng preview được triển khai và trỏ tới chuỗi kết nối của nhánh, và một diff schema được tạo và đăng dưới dạng bình luận pull request, hiển thị chính xác các bảng, cột hoặc chỉ mục đã thay đổi. Khi pull request được đóng hoặc hợp nhất, tự động xóa nhánh. Vì nhánh bắt đầu từ production, migration schema có thể được áp dụng và kiểm thử trước khi thay đổi đến production. Ví dụ triển khai preview trên Databricks Apps, mặc dù bài đăng cho biết khái niệm này áp dụng cho các nền tảng hosting khác như Vercel, Netlify và Cloudflare.

Về môi trường, bài đăng lưu ý rằng cấu hình Lakebase phổ biến sử dụng một workspace Databricks cho mỗi môi trường, chẳng hạn như development, staging và production, và các nhóm thường tạo nhánh từ một cơ sở dữ liệu đã được seed thay vì từ cơ sở dữ liệu production để tránh lộ dữ liệu nhạy cảm như PII. Hướng dẫn này sử dụng một workspace duy nhất để đơn giản hoá, đồng thời lưu ý rằng các khái niệm tương tự áp dụng cho các thiết lập đa workspace.

Sao Chép Lỗi và Kiểm Tra Migration

Ngoài các vòng lặp per-agent và per-pull-request, bài viết mô tả các quy trình nhánh mà không được triển khai trong kho mẫu. Một nhà phát triển có thể tạo một nhánh riêng biệt từ môi trường production tại một thời điểm cụ thể, thường là ngay trước khi một lỗi xuất hiện, sao chép và điều tra vấn đề dựa trên dữ liệu thực, và xóa nhánh sau khi bản sửa lỗi được xác nhận. Các nhóm cũng có thể tạo một nhánh trước khi triển khai lên production, áp dụng một bản di chuyển schema, chạy các bài kiểm tra, và xác minh ứng dụng vẫn hoạt động như mong đợi trước khi đưa thay đổi lên. Những quy trình này cho phép các nhà phát triển làm việc với dữ liệu giống production hoặc dữ liệu được suy ra từ production, ví dụ sử dụng Unity Catalog masking, mà không gây rủi ro cho cơ sở dữ liệu trực tiếp, theo như bài viết nêu.

Bài viết liên kết tới một kho mẫu trên GitHub, trong thư mục Lakebase-Agentic-CI của kho databricks/tmm, chứa các ví dụ workflow GitHub Actions thực hiện mẫu này. Nó kết luận rằng, khi kết hợp, các mẫu này tạo thành cái mà nó gọi là vòng lặp phát triển Lakebase: một nhánh cho mỗi agent, một nhánh cho mỗi pull request, và các nhánh riêng biệt để xác thực production.