Bạn nên xây dựng cơ sở dữ liệu của mình từ kiểm soát nguồn như thế nào?

Đã có một số cuộc thảo luận trên wiki cộng đồng SO về việc liệu các đối tượng cơ sở dữ liệu có nên được kiểm soát phiên bản hay không. Tuy nhiên, tôi chưa thấy thảo luận nhiều về các phương pháp hay nhất để tạo quá trình tự động hóa xây dựng cho các đối tượng cơ sở dữ liệu.

Đây là một điểm thảo luận gây tranh cãi đối với nhóm của tôi - đặc biệt vì các nhà phát triển và DBA thường có các mục tiêu, cách tiếp cận và mối quan tâm khác nhau khi đánh giá lợi ích và rủi ro của cách tiếp cận tự động hóa để triển khai cơ sở dữ liệu.

Tôi muốn nghe một số ý kiến ​​từ cộng đồng SO về những phương pháp thực hành đã hiệu quả trong thế giới thực.

Tôi nhận ra rằng việc thực hành nào thực sự tốt nhất là hơi chủ quan, nhưng tôi nghĩ rằng một cuộc đối thoại tốt về những công việc có thể hữu ích cho nhiều người.

Dưới đây là một số câu hỏi mở đầu của tôi về các lĩnh vực quan tâm trong chủ đề này. Đây không phải là một danh sách chắc chắn - mà là một điểm khởi đầu để mọi người giúp hiểu những gì tôi đang tìm kiếm.

1. Có nên xây dựng cả môi trường thử nghiệm và sản xuất từ ​​kiểm soát nguồn không?
   
   • Cả hai nên được xây dựng bằng cách sử dụng tự động hóa - hay nên sản xuất bằng cách xây dựng bằng cách sao chép các đối tượng từ một môi trường thử nghiệm ổn định, đã hoàn thiện?
   • Làm thế nào để bạn đối phó với sự khác biệt tiềm ẩn giữa môi trường thử nghiệm và sản xuất trong các kịch bản triển khai?
   • Làm thế nào để bạn kiểm tra xem các tập lệnh triển khai sẽ hoạt động hiệu quả chống lại quá trình sản xuất như khi chúng làm trong thử nghiệm?
2. Những loại đối tượng nào nên được kiểm soát phiên bản?
   • Chỉ cần mã (thủ tục, gói, trình kích hoạt, java, v.v.)?
   • Các chỉ số?
   • Những hạn chế?
   • Định nghĩa bảng?
   • Tập lệnh thay đổi bảng? (ví dụ: tập lệnh ALTER)
   • Mọi điều?
3. Những loại đối tượng nào không nên được kiểm soát phiên bản?
   • Trình tự?
   • Trợ cấp?
   • Tài khoản người dùng?
4. Các đối tượng cơ sở dữ liệu nên được tổ chức như thế nào trong kho SCM của bạn?
   • Làm thế nào để bạn đối phó với những thứ một lần như tập lệnh chuyển đổi hoặc tập lệnh ALTER?
   • Bạn xử lý như thế nào khi gỡ bỏ các đối tượng khỏi cơ sở dữ liệu?
   • Ai sẽ chịu trách nhiệm thúc đẩy các đối tượng từ cấp độ phát triển đến cấp độ thử nghiệm?
   • Làm thế nào để bạn điều phối các thay đổi từ nhiều nhà phát triển?
   • Làm thế nào để bạn đối phó với việc phân nhánh cho các đối tượng cơ sở dữ liệu được sử dụng bởi nhiều hệ thống?
5. Những ngoại lệ nào, nếu có, có thể hợp lý cho quá trình này?
   • Vấn đề an ninh?
   • Dữ liệu có mối quan tâm về xác định danh tính?
   • Tập lệnh không thể hoàn toàn tự động?
6. Làm thế nào bạn có thể làm cho quy trình trở nên linh hoạt và khả thi?
   • Lỗi của nhà phát triển?
   • Đối với các vấn đề môi trường không mong muốn?
   • Để khắc phục thảm họa?
