Databricks รายละเอียดการแยกสาขา Lakebase สำหรับเอเจนต์การเขียนโค้ดแบบขนาน

Databricks เมื่อวันที่ 8 ตุลาคม 2026 เผยแพร่ บทความบล็อก ที่อธิบายขั้นตอนการพัฒนาที่แต่ละเอเจนต์การเขียนโค้ดแบบขนานและแต่ละ pull request ทำงานกับฐานข้อมูล Postgres ที่แยกจากกันและชั่วคราวของตนเอง ซึ่งสร้างขึ้นผ่านการแยกสาขาแบบ copy‑on‑write ที่รวมอยู่ในบริการฐานข้อมูล Lakebase ของมัน

ในบทความนี้ Databricks อธิบายว่าฐานข้อมูลเป็นส่วนที่มักถูกมองข้ามในขั้นตอนการพัฒนาในช่วงที่เอเจนต์การเขียนโค้ดกำลังรับภาระงานพัฒนาที่เพิ่มขึ้นและการรันเอเจนต์หลายตัวแบบขนานกำลังกลายเป็นมาตรฐาน ด้วยสภาพแวดล้อมที่แชร์แบบดั้งเดิม เช่น ฐานข้อมูลการพัฒนาหรือสเตจดิ้งเดียวกัน เอเจนต์ที่ทำงานพร้อมกันอาจขัดแย้งกันในการเปลี่ยนแปลงสกีม่า แทรกแซงกัน หรือพึ่งพา mock ที่ไม่สะท้อนข้อมูลจริงตามโลกภายนอก สิ่งเหล่านี้เป็นปัญหาที่นักพัฒนาต้องเผชิญอยู่แล้วตามที่บทความระบุ แต่เอเจนต์ทำให้ปัญหาเหล่านี้แย่ลงเนื่องจากพวกเขาเคลื่อนที่เร็วขึ้น ทำงานแบบขนาน และต้องการสภาพแวดล้อมที่ปลอดภัยเพื่อหลีกเลี่ยงการเสี่ยงต่อข้อมูลการผลิตหรือการเปิดเผยข้อมูลที่ละเอียดอ่อน

กลไกการแยกสาขา

Databricks ระบุว่าการแยกสาขา Lakebase ทำให้ผู้ใช้สามารถแยกสาขาฐานข้อมูลทั้งหมดได้ในเวลาน้อยกว่า 1 วินาทีโดยไม่คำนึงถึงขนาดของฐานข้อมูล สาขาต่าง ๆ พึ่งพาการจัดเก็บแบบ copy‑on‑write: สาขาใหม่สืบทอดสกีม่าและข้อมูลของพ่อแม่ในขณะที่ใช้ที่เก็บข้อมูลพื้นฐานร่วมกัน และใช้พื้นที่จัดเก็บเพิ่มเติมเฉพาะเมื่อมีการแตกต่าง ตาม เอกสารการแยกสาขา Lakebase ของ Databricks แต่ละโครงการจะถูกสร้างด้วยสาขาเริ่มต้นชื่อ production และสาขาทุกสาขานอกจากสาขารากจะมีพ่อแม่ การเปลี่ยนแปลงในสาขาลูกจะไม่ส่งผลต่อสาขาพ่อแม่ และการแยกกันนี้ขยายไปถึงสถานะบทบาทของ Postgres: บทบาทและฐานข้อมูลที่สร้างขึ้น, การให้สิทธิ์ GRANTs และ REVOKEs ที่ใช้, และแอตทริบิวต์ของบทบาทที่แก้ไขในสาขาหนึ่งจะไม่มีผลต่อสาขาอื่น

