11

Tại nơi làm việc, chúng tôi có 4 người cùng làm việc trên một vài dự án khác nhau. Đối với mỗi dự án, chúng tôi có một bản sao cục bộ mà chúng tôi làm việc và sau đó có một sự phát triển, dàn dựng và triển khai trực tiếp, cùng với bất kỳ nhánh nào chúng ta có (chúng tôi sử dụng subversion). Cơ sở dữ liệu của chúng tôi là MySQL.Làm thế nào để bạn quản lý các sửa đổi cơ sở dữ liệu trên một dự án cỡ trung bình với các chi nhánh?

Vì vậy, câu hỏi của tôi là, cách tốt nhất để quản lý những sửa đổi nào đối với cơ sở dữ liệu đã được thực hiện cho từng triển khai (và đối với nhà phát triển bản sao cục bộ của họ). Ngay bây giờ mỗi thay đổi đi vào một tập tin văn bản đó là dấu thời gian trong tên và đưa vào một thư mục trong dự án. Điều này không làm việc rất tốt để được trung thực .. Tôi cần một giải pháp sẽ giúp theo dõi những gì đã được áp dụng ở đâu.

Trả lời

2

Nếu cơ sở dữ liệu của bạn ánh xạ độc đáo với một tập hợp các đối tượng truy cập dữ liệu, hãy xem xét sử dụng 'di chuyển'. Ý tưởng là lưu trữ mô hình dữ liệu của bạn dưới dạng mã ứng dụng với các bước để tiến lên và lùi qua từng phiên bản cơ sở dữ liệu.

Tôi tin rằng Rails did it first.

Java có at least one project.

Và đây là .NET migration library.

Để thay đổi phiên bản, bạn chạy một tập lệnh đơn giản để thực hiện tất cả các phiên bản lên hoặc xuống để đưa bạn đến phiên bản bạn muốn. Vẻ đẹp của nó là, bạn kiểm tra di chuyển của bạn vào cùng một kho lưu trữ nguồn như mã ứng dụng của bạn - tất cả ở cùng một nơi.

Có thể những người khác có thể đề xuất các thư viện di chuyển khác.

Chúc mừng.

Chỉnh sửa: Xem thêm https://stackoverflow.com/questions/313/net-migrations-engine.NET database migration tool roundup (từ bài đăng ở trên).

+0

Điều này trông giống như một lựa chọn thực sự thú vị. Tôi rất thích nghe trải nghiệm của một số người với thư viện di trú .NET – Greg

+0

Cảm ơn bạn đã cập nhật Tôi sẽ thử tuyến đường Di chuyển. – Greg

+0

Tôi đã thực hiện một số sửa đổi của riêng mình cho migratordotnet và đã sử dụng điều này khá thành công ngay bây giờ. – Greg

8

http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx

Blog trên đưa chúng tôi đến hệ thống kiểm soát phiên bản cơ sở dữ liệu hiện tại của chúng tôi. Nói một cách đơn giản, không có thay đổi DB nào được thực hiện mà không có tập lệnh cập nhật và tất cả các tập lệnh cập nhật đều nằm trong kho kiểm soát nguồn của chúng tôi.

Chúng tôi chỉ quản lý thay đổi lược đồ nhưng bạn cũng có thể/sẵn sàng cân nhắc việc lưu trữ dữ liệu của mình trong kiểm soát phiên bản; tạo các tệp như vậy là một bài tập khá tầm thường khi sử dụng mysqldump.

Giải pháp của chúng tôi khác với giải pháp được trình bày trong blog theo một cách chính: nó không tự động. Chúng tôi phải bàn tay áp dụng các cập nhật cơ sở dữ liệu, vv Mặc dù điều này có thể hơi tốn thời gian, nhưng nó đã trì hoãn một số nỗ lực mà một hệ thống hoàn toàn tự động sẽ yêu cầu. Tuy nhiên, một điều chúng tôi đã làm là tự động theo dõi phiên bản db trong phần mềm: điều này khá đơn giản và đảm bảo rằng phần mềm của chúng tôi biết về cơ sở dữ liệu đang chạy và sẽ CHỈ chạy nếu nó biết lược đồ đang hoạt động.

Phần khó nhất trong giải pháp của chúng tôi là cách hợp nhất các cập nhật từ các chi nhánh của chúng tôi vào thân cây của chúng tôi. Chúng tôi đã dành một chút thời gian để phát triển một luồng công việc để giải quyết khả năng của hai nhà phát triển cố gắng hợp nhất các chi nhánh với các bản cập nhật DB cùng một lúc và cách xử lý nó. Cuối cùng, chúng tôi đã quyết định khóa tệp trong kiểm soát phiên bản (tệp thực sự cho chúng tôi thực sự là phiên bản phần mềm lập bản đồ bảng để hỗ trợ chiến lược quản lý thủ công của chúng tôi), giống như phần quan trọng của chủ đề và nhà phát triển khóa đi về bản cập nhật của thân cây. Khi hoàn thành, nhà phát triển khác sẽ có thể khóa và họ có trách nhiệm thực hiện bất kỳ thay đổi nào cần thiết cho tập lệnh của họ để đảm bảo rằng các phiên bản dự kiến ​​va chạm và các juju xấu khác đều bị tránh.

+0

Tôi đã đọc và thực sự tôi không thích ý tưởng này. Tôi nghĩ rằng toàn bộ hệ thống sẽ cần phải được xây dựng để thực sự hỗ trợ điều này cho nhiều triển khai. – Greg

+0

Thêm một chút về những gì bạn đã mô tả: chắc chắn có một số công cụ cơ sở hạ tầng được xây dựng để có được giải pháp đó nhưng không phải tất cả là cần thiết (chúng tôi đã chọn không cho phép phần mềm tự "cập nhật") đó là một giải pháp mạnh mẽ như vậy mà nỗ lực ban đầu sẽ được đền đáp nhanh chóng. – antik

+0

Tôi nghĩ rằng đây là một khởi đầu tốt (những gì bạn đã mô tả là tương tự như những gì tôi đã suy nghĩ). Một trong những vấn đề lớn nhất tôi đã suy nghĩ về mặc dù là sáp nhập .. Mà chúng tôi dường như đang làm rất nhiều thời gian gần đây. Hy vọng rằng chúng tôi không có quá nhiều thay đổi lược đồ trong một chi nhánh, nhưng điều đó xảy ra .. – Greg

5

Chúng tôi giữ tất cả các tập lệnh cơ sở dữ liệu của chúng tôi (dữ liệu và lược đồ/ddl) trong điều khiển phiên bản. Chúng tôi cũng giữ một danh mục trung tâm về những thay đổi. Khi nhà phát triển thực hiện thay đổi đối với tệp lược đồ/DDL hoặc thêm tập lệnh thay đổi dữ liệu theo cách nào đó, các tệp đó được thêm vào danh mục, cùng với số cam kết SVN.

Chúng tôi đã kết hợp một tiện ích nhỏ trong nhà đọc thay đổi danh mục và xây dựng tập lệnh cập nhật lớn dựa trên nội dung của danh mục bằng cách lấy nội dung từ mỗi bản sửa đổi trong danh mục và áp dụng chúng. Khái niệm này khá giống với công cụ DBDeploy, mà tôi tin ban đầu là từ Thoughtworks, vì vậy bạn có thể sử dụng nó. Nó sẽ ít nhất cung cấp cho bạn một nơi tốt để bắt đầu, từ đó bạn có thể tùy chỉnh một giải pháp phù hợp hơn với nhu cầu của bạn.

Chúc bạn may mắn!