7. Làm thế nào để bạn thuyết phục những người ra quyết định rằng lợi ích của DB-SCM thực sự phù hợp với chi phí?
   • Bằng chứng giai thoại?
   • Nghiên cứu ngành?
   • Khuyến nghị thực tiễn tốt nhất trong ngành?
   • Kháng cáo lên các cơ quan chức năng được công nhận?
   • Phân tích lợi ích chi phí?
8. Ai nên "sở hữu" các đối tượng cơ sở dữ liệu trong mô hình này?
   • Các nhà phát triển?
   • DBA?
   • Nhà phân tích dữ liệu?
   • Nhiều hơn một?

Dưới đây là một số câu trả lời cho câu hỏi của bạn:

1. Có nên xây dựng cả môi trường thử nghiệm và sản xuất từ ​​kiểm soát nguồn không? ĐÚNG
   • Cả hai nên được xây dựng bằng cách sử dụng tự động hóa - hay nên sản xuất bằng cách xây dựng bằng cách sao chép các đối tượng từ một môi trường thử nghiệm ổn định, đã hoàn thiện?
   • Tự động hóa cho cả hai. KHÔNG sao chép dữ liệu giữa các môi trường
   • Làm thế nào để bạn đối phó với sự khác biệt tiềm ẩn giữa môi trường thử nghiệm và sản xuất trong các kịch bản triển khai?
   • Sử dụng các mẫu để thực sự bạn sẽ tạo ra các tập lệnh khác nhau cho từng môi trường (ví dụ: tham chiếu đến hệ thống bên ngoài, cơ sở dữ liệu được liên kết, v.v.)
   • Làm thế nào để bạn kiểm tra xem các tập lệnh triển khai sẽ hoạt động hiệu quả chống lại quá trình sản xuất như khi chúng làm trong thử nghiệm?
   • Bạn kiểm tra chúng trên môi trường tiền sản xuất: thử nghiệm triển khai trên bản sao chính xác của môi trường sản xuất (cơ sở dữ liệu và các hệ thống có thể khác)
2. Những loại đối tượng nào nên được kiểm soát phiên bản?
   • Chỉ cần mã (thủ tục, gói, trình kích hoạt, java, v.v.)?
   • Các chỉ số?
   • Những hạn chế?
   • Định nghĩa bảng?
   • Tập lệnh thay đổi bảng? (ví dụ: tập lệnh ALTER)
   • Mọi điều?
   • Mọi thứ và:
     • Đừng quên dữ liệu tĩnh (danh sách tra cứu, v.v.), vì vậy bạn không cần sao chép BẤT KỲ dữ liệu nào giữa các môi trường
     • Chỉ giữ phiên bản hiện tại của các tập lệnh cơ sở dữ liệu (tất nhiên là phiên bản được kiểm soát) và
     • Lưu trữ các tập lệnh ALTER: 1 tập lệnh LỚN (hoặc thư mục các tập lệnh có tên thích 001_AlterXXX.sql, để chạy chúng theo thứ tự sắp xếp tự nhiên sẽ nâng cấp từ phiên bản A lên B)
3. Những loại đối tượng nào không nên được kiểm soát phiên bản?
   • Trình tự?
   • Trợ cấp?
   • Tài khoản người dùng?
   • xem phần 2. Nếu người dùng / vai trò (hoặc tên người dùng kỹ thuật) của bạn khác nhau giữa các môi trường, bạn vẫn có thể viết kịch bản cho chúng bằng cách sử dụng các mẫu (xem 1.)
