Làm thế nào để bạn xử lý liên tục thay đổi kích thước cơ sở dữ liệu?


9

Trong hai tháng qua, tôi đã tìm kiếm các giải pháp hoặc thực tiễn để xử lý việc quản lý phát hành trong cơ sở dữ liệu. Tôi đang tìm kiếm những gì mọi người xem là quá trình tốt nhất để xử lý việc này.

Chúng tôi có 3 môi trường cho cơ sở dữ liệu của chúng tôi:

  • Phát triển
  • Kiểm tra chấp nhận người dùng (UAT)
  • Sản xuất

Vấn đề là đôi khi chúng tôi đang thực hiện các thay đổi đối với một số thứ trong cơ sở dữ liệu phát triển của mình và đến lúc triển khai, một số tính năng có thể chưa sẵn sàng để được phát hành lên UAT.

Gần đây, chúng tôi đã bắt đầu sử dụng kiểm soát Nguồn SQL của Red Gate để lưu trữ tất cả các thực thể của chúng tôi (với các cam kết thông thường).

Tôi đã nghĩ đến việc loại bỏ các thay đổi (nghĩa là mọi thứ từ thay đổi X trở lại đang bị đẩy sang UAT), tuy nhiên, điều này có nghĩa là mọi người chỉ kiểm tra mã của họ vào kiểm soát nguồn ngay trước khi chúng tôi triển khai có thể gây nhầm lẫn ( đặc biệt là vì mọi người hay quên). Một vấn đề khác liên quan đến cách tiếp cận thay đổi là nếu có một lỗi trong quy trình được lưu trữ cần phải sửa, số lượng thay đổi cuối cùng sẽ nằm ngoài phạm vi của bộ thay đổi tối đa của chúng tôi để sửa đổi, do đó chúng tôi cần phải sửa tạo lại cơ sở dữ liệu từ một bộ thay đổi tối đa, chúng tôi sẽ đẩy lỗi ra một lần nữa.

Bất kỳ đề xuất về một quá trình?

Cảm ơn


Có vẻ như các tập lệnh cơ sở dữ liệu của bạn không nằm trong cùng điều khiển nguồn với mã "thực tế" của bạn. Tại sao lại thế này? Bạn có thể coi nó là "mã nguồn" và đặt nó với các nhánh riêng lẻ không?
Mike M.

Hiện tại chúng tôi chỉ lưu trữ phiên bản phát triển của tập lệnh trong kiểm soát nguồn và cả UAT / Sản xuất đều không đồng bộ với phát triển tích cực. Mỗi tập lệnh trong kiểm soát nguồn được cập nhật mỗi khi nhà phát triển thực hiện cam kết. Vấn đề với các nhánh riêng lẻ là chúng tôi có 1 cơ sở dữ liệu tập trung mà mọi người đều sử dụng (đối với những thay đổi lớn hơn, chúng tôi phân nhánh các cơ sở dữ liệu riêng biệt).

1
Bạn có thể tạo một nhánh cho bản phát hành và chỉ cam kết các thay đổi liên quan đến bản phát hành này. Tất cả các thay đổi khác nên được thực hiện cho thân cây. Bạn sẽ cần hai cơ sở dữ liệu phát triển để đạt được điều này. Đây sẽ là một vấn đề?

Nghe có vẻ như một người có thể sẽ hết hạn khá nhanh. Không? Đối với một trong những dự án của tôi, chúng tôi đang ở giữa một cuộc đại tu lớn của cơ sở dữ liệu, vì vậy chúng tôi đã phân nhánh để một sự phát triển tích cực vẫn có thể xảy ra trong phiên bản cơ sở dữ liệu chưa sửa đổi. Tuy nhiên, mỗi ngày tôi thấy phiên bản phân nhánh của chúng tôi ngày càng lỗi thời mà tôi không chắc liệu điều đó có ổn hay không ... Tôi chưa bao giờ thực sự phải đối phó với các tình huống như thế này trước đây.
judda

Câu trả lời:


5

Di cư

Một lên và xuống, đó là trong repo của bạn và được gắn thẻ cùng với ứng dụng của bạn.

Bạn thậm chí có thể DIY với các tệp phẳng sql sửa đổi lược đồ của bạn và cập nhật phiên bản lược đồ. Tất cả những gì bạn thực sự phải làm là:

  • giữ di chuyển của bạn bên cạnh mã nguồn, chúng nên được phiên bản và được gắn thẻ với nhau
  • luôn luôn sử dụng các thay đổi được quản lý (di chuyển) trong mọi môi trường
  • không bao giờ cho phép sửa đổi đặc biệt trong mọi môi trường

Chà, bạn có thể thực hiện các thay đổi phát triển trong dev, nhưng bạn phải luôn thổi bay db của mình và xây dựng lại nó bằng các lần di chuyển sau khi bạn nắm bắt được thay đổi.


Điều gì sẽ xảy ra nếu một lỗi được tìm thấy trong các tập lệnh? Bạn có quay lại kịch bản sql và cập nhật nó không?
judda

