Cộng tác qua Git

Data model của Hackolade được lưu ở định dạng JSON (JavaScript Object Notation) mở, không độc quyền. Điều này nghe kỹ thuật nhưng hệ quả rất thực tế: model là file văn bản, nên nó quản lý phiên bản được bằng Git y như source code — ai sửa gì, khi nào, vì sao, đều truy vết được. Hãng gọi triết lý này là “Metadata-as-Code”: metadata (ở đây là data model) được đối xử như code, nằm cạnh code trong cùng hệ thống version control.

Tính năng Repository tích hợp sẵn trong Hackolade Studio, và chỉ có ở Workgroup Edition.

Git trong 60 giây (cho người chưa dùng)

Nếu bạn là BA (Business Analyst) hay data architect chưa quen Git, chỉ cần nắm bốn khái niệm:

• Repository (repo): kho chứa file có lưu toàn bộ lịch sử thay đổi.
• Branch (nhánh): bản sao làm việc riêng trong repo — bạn sửa thoải mái trên nhánh của mình mà không đụng vào bản chính, xong mới xin nhập lại.
• Commit: một “điểm lưu” có ghi chú, chốt lại các thay đổi tại một thời điểm; push là đẩy các commit đó lên repo trung tâm.
• PR (Pull Request): lời đề nghị “hãy nhập thay đổi ở nhánh của tôi vào bản chính”, kèm màn hình cho người khác xem diff và duyệt trước khi nhập.

Điểm dễ chịu là Hackolade Studio bọc các thao tác này trong giao diện ứng dụng — bạn clone, tạo branch, commit, push/pull ngay trong tool, không phải gõ lệnh Git.

Kết nối với Git provider nào?

Tài liệu hãng nêu rõ bốn nền tảng được hỗ trợ, mỗi nền tảng có hướng dẫn cấu hình riêng:

Provider	Ghi chú
GitHub
GitLab
Bitbucket	Cả bản Cloud và Data Center (tự host)
Azure DevOps Repos

Hackolade cung cấp hai chế độ làm việc với repo:

• Làm việc trực tiếp với remote repo — giao diện đơn giản cho người thỉnh thoảng mới tương tác Git: kết nối provider, duyệt/tìm model trong repo và mở trực tiếp, lưu model mới hoặc đã sửa thẳng lên repo. Đổi lại, chế độ này mất một số lợi ích từ bản chất phân tán của Git.
• Làm việc với repo clone về máy — quy trình đầy đủ hơn: làm việc offline được, commit nhiều file một lần, phù hợp người dùng thường xuyên.

Workflow đề xuất: review schema như review code

Quy trình chuẩn cho một thay đổi schema — ví dụ thêm entity “Hạn mức tín dụng” vào model của một ngân hàng:

gitGraph
   commit id: "model v1.0"
   commit id: "phát hành prod"
   branch them-han-muc-tin-dung
   checkout them-han-muc-tin-dung
   commit id: "thêm entity Hạn mức"
   commit id: "sửa theo góp ý review"
   checkout main
   merge them-han-muc-tin-dung id: "PR được duyệt"
   commit id: "model v1.1"

1. Clone/kết nối repo chứa model dùng chung của team.
2. Tạo branch cho thay đổi của bạn — bản chính (main) không bị ảnh hưởng.
3. Sửa model trong Hackolade Studio như bình thường.
4. Commit và push: ứng dụng có màn hình review lại chính các thay đổi của bạn trước khi commit.
5. Mở PR — trong Hackolade gọi là “submit for review”: đồng nghiệp dùng màn hình “review change requests” để xem diff schema và góp ý/duyệt.
6. Merge vào bản chính sau khi được duyệt; nếu hai người cùng sửa một chỗ, tool có giao diện giải quyết conflict.

Vì sao cách này giảm sự cố?

Một cột bị đổi kiểu dữ liệu hay một field bị xóa có thể làm gãy ứng dụng, báo cáo và pipeline phía sau — mức thiệt hại không kém một bug code. Khi mọi thay đổi schema buộc phải đi qua PR, bạn có: một người thứ hai soát lại trước khi thay đổi thành “chính thức”, lịch sử đầy đủ ai-đổi-gì-vì-sao để lần ngược khi có sự cố, và khả năng quay về phiên bản trước. Thay đổi âm thầm — nguồn gốc phổ biến của schema drift — biến mất khỏi quy trình.

Nhiều vai trò trên cùng một repo

Cùng một repo model, mỗi vai trò tham gia một khâu: data architect thiết kế và giữ chuẩn trên nhánh chính; BA bổ sung mô tả nghiệp vụ, business name trên nhánh riêng rồi submit for review; DBA (Database Administrator) review các PR chạm đến kiểu dữ liệu, index, ràng buộc trước khi duyệt. Kết quả là model dùng chung tiến hóa có kiểm soát, thay vì mỗi người giữ một bản copy trên máy và định kỳ “khổ sở” hợp nhất tay.

Các sai lầm dễ mắc phải

• Gửi file model qua email/chat thay vì dùng repo. Chỉ sau vài vòng là xuất hiện model_final_v2_moi_nhat.json và không ai biết bản nào chuẩn. Repo trung tâm + branch giải quyết tận gốc.
• Sửa thẳng trên bản chính. Làm việc lâu ngày trực tiếp trên main khiến thay đổi dở dang lẫn với bản chính thức. Tạo branch cho từng thay đổi — chi phí gần bằng không.
• PR không có người review đúng chuyên môn. PR đổi kiểu dữ liệu mà không có DBA xem thì chỉ là hình thức. Quy ước rõ loại thay đổi nào cần vai trò nào duyệt.

Nguồn tham khảo

• Repository
• Working directly with a remote repo

BSD Insight là đối tác triển khai Hackolade tại Việt Nam — liên hệ tư vấn.