4. Các đối tượng cơ sở dữ liệu nên được tổ chức như thế nào trong kho SCM của bạn?
   • Làm thế nào để bạn đối phó với những thứ một lần như tập lệnh chuyển đổi hoặc tập lệnh ALTER?
   • xem 2.
   • Bạn xử lý như thế nào khi gỡ bỏ các đối tượng khỏi cơ sở dữ liệu?
   • bị xóa khỏi DB, bị xóa khỏi trung kế / mẹo điều khiển nguồn
   • Ai sẽ chịu trách nhiệm thúc đẩy các đối tượng từ cấp độ phát triển đến cấp độ thử nghiệm?
   • lịch trình dev / test / phát hành
   • Làm thế nào để bạn điều phối các thay đổi từ nhiều nhà phát triển?
   • cố gắng KHÔNG tạo cơ sở dữ liệu riêng cho từng nhà phát triển. bạn sử dụng kiểm soát nguồn, phải không? trong trường hợp này, các nhà phát triển thay đổi cơ sở dữ liệu và đăng ký các tập lệnh. để hoàn toàn an toàn, hãy tạo lại cơ sở dữ liệu từ các tập lệnh trong quá trình xây dựng hàng đêm
   • Làm thế nào để bạn đối phó với việc phân nhánh cho các đối tượng cơ sở dữ liệu được sử dụng bởi nhiều hệ thống?
   • khó khăn nhất: cố gắng tránh bằng mọi giá.
5. Những ngoại lệ nào, nếu có, có thể hợp lý cho quá trình này?
   • Vấn đề an ninh?
   • không lưu trữ mật khẩu để kiểm tra / sản phẩm. bạn có thể cho phép nó cho nhà phát triển, đặc biệt nếu bạn đã tự động xây dựng lại DB hàng ngày / hàng đêm
   • Dữ liệu có mối quan tâm về xác định danh tính?
   • Tập lệnh không thể hoàn toàn tự động?
   • tài liệu và lưu trữ với thông tin phát hành / tập lệnh ALTER
6. Làm thế nào bạn có thể làm cho quy trình trở nên linh hoạt và khả thi?
   • Lỗi của nhà phát triển?
   • được thử nghiệm với bản dựng hàng ngày từ đầu và so sánh kết quả với nâng cấp gia tăng (từ phiên bản A lên B bằng ALTER). so sánh cả lược đồ kết quả và dữ liệu tĩnh
   • Đối với các vấn đề môi trường không mong muốn?
   • sử dụng kiểm soát phiên bản và sao lưu
   • so sánh lược đồ cơ sở dữ liệu PROD với những gì bạn nghĩ, đặc biệt là trước khi triển khai. SuperDuperCool DBA có thể đã sửa một lỗi chưa từng có trong hệ thống bán vé của bạn :)
   • Để khắc phục thảm họa?
7. Làm thế nào để bạn thuyết phục những người ra quyết định rằng lợi ích của DB-SCM thực sự phù hợp với chi phí?
   • Bằng chứng giai thoại?
   • Nghiên cứu ngành?
   • Khuyến nghị thực tiễn tốt nhất trong ngành?
   • Kháng cáo lên các cơ quan chức năng được công nhận?
   • Phân tích lợi ích chi phí?
   • Nếu các nhà phát triển và DBA đồng ý, bạn không cần phải thuyết phục bất cứ ai, tôi nghĩ (Trừ khi bạn cần tiền để mua một phần mềm như dbGhost cho MSSQL)
8. Ai nên "sở hữu" các đối tượng cơ sở dữ liệu trong mô hình này?
   • Các nhà phát triển?
   • DBA?
   • Nhà phân tích dữ liệu?
   • Nhiều hơn một?
   • Thông thường các DBA phê duyệt mô hình (trước khi nhận phòng hoặc sau khi xem xét mã). Họ chắc chắn sở hữu các đối tượng liên quan đến hiệu suất. Nhưng nói chung nhóm sở hữu nó [và tất nhiên là chủ nhân :)]

Tôi coi SQL là mã nguồn khi có thể

Nếu tôi có thể viết nó bằng SQL tuân thủ tiêu chuẩn thì nó thường nằm trong một tệp trong điều khiển nguồn của tôi. Tệp sẽ định nghĩa càng nhiều càng tốt chẳng hạn như SP, câu lệnh Table CREATE.

Tôi cũng bao gồm dữ liệu giả để thử nghiệm trong kiểm soát nguồn:

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

