Câu hỏi Làm thế nào để bạn quản lý cơ sở dữ liệu trong phát triển, thử nghiệm và sản xuất?


Tôi đã có một thời gian khó cố gắng tìm các ví dụ tốt về cách quản lý lược đồ cơ sở dữ liệu và dữ liệu giữa các máy chủ phát triển, thử nghiệm và sản xuất.

Đây là thiết lập của chúng tôi. Mỗi nhà phát triển có một máy ảo chạy ứng dụng của chúng tôi và cơ sở dữ liệu MySQL. Đó là sandbox cá nhân của họ để làm bất cứ điều gì họ muốn. Hiện tại, các nhà phát triển sẽ thực hiện một thay đổi đối với lược đồ SQL và thực hiện kết xuất cơ sở dữ liệu với một tệp văn bản mà họ cam kết vào SVN.

Chúng tôi muốn triển khai một máy chủ phát triển tích hợp liên tục sẽ luôn chạy mã cam kết mới nhất. Nếu chúng ta làm điều đó ngay bây giờ, nó sẽ tải lại cơ sở dữ liệu từ SVN cho mỗi bản dựng.

Chúng tôi có một máy chủ thử nghiệm (ảo) chạy "ứng cử viên phát hành". Triển khai cho máy chủ thử nghiệm hiện là một quá trình rất thủ công và thường liên quan đến việc tôi tải SQL mới nhất từ ​​SVN và tinh chỉnh nó. Ngoài ra, dữ liệu trên máy chủ thử nghiệm không nhất quán. Bạn kết thúc với bất kỳ dữ liệu thử nghiệm nào mà nhà phát triển cuối cùng cam kết có trên máy chủ sandbox của mình.

Nơi mọi thứ bị hỏng là triển khai để sản xuất. Vì chúng tôi không thể ghi đè dữ liệu trực tiếp bằng dữ liệu thử nghiệm, điều này liên quan đến việc tạo lại tất cả các thay đổi lược đồ theo cách thủ công. Nếu có một số lượng lớn các thay đổi lược đồ hoặc tập lệnh chuyển đổi để thao tác dữ liệu, điều này có thể thực sự có nhiều lông.

Nếu vấn đề chỉ là giản đồ, Nó sẽ là một vấn đề dễ dàng hơn, nhưng có dữ liệu "cơ sở" trong cơ sở dữ liệu được cập nhật trong quá trình phát triển, chẳng hạn như siêu dữ liệu trong bảng bảo mật và quyền.

Đây là rào cản lớn nhất tôi thấy trong việc chuyển sang tích hợp liên tục và xây dựng một bước. Làm thế nào để bạn giải quyết nó?


Một câu hỏi tiếp theo: làm thế nào để bạn theo dõi các phiên bản cơ sở dữ liệu để bạn biết các kịch bản nào cần chạy để nâng cấp một cá thể cơ sở dữ liệu đã cho? Là một bảng phiên bản như Lance đề cập dưới thủ tục tiêu chuẩn?


Cảm ơn vì đã tham khảo Tarantino. Tôi không ở trong môi trường .NET, nhưng tôi đã tìm thấy Trang wiki DataBaseChangeMangement rất hữu ích. Đặc biệt là điều này Bản trình bày Powerpoint (.ppt)

Tôi sẽ viết một kịch bản Python để kiểm tra tên của *.sql các tập lệnh trong một thư mục nhất định đối với một bảng trong cơ sở dữ liệu và chạy các thư mục không có trong thứ tự dựa trên một số nguyên tạo thành phần đầu tiên của tên tệp. Nếu nó là một giải pháp khá đơn giản, như tôi nghi ngờ nó sẽ được, sau đó tôi sẽ đăng nó ở đây.


Tôi đã có một kịch bản làm việc cho việc này. Nó xử lý khởi tạo DB nếu nó không tồn tại và chạy các kịch bản nâng cấp khi cần thiết. Ngoài ra còn có các nút chuyển để xóa cơ sở dữ liệu hiện có và nhập dữ liệu thử nghiệm từ một tệp. Đó là khoảng 200 dòng, vì vậy tôi sẽ không đăng nó (mặc dù tôi có thể đặt nó trên pastebin nếu có lãi).


