Các tập tin cơ sở dữ liệu (script vv) có nên được kiểm soát nguồn không? Nếu vậy, phương pháp tốt nhất để giữ nó và cập nhật nó ở đó là gì?

Thậm chí có cần phải có các tệp cơ sở dữ liệu để kiểm soát nguồn không vì chúng ta có thể đặt nó trên một máy chủ phát triển nơi mọi người có thể sử dụng nó và thay đổi nó nếu cần. Nhưng, sau đó chúng tôi không thể lấy lại nếu ai đó làm hỏng nó.

Cách tiếp cận nào được sử dụng tốt nhất cho cơ sở dữ liệu về kiểm soát nguồn?

Đúng. Bạn sẽ có thể xây dựng lại bất kỳ phần nào trong hệ thống của mình từ kiểm soát nguồn bao gồm cả cơ sở dữ liệu (và tôi cũng tranh luận về dữ liệu tĩnh nhất định).

Giả sử rằng bạn không muốn có một công cụ để làm điều đó, tôi khuyên bạn nên có những điều sau đây:

• Các tập lệnh tạo cho các cấu trúc bảng cơ bản bao gồm lược đồ, người dùng, bảng, khóa, mặc định, v.v.
• Nâng cấp tập lệnh (thay đổi cấu trúc bảng hoặc di chuyển dữ liệu từ lược đồ trước sang lược đồ mới)
• Các tập lệnh tạo cho các thủ tục, chỉ mục, khung nhìn, trình kích hoạt được lưu trữ (bạn không cần lo lắng về việc nâng cấp cho các tập lệnh này khi bạn chỉ ghi đè lên những gì đã có với tập lệnh tạo chính xác)
• Các kịch bản tạo dữ liệu để hệ thống chạy (một người dùng, bất kỳ dữ liệu danh sách chọn tĩnh nào, loại đó)

Tất cả các tập lệnh nên bao gồm các câu lệnh thả thích hợp và được viết để chúng có thể được chạy như bất kỳ người dùng nào (bao gồm các tiền tố lược đồ / chủ sở hữu liên quan nếu có liên quan).

Quá trình cập nhật / gắn thẻ / phân nhánh phải chính xác như phần còn lại của mã nguồn - có rất ít điểm khi thực hiện nếu bạn không thể liên kết phiên bản cơ sở dữ liệu với phiên bản ứng dụng.

Ngẫu nhiên, khi bạn nói mọi người chỉ có thể cập nhật máy chủ thử nghiệm, tôi hy vọng bạn có nghĩa là máy chủ phát triển. Nếu các nhà phát triển đang cập nhật máy chủ thử nghiệm một cách nhanh chóng thì bạn đang nhìn vào một thế giới đau khổ khi tìm ra những gì bạn cần phát hành.

Đúng.

phương pháp tốt nhất để giữ nó và cập nhật nó là gì?

Ừm. Viết một kịch bản xây dựng lược đồ. Kiểm tra nó sau khi thực hiện thay đổi. Kiểm tra nó trước khi chạy nó.

Thật khó để xác định những gì bạn yêu cầu.

Viết kịch bản di chuyển lược đồ chính thức. Kiểm tra chúng sau khi thử nghiệm. Kiểm tra chúng trước khi chạy chúng.

Còn gì nữa không?

Điều xảy ra là các thay đổi lược đồ biến thành các vấn đề sởn gai ốc vì lược đồ tiến hóa hữu cơ thông qua một loạt các thay đổi không có giấy tờ.

Sự tiến hóa hữu cơ này làm cho việc di chuyển lược đồ trở nên khó khăn hơn vì không có nguồn "có thẩm quyền" cho những gì được cho là ở đó. Có hai phiên bản sản xuất hơi khác nhau, phiên bản dàn dựng, phiên bản QA và tám phiên bản phát triển. Tất cả hơi khác nhau.

Nếu có một nguồn duy nhất, có thẩm quyền, thì di chuyển lược đồ chỉ là đồng bằng giữa phiên bản trước và phiên bản này.

Đúng

Các kịch bản cơ sở dữ liệu (ddl, dml) là mã. Tất cả các mã phải nằm trong một hệ thống kiểm soát phiên bản.