Và sau đó tôi tóm tắt tất cả các truy vấn SQL của mình để có thể xây dựng toàn bộ dự án cho MySQL, Oracle, MSSQL hoặc bất kỳ thứ gì khác.

Tự động hóa xây dựng và thử nghiệm sử dụng các tập lệnh xây dựng này vì chúng cũng quan trọng như nguồn ứng dụng và kiểm tra mọi thứ từ tính toàn vẹn thông qua trình kích hoạt, thủ tục và ghi nhật ký.

Chúng tôi sử dụng tích hợp liên tục thông qua TeamCity. Tại mỗi lần đăng ký kiểm soát nguồn, cơ sở dữ liệu và tất cả dữ liệu kiểm tra được xây dựng lại từ đầu, sau đó là mã, sau đó chạy các bài kiểm tra đơn vị dựa trên mã. Nếu bạn đang sử dụng công cụ tạo mã như CodeSmith, nó cũng có thể được đặt vào quy trình xây dựng của bạn để tạo lớp truy cập dữ liệu của bạn mới với mỗi bản dựng, đảm bảo rằng tất cả các lớp của bạn "khớp" và không tạo ra lỗi do thông số SP không khớp hoặc thiếu cột.

Mỗi bản dựng có bộ sưu tập các tập lệnh SQL riêng được lưu trữ trong thư mục $ project \ SQL \ trong điều khiển nguồn, được gán một tiền tố số và được thực thi theo thứ tự. Bằng cách đó, chúng tôi đang thực hành quy trình triển khai của mình ở mọi bản dựng.

Tùy thuộc vào bảng tra cứu, hầu hết các giá trị tra cứu của chúng tôi cũng được lưu trữ trong các tập lệnh và chạy để đảm bảo dữ liệu cấu hình là những gì chúng tôi mong đợi, chẳng hạn như "reason_codes" hoặc "country_codes". Bằng cách này, chúng tôi có thể thực hiện thay đổi dữ liệu tra cứu trong nhà phát triển, kiểm tra nó và sau đó "quảng bá" nó thông qua QA và sản xuất, thay vì sử dụng một công cụ để sửa đổi các giá trị tra cứu trong sản xuất, điều này có thể gây nguy hiểm cho thời gian hoạt động.

Chúng tôi cũng tạo một tập hợp các tập lệnh "khôi phục" để hoàn tác các thay đổi cơ sở dữ liệu của chúng tôi, trong trường hợp quá trình xây dựng để sản xuất gặp trục trặc. Bạn có thể kiểm tra các tập lệnh khôi phục bằng cách chạy chúng, sau đó chạy lại các bài kiểm tra đơn vị cho bản dựng một phiên bản bên dưới của bạn, sau khi các tập lệnh triển khai của nó chạy.

+1 cho Liquibase : LiquiBase là một thư viện mã nguồn mở (LGPL), độc lập với cơ sở dữ liệu để theo dõi, quản lý và áp dụng các thay đổi cơ sở dữ liệu. Nó được xây dựng trên một tiền đề đơn giản: Tất cả các thay đổi cơ sở dữ liệu (cấu trúc và dữ liệu) được lưu trữ theo cách mô tả dựa trên XML và được kiểm tra trong điều khiển nguồn. Điểm tốt là các thay đổi DML được lưu trữ theo ngữ nghĩa, không chỉ khác biệt, để bạn có thể theo dõi mục đích của các thay đổi.

Nó có thể được kết hợp với kiểm soát phiên bản GIT để tương tác tốt hơn. Tôi sẽ định cấu hình môi trường dành cho nhà phát triển của chúng tôi để dùng thử.

Ngoài ra, bạn có thể sử dụng Maven, Ant xây dựng hệ thống để xây dựng mã sản xuất từ ​​các tập lệnh.

Điểm trừ là LiquiBase không tích hợp vào SQL IDE phổ biến và bạn nên tự thực hiện các thao tác cơ bản.

Để bổ sung cho điều này, bạn có thể sử dụng DBUnit để kiểm tra DB - công cụ này cho phép các tập lệnh tạo dữ liệu được sử dụng để kiểm tra môi trường sản xuất của bạn với tính năng dọn dẹp sau đó.