156
2017-08-08 21:01


gốc


Liên quan, thích hợp: stackoverflow.com/questions/52583/… - Ashwin A


Các câu trả lời:


Có một vài lựa chọn tốt. Tôi sẽ không sử dụng chiến lược "khôi phục sao lưu".

  1. Script tất cả các thay đổi lược đồ của bạn, và có máy chủ CI của bạn chạy các kịch bản trên cơ sở dữ liệu. Có một bảng phiên bản để theo dõi phiên bản cơ sở dữ liệu hiện tại và chỉ thực thi các tập lệnh nếu chúng là phiên bản mới hơn.

  2. Sử dụng giải pháp di chuyển. Những giải pháp này thay đổi theo ngôn ngữ, nhưng đối với .NET tôi sử dụng Migrator.NET. Điều này cho phép bạn phiên bản cơ sở dữ liệu của bạn và di chuyển lên và xuống giữa các phiên bản. Lược đồ của bạn được xác định trong mã C #.


48
2017-08-08 21:03





Các nhà phát triển của bạn cần phải viết các kịch bản thay đổi (lược đồ và thay đổi dữ liệu) cho mỗi lỗi / tính năng mà chúng hoạt động, không chỉ đơn giản là đổ toàn bộ cơ sở dữ liệu vào điều khiển nguồn. Các kịch bản này sẽ nâng cấp cơ sở dữ liệu sản xuất hiện tại lên phiên bản mới trong phát triển.

Quá trình xây dựng của bạn có thể khôi phục một bản sao của cơ sở dữ liệu sản xuất vào một môi trường thích hợp và chạy tất cả các tập lệnh từ điều khiển nguồn trên nó, mà sẽ cập nhật cơ sở dữ liệu lên phiên bản hiện tại. Chúng tôi thực hiện việc này hàng ngày để đảm bảo tất cả các tập lệnh đều chạy chính xác.


26
2017-08-17 09:38





Hãy xem cách Ruby on Rails thực hiện điều này.

Đầu tiên có các tệp di chuyển được gọi là, về cơ bản biến đổi lược đồ cơ sở dữ liệu và dữ liệu từ phiên bản N thành phiên bản N + 1 (hoặc trong trường hợp hạ cấp từ phiên bản N + 1 sang N). Cơ sở dữ liệu có bảng cho biết phiên bản hiện tại.

Cơ sở dữ liệu thử nghiệm luôn được xóa sạch trước khi kiểm tra đơn vị và được điền dữ liệu cố định từ các tệp.


12
2018-02-12 14:41





Quyển sách Cơ sở dữ liệu tái cấu trúc: Thiết kế cơ sở dữ liệu tiến hóa có thể cung cấp cho bạn một số ý tưởng về cách quản lý cơ sở dữ liệu. Một phiên bản ngắn cũng có thể đọc được tại http://martinfowler.com/articles/evodb.html

Trong một dự án PHP + MySQL tôi đã có số sửa đổi cơ sở dữ liệu được lưu trữ trong cơ sở dữ liệu và khi chương trình kết nối với cơ sở dữ liệu, trước tiên nó sẽ kiểm tra bản sửa đổi. Nếu chương trình yêu cầu bản sửa đổi khác, chương trình sẽ mở một trang để nâng cấp cơ sở dữ liệu. Mỗi nâng cấp được quy định trong mã PHP, nó sẽ thay đổi lược đồ cơ sở dữ liệu và di chuyển tất cả dữ liệu hiện có.