Di cư

• Sử dụng di chuyển cơ sở dữ liệu

Cho phép bạn sử dụng cùng các tệp db trong quá trình phát triển, qa và phát hành.

• Phát hành vào cơ sở dữ liệu với một số phát hành

Lưu trữ số phát hành ở đâu đó để kiểm toán, nhiều người lưu nó trong db. Mỗi bản phát hành sẽ bao gồm các lần di chuyển sẽ đưa cơ sở dữ liệu lên đúng phiên bản.

Có những công cụ như liquidibase nhằm cung cấp kiểm soát nguồn cho cơ sở dữ liệu. Thật khó khăn để duy trì các kịch bản thay đổi / cập nhật trong công cụ kiểm soát nguồn thông thường của bạn giống như nhiều công ty làm điều đó và bạn không thể luôn triển khai lại cơ sở dữ liệu từ đầu.

Chúng tôi cũng đã cố gắng tự động hóa việc này với các công cụ so sánh cơ sở dữ liệu (so sánh chủ so với db khách hàng) và điều đó có ích, nhưng bạn không thể tin tưởng 100% các công cụ đó, bạn chắc chắn cũng cần một quy trình xem xét.

Đúng

Và furthemore, bạn sẽ muốn chi nhánh .

Tôi sử dụng Git cho các chi nhánh:

• để phát triển theo từng tính năng (như chúng tôi làm để phát triển thường xuyên phần còn lại của ứng dụng)

• và một cho máy chủ sản xuất vì khách hàng sử dụng ứng dụng cũng tạo ra nội dung.

Bằng cách đó, bạn có được lợi ích từ kiểm soát nguồn và phân nhánh cho cả mã nguồn và cơ sở dữ liệu (và bất kỳ tệp nào khác bạn có).

Tôi chưa tìm thấy một hệ thống tất cả trong một [cho PostgreQuery], vì vậy tôi đã phải viết các hàm / tập lệnh để reindex đúng khi hợp nhất các nhánh (ví dụ: không nên sửa đổi bất kỳ chỉ mục nào từ nhánh sản xuất vì khách hàng phụ thuộc vào chúng trong khi các chỉ mục + khóa ngoại từ nhánh phát triển giao với nội dung sản xuất nên được giới thiệu lại: nó sẽ không hoạt động cho tất cả các ứng dụng, nhưng nó bao gồm tất cả các trường hợp ứng dụng của chúng tôi để nó đủ tốt).

Nhưng ý tưởng chung là nội dung cơ sở dữ liệu là một phần thiết yếu của ứng dụng và tất cả các nguồn tài nguyên phải nằm trong kiểm soát nguồn , vâng, vâng, bạn cũng nên sử dụng kiểm soát nguồn cho cơ sở dữ liệu.

Đối với Java, nhóm của chúng tôi sử dụng Flyway , thứ mà chúng tôi thấy thực sự dễ sử dụng và mạnh mẽ.

Nếu bạn đang làm việc trong Ruby, Rails có Di chuyển cũng là một cách mạnh mẽ để xử lý vấn đề này.

Liquibase đã được đề cập - đó là một giải pháp tốt nhưng tôi thấy nó cồng kềnh hơn so với các lựa chọn thay thế như Flyway.

Ngoài ra, phần mềm RedGate cung cấp một sản phẩm có tên SQL Source Control được thiết kế cho SQL Server. Tôi đã không sử dụng nó cho mình, nhưng một trong những đồng nghiệp của tôi nói rằng nó thật tuyệt.

Đây là vấn đề tôi đã thấy nhiều lần khi không có kiểm soát phiên bản hoặc quản lý thay đổi trên cơ sở dữ liệu phát triển. Lập trình viên A thực hiện thay đổi đối với bảng, dạng xem hoặc Proc. Lập trình viên B thực hiện một thay đổi cho cùng một điều và ghi đè lên những gì Lập trình viên A đã làm. Hoặc, DBA khôi phục DB sản xuất để phát triển và ghi đè các thay đổi. Tôi đã nhìn thấy những thứ này gây ra sự đau buồn đáng kể rất nhiều lần nó không buồn cười. Và điều này chỉ có trên các hệ thống phát triển. Mọi thứ có thể trở nên thực sự lộn xộn khi dàn dựng / thử nghiệm và thậm chí các máy chủ sản xuất bị cuốn vào điều này.