IMHO:

1. Lưu trữ DML trong các tệp để bạn có thể phiên bản chúng.
2. Tự động hóa quy trình xây dựng lược đồ từ kiểm soát nguồn.
3. Đối với mục đích thử nghiệm, nhà phát triển có thể sử dụng DB cục bộ được xây dựng từ điều khiển nguồn thông qua hệ thống xây dựng + thử nghiệm tải Dữ liệu có tập lệnh hoặc tập lệnh DBUnit (từ Điều khiển nguồn).
4. LiquiBase cho phép bạn cung cấp "trình tự chạy" của các tập lệnh để tôn trọng sự phụ thuộc.
5. Nên có đội DBA kiểm tra bữa nửa buổi chính với TẤT CẢ các thay đổi trước khi sử dụng sản xuất. Ý tôi là họ kiểm tra đường trục / chi nhánh từ các DBA khác trước khi chuyển vào đường trục MASTER. Vì vậy, tổng thể đó luôn nhất quán và sẵn sàng sản xuất.

Chúng tôi phải đối mặt với tất cả các vấn đề đã đề cập về thay đổi mã, hợp nhất, viết lại trong cơ sở dữ liệu sản xuất thanh toán của chúng tôi. Chủ đề này là tuyệt vời để khám phá tất cả những thứ đó.

Bằng cách đặt "câu hỏi trêu ghẹo", bạn dường như quan tâm đến cuộc thảo luận hơn là ý kiến ​​của ai đó về câu trả lời cuối cùng. Danh sách gửi thư tích cực (> 2500 thành viên) nhanh chóng đã giải quyết nhiều câu hỏi trong số này và theo kinh nghiệm của tôi, đây là một diễn đàn dân sự và phức tạp cho loại thảo luận này.

Về cơ bản tôi đồng ý với mọi câu trả lời của van . Để hiểu rõ hơn, cơ sở của tôi để quản lý cơ sở dữ liệu là loạt bài của K. Scott Allen (phải đọc, IMHO. Có vẻ như ý kiến ​​của Jeff cũng vậy).

• Đối tượng cơ sở dữ liệu luôn có thể được xây dựng lại từ đầu bằng cách tung ra một tập tin SQL duy nhất (mà bản thân có thể gọi file SQL khác): Create.sql. Điều này có thể bao gồm chèn dữ liệu tĩnh (danh sách ...).
• Các tập lệnh SQL được tham số hóa để không có thông tin nhạy cảm và / phụ thuộc vào môi trường được lưu trữ trong các tệp thuần túy.
• Tôi sử dụng một tập tin thực thi tùy chỉnh để ra mắt Create.sql: Create.cmd. Mục tiêu của nó chủ yếu là kiểm tra các điều kiện tiên quyết (công cụ, biến môi trường ...) và gửi các tham số tới tập lệnh SQL. Nó cũng có thể tải hàng loạt dữ liệu tĩnh từ tệp CSV cho các vấn đề về hiệu suất.
• Thông thường, thông tin đăng nhập của người dùng hệ thống sẽ được chuyển dưới dạng tham số cho Create.cmdtệp.

IMHO, tải dữ liệu động sẽ yêu cầu một bước khác, tùy thuộc vào môi trường của bạn. Các nhà phát triển sẽ muốn tải cơ sở dữ liệu của họ với dữ liệu thử nghiệm, rác hoặc không có dữ liệu nào, trong khi ở đầu kia, các nhà quản lý sản xuất sẽ muốn tải dữ liệu sản xuất. Tôi cũng sẽ cân nhắc việc lưu trữ dữ liệu thử nghiệm trong kiểm soát nguồn (ví dụ: để dễ dàng kiểm tra đơn vị).

Khi phiên bản đầu tiên của cơ sở dữ liệu đã được đưa vào sản xuất, bạn sẽ không chỉ cần xây dựng các tập lệnh (chủ yếu dành cho nhà phát triển) mà còn phải nâng cấp các tập lệnh (dựa trên các nguyên tắc tương tự):