1
Không, bạn tạo một di chuyển mới (làm tăng phiên bản lược đồ). Đó là cách bạn biết bản sửa lỗi đã được triển khai, bằng cách xem phiên bản lược đồ trong cơ sở dữ liệu.
dietbuddha

Cảm ơn sự giúp đỡ của bạn. Từ cái nhìn đầu tiên, đây có vẻ là một cách tiếp cận rất vững chắc và tương tự như chiến lược phân nhánh của chúng tôi.
judda

2

Kiểm soát nguồn!

Bạn không triển khai các tệp nhị phân phát triển của mình trực tiếp vào sản xuất mà không thông qua svn / git / p4, vậy tại sao cơ sở dữ liệu của bạn sẽ làm điều đó? Nhận các cá thể riêng cho các nhà phát triển để kiểm tra các thay đổi cục bộ của họ, nhưng khi nó phải vào db phát triển, nó phải đi qua các tệp ddl đã kiểm tra. Bạn thậm chí có thể viết lên các công cụ để áp dụng các thay đổi ddl này một cách tự động (Tôi không biết bất kỳ cách hiện có nào để thực hiện việc này một cách chính xác).

Khi bạn có các hạn chế xung quanh thay đổi lược đồ db (Không còn sqlplus -> phát hành ddl!) Và kiểm soát tài khoản chặt chẽ (không có quyền truy cập ddl cho mọi người), điều này sẽ trở nên dễ quản lý hơn.


1
Đáng buồn thay, cơ sở dữ liệu của chúng tôi quá lớn để được chuyển qua lại giữa các nhà phát triển để chạy các phiên riêng tư. Cũng như điều đó dường như không thực sự nghiêng về phát triển dựa trên nhóm hơn bởi vì ngay bây giờ, tôi thực hiện phát triển cuối cùng trong khi nói chuyện với mọi người về công việc UI liên kết cả hai. Tôi sẽ cần phải bắt đầu bằng cách kiểm tra tất cả các thay đổi và sau đó để chúng được cập nhật mới nhất trên cơ sở dữ liệu có vẻ là một rắc rối khá lớn.
judda

Tại sao db phát triển của bạn phải có cùng kích thước với db sản xuất? Chúng có thể có cùng một lược đồ và thậm chí bạn có thể có một nhóm thử nghiệm tải đặc biệt với tất cả dữ liệu, nhưng cơ sở dữ liệu dev cục bộ có thể nhỏ. Điều này cũng ngăn chặn các mối quan tâm rò rỉ dữ liệu, v.v. - về lý thuyết, dữ liệu prod hoàn toàn không nên phát triển.
Subu Sankara Subramanian

Tất cả dữ liệu của chúng tôi được tải thông qua quá trình tải dữ liệu của chúng tôi để xử lý các tệp được cung cấp cho chúng tôi từ máy khách và sau đó chuyển đổi chúng thành dữ liệu mà chúng tôi cần. Vì vậy, chúng tôi không thể tách dữ liệu dev và prod với tất cả các tải dữ liệu cần phải được xác minh trong mọi cách phát triển. Tôi đoán nó không cần phải có cùng kích thước, tuy nhiên, nó cần lượng dữ liệu tương đương để báo cáo mà chúng tôi tạo để tạo thông tin có ý nghĩa.
judda

Toàn bộ DB không cần phải được nhân rộng. Trong Oracle mỗi người dùng có lược đồ riêng và chúng tôi có một lược đồ ứng dụng. Tạo từ đồng nghĩa công khai cho tất cả các đối tượng trong lược đồ ứng dụng. Sau đó, mọi người dùng có thể thay đổi các đối tượng (bảng, SP) trong lược đồ riêng của họ và nếu họ tự kết nối thì tên đối tượng của họ sẽ được sử dụng. Đối với các đối tượng không có trong lược đồ, các từ đồng nghĩa woukd được sử dụng. Đây là cách chúng tôi làm việc.
softveda

0

Theo gợi ý về việc sử dụng di chuyển ... có thể sử dụng O / RM hỗ trợ Di chuyển như Ruby on Rails và Entity Framework 4.3 Tuy nhiên, vấn đề với cả hai cách tiếp cận là di chuyển là tất cả hoặc không có gì. Bạn không thể (thường) chọn Di chuyển nào được áp dụng như bạn có thể về các bộ thay đổi.

Một tùy chọn khả thi khác (nếu bạn đang ở trên ngăn xếp microsoft, bạn chưa bao giờ đề cập đến nền tảng này) là quản lý SQL của bạn bằng các công cụ Cơ sở dữ liệu Visual Studio. Nó đã được xây dựng trong tái cấu trúc (đổi tên / loại bỏ các cột, v.v.) và xác minh mô hình. Ví dụ, nếu một Proc được lưu trữ tham chiếu một cột không còn ở đó, nó sẽ thông báo cho bạn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.