7
2017-08-21 02:58





  • Đặt tên cho các cơ sở dữ liệu của bạn như sau: db_dev, db_test, db_qa, db_prod (Rõ ràng bạn không bao giờ nên mã hóa tên db
  • Vì vậy, bạn sẽ có thể triển khai ngay cả các loại khác nhau của db trên cùng một máy chủ vật lý (tôi không recomment rằng, nhưng bạn có thể phải ... nếu tài nguyên chặt chẽ)
  • Đảm bảo bạn có thể tự động di chuyển dữ liệu giữa các dữ liệu đó
  • Tách các tập lệnh tạo db khỏi tập hợp = Cần luôn có thể tạo lại db từ đầu và điền vào nó (từ phiên bản db cũ hoặc nguồn dữ liệu ngoài
  • không sử dụng các chuỗi kết nối hardcode trong mã (thậm chí không có trong các tệp cấu hình) - sử dụng trong các mẫu chuỗi kết nối tệp cấu hình, mà bạn điền động, mỗi cấu hình lại của application_layer cần biên dịch lại là BAD
  • sử dụng phiên bản cơ sở dữ liệu và các phiên bản đối tượng db - nếu bạn có thể đủ khả năng sử dụng các sản phẩm đã sẵn sàng, nếu không tự mình phát triển một thứ gì đó
  • theo dõi từng thay đổi DDL và lưu nó vào một số bảng lịch sử ( ví dụ ở đây )
  • Bản sao lưu NGÀY! Kiểm tra tốc độ bạn có thể khôi phục lại thứ gì đó bị mất từ ​​bản sao lưu (sử dụng các tập lệnh khôi phục automathic)
  • ngay cả cơ sở dữ liệu DEV và PROD của bạn cũng có cùng một kịch bản tạo, bạn sẽ gặp vấn đề với dữ liệu, vì vậy cho phép các nhà phát triển tạo bản sao chính xác của sản phẩm và chơi với nó (tôi biết mình sẽ nhận được minuses cho cái này, nhưng thay đổi suy nghĩ và quy trình kinh doanh sẽ khiến bạn tốn kém hơn rất nhiều khi shit chạm vào người hâm mộ - vì vậy hãy buộc các lập trình viên lập chỉ mục hợp pháp bất cứ điều gì nó làm, nhưng hãy đảm bảo điều này

4
2018-01-16 08:09





Đây là điều mà tôi liên tục không hài lòng với - giải pháp của chúng tôi cho vấn đề này. Trong nhiều năm, chúng tôi đã duy trì một kịch bản thay đổi riêng biệt cho mỗi bản phát hành. Kịch bản này sẽ chứa các vùng đồng bằng từ bản phát hành sản phẩm cuối cùng. Với mỗi bản phát hành của ứng dụng, số phiên bản sẽ tăng lên, cho một số thứ như sau:

  • dbChanges_1.sql
  • dbChanges_2.sql
  • ...
  • dbChanges_n.sql

Điều này đã làm việc đủ tốt cho đến khi chúng tôi bắt đầu duy trì hai dòng phát triển: Trunk / Mainline cho phát triển mới và chi nhánh bảo trì sửa lỗi, cải tiến ngắn hạn, v.v. Không tránh khỏi sự cần thiết phải thay đổi lược đồ trong nhánh. Tại thời điểm này, chúng ta đã có dbChanges_n + 1.sql trong Trunk, vì vậy chúng ta đã kết thúc với một lược đồ như sau:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • ...
  • dbChanges_n.3.sql

Một lần nữa, điều này làm việc đủ tốt, cho đến khi chúng tôi một ngày chúng tôi nhìn lên và thấy 42 kịch bản delta trong đường chính và 10 trong chi nhánh. ARGH!

Những ngày này, chúng tôi chỉ đơn giản là duy trì một tập lệnh delta và để SVN phiên bản - tức là chúng tôi ghi đè kịch bản với mỗi bản phát hành. Và chúng tôi né tránh việc thay đổi lược đồ trong các nhánh.

Vì vậy, tôi cũng không hài lòng với điều này. Tôi thực sự thích khái niệm di chuyển từ Rails. Tôi đã trở nên khá mê hoặc với LiquiBase. Nó hỗ trợ khái niệm tái cấu trúc cơ sở dữ liệu gia tăng. Nó đáng xem và tôi sẽ sớm xem xét nó một cách chi tiết. Có ai có kinh nghiệm với nó không? Tôi rất tò mò muốn nghe về kết quả của bạn.


3
2017-09-02 23:30





Bạn cũng có thể xem xét sử dụng một công cụ như So sánh SQL để viết kịch bản sự khác biệt giữa các phiên bản khác nhau của cơ sở dữ liệu, cho phép bạn di chuyển nhanh giữa các phiên bản


3
2017-08-22 12:53