• Phải có một cách để lấy phiên bản từ cơ sở dữ liệu (tôi sử dụng một thủ tục được lưu trữ, nhưng một bảng cũng sẽ làm được).
• Trước khi phát hành phiên bản mới, tôi tạo một Upgrade.sqltệp (có thể gọi những cái khác) cho phép nâng cấp phiên bản N-1 lên phiên bản N (N là phiên bản đang được phát hành). Tôi lưu trữ tập lệnh này trong một thư mục có tên N-1.
• Tôi có một tập tin thực thi mà không được nâng cấp: Upgrade.cmd. Nó có thể truy xuất phiên bản hiện tại (CV) của cơ sở dữ liệu thông qua một câu lệnh SELECT đơn giản, khởi chạy Upgrade.sqltập lệnh được lưu trữ trong CVthư mục và lặp lại cho đến khi không tìm thấy thư mục nào. Bằng cách này, bạn có thể tự động nâng cấp từ N-3 lên N.

Các vấn đề với điều này là:

• Rất khó để tự động so sánh các lược đồ cơ sở dữ liệu, tùy thuộc vào các nhà cung cấp cơ sở dữ liệu. Điều này có thể dẫn đến các tập lệnh nâng cấp không hoàn chỉnh.
• Mọi thay đổi đối với môi trường sản xuất (thường là bởi các DBA để điều chỉnh hiệu suất) cũng nên tìm cách kiểm soát nguồn. Để đảm bảo điều này, thường có thể ghi lại mọi sửa đổi vào cơ sở dữ liệu thông qua một trình kích hoạt. Nhật ký này được đặt lại sau mỗi lần nâng cấp.
• Tuy nhiên, lý tưởng hơn, các thay đổi do DBA khởi xướng nên là một phần của quá trình phát hành / nâng cấp khi có thể.

Bạn muốn có loại đối tượng cơ sở dữ liệu nào dưới quyền kiểm soát nguồn? Vâng, tôi sẽ nói càng nhiều càng tốt, nhưng không nhiều hơn ;-) Nếu bạn muốn tạo người dùng bằng mật khẩu, hãy lấy cho họ một mật khẩu mặc định (đăng nhập / đăng nhập, thực tế cho mục đích thử nghiệm đơn vị) và thực hiện thay đổi mật khẩu theo thao tác thủ công . Điều này xảy ra rất nhiều với Oracle nơi các lược đồ cũng là người dùng ...

Chúng tôi có dự án Silverlight với cơ sở dữ liệu MSSQL trong điều khiển phiên bản Git. Cách dễ nhất là đảm bảo rằng bạn đã có một cơ sở dữ liệu được thu gọn (nội dung khôn ngoan) và thực hiện kết xuất hoàn chỉnh từ fe Visual Studio. Sau đó, bạn có thể thực hiện 'sqlcmd' từ tập lệnh xây dựng của mình để tạo lại cơ sở dữ liệu trên mỗi máy phát triển.

Đối với việc triển khai, điều này là không thể vì cơ sở dữ liệu quá lớn: đó là lý do chính để có chúng trong cơ sở dữ liệu ngay từ đầu.

