Các cách hiệu quả để đối phó với các lược đồ cơ sở dữ liệu được chia sẻ giữa các nhánh mã là gì?

Làm việc trên một dự án với nhiều chi nhánh, trong đó mỗi chi nhánh cuối cùng được sáp nhập trở lại chi nhánh chính và về bản chất được tách ra để phát triển một tính năng mới.

Cơ sở dữ liệu, đó là MS SQL Server, có một lược đồ được chia sẻ, tuy nhiên mỗi nhánh sẽ thay đổi lược đồ khi tiến trình.

Câu hỏi chính của tôi là những cách tốt để đối phó với việc chia sẻ lược đồ từ nhánh chính xuống nhánh dẫn xuất, sao cho những thay đổi được thực hiện cho nhánh chính dễ dàng được sáp nhập vào nhánh dẫn xuất, mà không bước vào những thay đổi mới trong dẫn xuất chi nhánh?

Tôi đã sử dụng thành công phương pháp sau, được xây dựng trong Kiểm soát phiên bản và Cơ sở dữ liệu của bạn :

• duy trì số phiên bản trong siêu dữ liệu (Tôi sử dụng thuộc tính cơ sở dữ liệu mở rộng)
• mọi thay đổi lược đồ được mã hóa thành tập lệnh cập nhật từ phiên bản hiện tại sang phiên bản tiếp theo
• ứng dụng vận chuyển tất cả các tập lệnh để nâng cấp từ phiên bản 0 (triển khai ban đầu) cho đến phiên bản hiện tại
• Mọi thay đổi được thực hiện thông qua một kịch bản. Bao gồm các thay đổi dữ liệu của 'hệ thống' như từ điển và mục nhập bảng tra cứu.
• Khi được triển khai, ứng dụng sẽ kiểm tra phiên bản lược đồ trên đĩa, sau đó chạy tất cả các bước nâng cấp để đưa lược đồ về phiên bản bắt buộc hiện tại

Tôi thường nghe ý kiến ​​'làm thế nào khác với việc giữ các tập lệnh định nghĩa đối tượng dưới sự kiểm soát nguồn?'. Sự khác biệt là rất lớn, bởi vì khi bạn triển khai một phiên bản mới của ứng dụng, bạn sẽ không chỉ đơn giản là tạo một cơ sở dữ liệu mới. Hầu hết các lần ứng dụng của bạn sẽ phải nâng cấp cơ sở dữ liệu hiện có, bao gồm cả dữ liệu hiện có . Đây là một sự khác biệt quan trọng, các bước nâng cấp của bạn cần đảm bảo tính toàn vẹn và nhất quán của dữ liệu hiện có trong quá trình nâng cấp. Một số thao tác không quan trọng bằng mã (thêm một cột không thể rỗng với giá trị mặc định vào tập lệnh định nghĩa đối tượng bảng, được thực hiện), nhưng thực tế chúng rất đau khi triển khai thực tế (bảng có 1,5 tỷ hàng, cột thêm sẽ hết của không gian nhật ký nếu được thực hiện theo cách 'đơn giản').

Làm thế nào để điều này làm việc với phân nhánh:

• Khi nhánh được tạo, nó ngắt phiên bản lược đồ hiện tại, giả sử phiên bản 1.6
• khi nhóm bắt đầu làm việc trên chi nhánh, nó thêm phiên bản mới, 1.7 và sau đó nó bắt đầu mã hóa bước nâng cấp từ 1.6 lên 1.7
• bước nâng cấp được thay đổi khi sửa đổi được thực hiện trong nhánh. Nó luôn chạy tập lệnh nâng cấp từ v 1.6 lên 1.7, nhưng chính xác những tập lệnh đó làm gì, phải tuân theo các lần lặp và kiểm tra mã thông thường trong nhánh
• nhánh kết thúc phát triển, nó chuẩn bị cho sự tích hợp ngược (sẽ được sáp nhập trở lại vào đường cơ sở)
  • nó thực hiện một sự tích hợp chuyển tiếp mới từ đường cơ sở đến chi nhánh. Nếu tích hợp không mang lại bất kỳ thay đổi nào cho phiên bản lược đồ, tất cả mọi thứ đều tốt, nhánh có thể đảo ngược tích hợp như hiện trạng. phiên bản 1.7 trở thành phiên bản cơ sở mới.
  • điều thú vị là khi một nhánh khác đã tích hợp ngược vào cơ sở trong thời gian đó và bây giờ phiên bản lược đồ cơ sở đã thay đổi thành, giả sử, 1.7. Trong trường hợp này, chi nhánh của chúng tôi phải nâng phiên bản lược đồ mục tiêu triển khai lên 1.8 và thực hiện đánh giá bước nâng cấp trước đây từ 1.6 lên 1.7 để xem cách hoạt động trong môi trường mới, nâng cấp từ 1.7 lên 1.8. Xung đột lược đồ logic phải được giải quyết, kịch bản có thể yêu cầu thay đổi, thử nghiệm phải được thực hiện. Sau khi hoàn thành, chi nhánh có thể đảo ngược tích hợp vào cơ sở. Phiên bản mục tiêu được triển khai của sản phẩm hiện trở thành 1.8.
  • Khi một nhánh khác đã phân nhánh ở phiên bản lược đồ 1.6 muốn tích hợp ngược lại, thì nó sẽ phải nâng phiên bản lược đồ của nó thành 1.9, kiểm tra tập lệnh nâng cấp từ 1.8 lên 1.9, sau đó nó có thể tích hợp trở lại vào cơ sở.