แต่ละสาขามีคอมพิวต์ของตนเอง ปรับขนาดเป็นศูนย์เมื่อไม่มีการใช้งาน และเรียกเก็บค่าใช้จ่ายเฉพาะชั่วโมงคอมพิวต์ที่ใช้งานจริงตามที่เอกสารระบุ การเรียกเก็บค่าจัดเก็บข้อมูลขึ้นอยู่กับว่สาขาจะหมดอายุหรือไม่: สาขาที่กำลังจะหมดอายุจะถูกเรียกเก็บเฉพาะข้อมูลที่เปลี่ยนแปลงบนสาขานั้น ส่วนสาขาถาวรที่ไม่มีวันหมดอายุจะถูกเรียกเก็บตามขนาดข้อมูลเต็มของมัน เหมือนฐานข้อมูลอิสระ การรีเซ็ตสาขา ซึ่งรีเฟรชสาขาลูกจากสาขาพ่อแม่ ทำงานในทิศทางเดียวเท่านั้น คือจากพ่อแม่ไปยังลูก การกู้คืนตามจุดเวลา (point‑in‑time recovery) สร้างสาขารากใหม่จากข้อมูลประวัติภายในช่วงเวลาการกู้คืนโดยที่สาขาต้นฉบับยังคงอยู่โดยไม่เปลี่ยนแปลงและพร้อมทำงาน

บน หน้าผลิตภัณฑ์ของ Databricks Databricks อธิบายว่า Lakebase เป็นบริการ Postgres แบบจัดการเต็มรูปแบบและแบบ serverless ที่ทำงานด้วยเอนจิน Postgres แบบโอเพนซอร์สแทนการใช้ฟอร์ก

สาขาหนึ่งต่อเอเจนต์หนึ่ง

ขั้นตอนการทำงานในบทความจับคู่ Git worktrees กับสาขา Lakebase worktree ให้แต่ละเอเจนต์มีไดเรกทอรีของตนเองพร้อมสาขาที่เช็คเอาต์ไว้ ทำให้ขจัดความขัดแย้งระดับไฟล์ระหว่างเอเจนต์ และ hook หลังการเช็คเอาต์จะสร้างสาขาฐานข้อมูลโดยอัตโนมัติสำหรับแต่ละ worktree ใหม่ ในตัวอย่างที่สร้างด้วย Claude Code เอเจนต์จะรัน claude -worktree feature-123Git สร้าง worktree, hook ทำงาน, และเอเจนต์จะได้ไดเรกทอรีโค้ดของตนเองพร้อมฐานข้อมูลที่แยกจากกันอย่างสมบูรณ์ ไฟล์คำแนะนำในรีโพซิทอรี เช่น AGENTS.md หรือ CLAUDE.md ช่วยกำหนดพฤติกรรมของเอเจนต์ และเมื่อเอเจนต์ทำงานเสร็จจะเปิด pull request หลังจากนั้น worktree และสาขาฐานข้อมูลทั้งสองสามารถถูกยกเลิกได้

หนึ่งความแตกต่างจาก Git ที่บทความระบุคือสาขา Lakebase ไม่ได้ถูกรวมกลับเข้าสู่สาขาหลัก เนื่องจากพ่อแม่และลูกสามารถเปลี่ยนแปลงได้อย่างอิสระและการปรับข้อมูลให้ตรงกันอาจกลายเป็นเรื่องยากแทนที่จะทำเช่นนั้น การเปลี่ยนแปลงสกีม่าได้รับการติดตามในโค้ดพร้อมกับตรรกะของแอปพลิเคชันและถูกส่งต่อไปยังสาขาพ่อแม่ผ่านการมิเกรชันโดยใช้เครื่องมือเช่น Drizzle, Flyway, Liquibase หรือ Alembic ตัวอย่างใช้ Drizzle: เมื่อจำเป็นต้องเปลี่ยนสกีม่า เอเจนต์จะเพิ่มมิเกรชันที่สอดคล้องลงในโค้ดเบส และระบบอัตโนมัติของการปรับใช้จะดำเนินการเมื่อติดตั้งแอปพลิเคชัน preview และอีกครั้งเมื่อการเปลี่ยนแปลงถูกรวมเข้าสู่ main

สาขาหนึ่งต่อ Pull Request หนึ่ง