Tôi thực sự tin rằng DB phải là một phần của kiểm soát nguồn và ở một mức độ lớn của quá trình xây dựng. Nếu nó nằm trong quyền kiểm soát nguồn thì tôi có cùng các biện pháp bảo vệ an toàn mã hóa khi viết một thủ tục được lưu trữ trong SQL như khi tôi viết một lớp trong C #. Tôi làm điều này bằng cách bao gồm một thư mục tập lệnh DB dưới cây nguồn của tôi. Thư mục script này không nhất thiết phải có một tệp cho một đối tượng trong cơ sở dữ liệu. Đó sẽ là một cơn đau ở mông! Tôi phát triển trong db của mình chỉ là một dự án mã của tôi. Sau đó, khi tôi sẵn sàng đăng ký, tôi thực hiện sự khác biệt giữa phiên bản cuối cùng của cơ sở dữ liệu của tôi và phiên bản hiện tại tôi đang làm việc. Tôi sử dụng SQL Compare cho việc này và nó tạo ra một tập lệnh của tất cả các thay đổi. Tập lệnh này sau đó được lưu vào thư mục db_update của tôi với quy ước đặt tên cụ thể 1234_TasksCompletedInThisIteration trong đó số là số tiếp theo trong tập hợp các tập lệnh đã có ở đó và tên mô tả những gì đang được thực hiện trong đăng ký này. Tôi thực hiện theo cách này vì như một phần của quá trình xây dựng của tôi, tôi bắt đầu với một cơ sở dữ liệu mới, sau đó được xây dựng theo chương trình bằng cách sử dụng các tập lệnh trong thư mục này. Tôi đã viết một tác vụ NAnt tùy chỉnh lặp qua từng tập lệnh thực thi nội dung của nó trên db trần. Rõ ràng nếu tôi cần một số dữ liệu để đi vào db thì tôi cũng có các tập lệnh chèn dữ liệu. Điều này cũng có nhiều lợi ích. Một, tất cả nội dung của tôi đều được tạo phiên bản. Thứ hai, mỗi bản dựng là một bản dựng mới có nghĩa là sẽ không có bất kỳ thứ gì lén lút xâm nhập vào quá trình phát triển của tôi (chẳng hạn như dữ liệu bẩn gây ra sự kỳ quặc trong hệ thống). Thứ ba, khi một người mới được thêm vào nhóm phát triển, họ chỉ cần cập nhật bản mới nhất và nhà phát triển cục bộ của họ được xây dựng cho họ một cách nhanh chóng. Thứ tư, tôi có thể chạy các trường hợp thử nghiệm (tôi không gọi đó là "bài kiểm tra đơn vị"!) Trên cơ sở dữ liệu của mình khi trạng thái của cơ sở dữ liệu được đặt lại với mỗi bản dựng (có nghĩa là tôi có thể kiểm tra kho lưu trữ của mình mà không phải lo lắng về việc thêm dữ liệu thử nghiệm vào db).

Cái này không dành cho tất cả mọi người.

Điều này không dành cho mọi dự án. Tôi thường làm việc trong các dự án về lĩnh vực xanh cho phép tôi thuận tiện hơn!

Thay vì đi vào các cuộc tranh luận về tháp trắng, đây là một giải pháp đã hoạt động rất hiệu quả đối với tôi đối với các vấn đề trong thế giới thực.

Xây dựng cơ sở dữ liệu từ đầu có thể được tóm tắt là quản lý các tập lệnh sql.

DBdeploy là một công cụ sẽ kiểm tra trạng thái hiện tại của cơ sở dữ liệu - ví dụ như những tập lệnh nào đã được chạy trước đó trên nó, những tập lệnh nào có sẵn để chạy và do đó những tập lệnh nào cần được chạy.

Sau đó, nó sẽ đối chiếu tất cả các tập lệnh cần thiết với nhau và chạy chúng. Sau đó, nó ghi lại những tập lệnh nào đã được chạy.

Nó không phải là công cụ đẹp nhất hay phức tạp nhất - nhưng với sự quản lý cẩn thận, nó có thể hoạt động rất tốt. Nó là mã nguồn mở và có thể mở rộng dễ dàng. Một khi việc chạy các tập lệnh được xử lý tốt, việc thêm một số thành phần bổ sung như tập lệnh shell kiểm tra các tập lệnh mới nhất và chạy dbdeploy đối với một phiên bản cụ thể có thể dễ dàng đạt được.

Xem giới thiệu hay tại đây:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Bạn có thể thấy rằng Liquibase xử lý rất nhiều thứ bạn đang tìm kiếm.

Mỗi nhà phát triển nên có cơ sở dữ liệu cục bộ của riêng họ và sử dụng kiểm soát mã nguồn để xuất bản cho nhóm. Giải pháp của tôi là đây: http://dbsourcetools.codeplex.com/ Chúc các bạn vui vẻ, - Nathan