Lưu ý rằng không có công cụ liên quan, không có kịch bản khác của lược đồ ma thuật, không có trình hướng dẫn và không có tập lệnh nhấp chuột phải vào nút phải. Đây là một quá trình hướng đến nhà phát triển 100%, dựa trên nguồn (tập lệnh). Nhiều người tìm thấy toàn bộ quá trình này công phu, nhưng nó hoạt động. Trên thực tế, với tư cách là người dùng SQL Server, bạn đã tận dụng kết quả của quá trình này trong việc sử dụng SQL Server hàng ngày của mình: SQL Server sử dụng quy trình nâng cấp cơ sở dữ liệu rất giống nhau và, như bạn có thể mong đợi, quá trình phát triển sản phẩm sử dụng rộng rãi phân nhánh và vấn đề bạn đề cập là một vấn đề rất thực tế phải được giải quyết.

BTW, cách phân nhánh / tích hợp thực sự xảy ra khác nhau giữa các sản phẩm kiểm soát nguồn, tôi đang sử dụng các thuật ngữ quen thuộc từ chế độ hoạt động tích hợp bắt buộc .

Trong khi câu trả lời của tôi có thể không dài bằng Remus ', tôi thấy đây là một giải pháp thực sự tốt. Tôi chưa có nó được thiết lập trong sản xuất, vì vậy YMMV *.

Rượu

Về cơ bản, đây là một tệp XML nơi bạn thực hiện các thay đổi lược đồ cho cơ sở dữ liệu của mình dưới dạng các phần tử mới bên trong tệp XML. Ví dụ:

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

Nó có một cú pháp hoàn chỉnh để bạn có thể làm bất cứ điều gì bạn muốn vào cơ sở dữ liệu của bạn.

Bạn cũng chỉ định trong cài đặt Liquibase của bạn cơ sở dữ liệu nào bạn muốn được phiên bản. Sau đó, bạn "chạy" .xml với tệp thực thi Java đi kèm (tệp jar). Điều này về cơ bản tái tạo những thay đổi được chỉ định trong XML vào cơ sở dữ liệu của bạn.

Yếu tố thực sự là bạn lưu trữ tệp XML này trong cùng thư mục được phiên bản với mã của bạn. Vì vậy, trong trường hợp của tôi đó là Git. Tôi đã có tệp XML này trong thư mục dự án của mình (cùng cấp với /.git) và sau đó bất cứ khi nào tôi chuyển nhánh, tệp XML sẽ thay đổi thành phiên bản nhánh đó và tôi sẽ chạy tệp .jar và cơ sở dữ liệu của tôi bây giờ sẽ phản ánh nhánh đó.

* Lưu ý: Tôi chưa hoàn thành việc triển khai vì tôi gặp sự cố khi kết nối Java với SQL Server. Cần một số trình điều khiển jdbc và như vậy và tôi không có tâm trạng. Do đó, số dặm của bạn có thể thay đổi.

Tại Red Gate, chúng tôi sẽ sớm phát hành một giải pháp phiên bản cơ sở dữ liệu tận dụng cả So sánh SQL và Kiểm soát nguồn SQL. Điều này sử dụng phương pháp nâng cấp tập lệnh di chuyển và đóng dấu cơ sở dữ liệu với thuộc tính mở rộng phiên bản tương ứng với sửa đổi kiểm soát nguồn.

Chúng tôi hy vọng sẽ phát hành vào giữa tháng 12. Có một ứng cử viên phát hành có sẵn bây giờ. Để biết thêm thông tin, hãy truy cập:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

Chúng tôi hy vọng sẽ xây dựng giải pháp này trong những tháng tới vì vậy vui lòng cho chúng tôi biết suy nghĩ của bạn.

Nếu bạn và xử lý các thay đổi lược đồ của mình bằng cách tạo các tập lệnh và giữ các tập lệnh đó dưới sự kiểm soát nguồn, thì bạn sẽ có thể xử lý các thay đổi đó như bất kỳ tập hợp mã nào khác. Bạn có thể chọn tự động hợp nhất hoặc can thiệp thủ công hơn.

Tôi đang ở trong một tình huống tương tự khi tôi làm việc trên một trang web trực tiếp và một số nhánh phát triển trong đó tôi cần thay đổi lược đồ cơ sở dữ liệu.

Tôi đã giải quyết nó bằng cách viết một bài kiểm tra sau và một cái móc sau hợp nhất có thể được sử dụng độc đáo với git. Tôi lưu trữ tất cả các lần di chuyển của mình dưới dạng các tệp SQL trong một thư mục riêng và cam kết chúng cùng với mã PHP đã thay đổi. Mỗi lần tôi thực hiện một

git checkout

hoặc một

git merge

git sẽ tự động gọi di chuyển lên và xuống thích hợp. Xem triển khai của tôi trên Github .