Kiểm soát phiên bản cơ sở dữ liệu không nhất thiết phải giống như kiểm soát phiên bản mã thông thường để có hiệu lực. Tuy nhiên, một số loại kiểm soát thay đổi và sao lưu lịch sử sẽ ngăn chặn nhiều vấn đề.

Hãy nghĩ về nó như là "Kiểm soát phiên bản" thay vì "Kiểm soát nguồn". Điều này ngụ ý rằng bạn có thể thấy toàn bộ lịch sử của tập lệnh cụ thể đó. Việc bạn có thể xây dựng lại cơ sở dữ liệu về hình thức hiện tại hay không sẽ là vấn đề thực tiễn của bạn đối với các tập lệnh này và bất kỳ khung công tác nào được sử dụng để tạo chúng.

Đối với các dự án PHP / MySQL của chúng tôi, chúng tôi đã sử dụng một công cụ nhỏ (một lần) có tên Ladder . Nó được thiết kế để tạo điều kiện cho sự phát triển hữu cơ của cơ sở dữ liệu theo thời gian. Tất cả các di chuyển cho một dự án được lưu trữ trong kiểm soát sửa đổi / nguồn / phiên bản và được theo dõi cùng với mã.

Nó hỗ trợ thêm / thay đổi / thả cột, chạy truy vấn, thêm / xóa chỉ mục, ràng buộc, v.v. Nó sẽ theo dõi trạng thái của cơ sở dữ liệu và áp dụng bất kỳ di chuyển bị thiếu nào. Nó cũng cho phép bạn "quay ngược thời gian" bằng cách chỉ định di chuyển mà bạn cần phải có. ( php ladder.php migrate 15)

Oh, và bổ sung mới nhất là cơ sở dữ liệu khác nhau. Chạy diff-savelệnh, thêm và xóa một số cột khỏi cơ sở dữ liệu và chạy difflệnh của nó . Bạn sẽ thấy mã di chuyển được tạo tự động dựa trên trạng thái cơ sở dữ liệu.

DataGrove giải quyết một số vấn đề được đề cập ở đây ( ví dụ bởi jfrankcarr ).

Nó theo dõi tất cả các thay đổi đối với DB và cho phép bạn lưu phiên bản của toàn bộ trạng thái của DB vào kho lưu trữ. Sau đó, nó cho phép bạn sinh ra nhiều bản sao ảo của cùng một DB, vì vậy mỗi nhà phát triển hoặc DBA có thể có bản sao riêng của mình (mỗi bản sao ảo có thể được sinh ra từ một phiên bản khác nhau). Nó sẽ đảm bảo không ai ghi đè mã / thay đổi của người khác. Mỗi một bản sao ảo cũng được theo dõi vào cùng một kho lưu trữ để tất cả các trạng thái DB có thể dễ dàng chia sẻ và tạo lại.

Tôi cũng muốn mang theo một công cụ giám sát cũng có thể được sử dụng làm công cụ phiên bản dữ liệu. Công cụ tôi đang nói đến là MONyog, thực sự nó là một công cụ giám sát MySQL nhưng với một chút hack chúng ta có thể dễ dàng sử dụng nó làm phiên bản dữ liệu.

Nhưng trước khi đi xa hơn tôi sẽ trích dẫn rằng sẽ không nên đưa toàn bộ cơ sở dữ liệu để tạo phiên bản. Nó là kẻ giết người thực sự để theo dõi sự thay đổi cho một tập hợp dữ liệu cụ thể.

MONyog có một tính năng gọi là CSO (Đối tượng SQL tùy chỉnh), có thể theo dõi sự thay đổi trong bộ dữ liệu cụ thể. Thêm một CSO được mô tả ở đây . Bây giờ trong phần lịch sử theo dõi của MONyog, bạn có thể nhận được các thay đổi trong một khoảng thời gian. Tốt nhất, nó cung cấp một báo cáo trực quan trong trang html. Báo cáo sẽ trông giống như thế này