สำหรับการบูรณาการต่อเนื่อง บทความอธิบายขั้นตอนการทำงานของ GitHub Actions ที่การเปิด pull request ต่อ main จะทำให้ Lakebase CLI สร้างสาขาชั่วคราวที่ตั้งชื่อตาม pull request เป็นสาขาลูกของสาขา production และสาขานั้นจะเป็นสภาพแวดล้อมฐานข้อมูลของ pull request เครื่องมือมิเกรชันจะทำงานบนสาขาใหม่ แอปพลิเคชัน preview จะถูกปรับใช้และชี้ไปที่สตริงการเชื่อมต่อของสาขานั้น และการเปรียบเทียบสกีม่า (schema diff) จะถูกสร้างและโพสต์เป็นคอมเมนต์ของ pull‑request เพื่อแสดงว่าตาราง คอลัมน์ หรือดัชนีใดเปลี่ยนแปลง เมื่อ pull request ปิดหรือถูกรวม ระบบอัตโนมัติจะลบสาขานั้นออก เนื่องจากสาขาเริ่มจาก production การมิเกรชันสกีม่าสามารถนำไปใช้และทดสอบก่อนการเปลี่ยนแปลงถึง production ตัวอย่างปรับใช้ preview บน Databricks Apps แม้ว่าบทความระบุแนวคิดนี้สามารถใช้กับแพลตฟอร์มโฮสติ้งอื่น ๆ เช่น Vercel, Netlify, และ Cloudflare

เกี่ยวกับสภาพแวดล้อม บทความระบุว่าการตั้งค่า Lakebase ที่พบบ่อยใช้ Databricks workspace หนึ่งอันต่อสภาพแวดล้อม เช่น development, staging, และ production และทีมมักแยกสาขาจากฐานข้อมูลที่เตรียมไว้ล่วงหน้าแทนฐานข้อมูล production เพื่อหลีกเลี่ยงการเปิดเผยข้อมูลที่ละเอียดอ่อนเช่น PII การสาธิตใช้ workspace เดียวเพื่อความง่าย แต่ชี้ให้เห็นว่าแนวคิดเดียวกันสามารถใช้กับการตั้งค่า multi‑workspace ได้

การทำซ้ำบั๊กและการทดสอบมิเกรชัน

นอกเหนือจากลูป per-agent และ per‑pull‑request แล้วโพสต์นี้อธิบายเวิร์กโฟลว์การแยกสาขาที่ยังไม่ได้ทำในคลังตัวอย่าง นักพัฒนาสามารถสร้างสาขาแยกจาก production ในช่วงเวลาที่กำหนดได้ โดยทั่วไปจะทำก่อนที่บั๊กจะปรากฏขึ้น เพื่อทำการทำซ้ำและสืบสวนปัญหาด้วยข้อมูลจริง และจะลบสาขานั้นเมื่อการแก้ไขได้รับการตรวจสอบแล้ว ทีมงานก็สามารถสร้างสาขาก่อนทำการ deploy ไปยัง production, ใช้การย้ายสคีม่า, รันการทดสอบ, และตรวจสอบว่าแอปพลิเคชันยังทำงานตามที่คาดหวังก่อนที่จะโปรโมตการเปลี่ยนแปลง เวิร์กโฟลว์เหล่านี้ทำให้นักพัฒนาสามารถทำงานกับข้อมูลที่คล้าย production หรือได้มาจาก production เช่น การใช้ Unity Catalog masking โดยไม่ต้องเสี่ยงต่อฐานข้อมูลที่ใช้งานจริง ตามที่โพสต์ระบุ

โพสต์นี้เชื่อมโยงไปยังคลังตัวอย่างบน GitHub ในไดเรกทอรี Lakebase-Agentic-CI ของคลัง databricks/tmm ซึ่งมีตัวอย่าง workflow ของ GitHub Actions ที่ดำเนินการตามรูปแบบนี้ สรุปว่ารูปแบบเหล่านี้ร่วมกันสร้างสิ่งที่ผู้เขียนเรียกว่า Lakebase development loop: สาขาหนึ่งต่อหนึ่งเอเจนต์, สาขาหนึ่งต่อหนึ่ง pull request, และสาขาแยกสำหรับการตรวจสอบ production