Nhóm thực hành tốt nhất làm việc với cơ sở dữ liệu

Question

Điều gì là tốt hơn cho nhóm làm việc trên DB? Có phải bản sao cơ sở dữ liệu cục bộ cho từng nhà phát triển hoặc cơ sở dữ liệu được chia sẻ không?

Answer 1

Theo kinh nghiệm của tôi, một nhóm phải có (ít nhất) một cơ sở dữ liệu được chia sẻ cho tích hợp.

Trong quá trình phát triển, mỗi thành viên trong nhóm phải có cơ sở dữ liệu riêng biệt, nếu không, các thay đổi của giản đồ cơ sở dữ liệu có thể cản trở các thành viên khác trong nhóm. Những trường hợp này cũng có thể nằm trên một máy chủ tập trung.

Answer 2

Từ kinh nghiệm, cơ sở dữ liệu được chia sẻ tốt hơn. Mã của chúng tôi được sử dụng để phá vỡ tất cả thời gian vì ai đó đã thêm một cột trên cơ sở dữ liệu cục bộ của họ, sau đó tải mã nguồn mới của họ lên SVN. Việc triển khai của mọi người khác sau đó sẽ bị phá vỡ cho đến khi họ tìm ra những gì đã thay đổi trong cơ sở dữ liệu.

Tôi sẽ có cơ sở dữ liệu được chia sẻ để phát triển. Chúng tôi cũng có một hoặc hai cơ sở dữ liệu dev để thử nghiệm linh tinh.

Answer 3

Tôi chỉ có thể nói về cách các đội bóng tôi đang ở hiện đang làm việc, mà phù hợp với nhu cầu của chúng tôi cũng đủ:

Chúng tôi có một kịch bản mô hình dữ liệu trung tâm mà cập nhật bất kỳ cơ sở dữ liệu tự động lên phiên bản giản đồ mới nhất. Các nhà phát triển kiểm tra các thay đổi đối với tập lệnh này cùng với các thay đổi đối với mã nguồn (cam kết đơn lẻ trên cùng một kho lưu trữ). Bản cập nhật hàng đêm cập nhật một bản sao cơ sở dữ liệu trung tâm, tiếp theo là một loạt các bài kiểm tra tự động trên cơ sở dữ liệu đó và nhóm QA của con người cũng sử dụng cùng cơ sở dữ liệu này vào ngày hôm sau cho tất cả các thử nghiệm của họ.

Chúng tôi không cho phép thay đổi giản đồ trên cá thể cơ sở dữ liệu trung tâm theo bất kỳ cách nào khác ngoài cách xây dựng tích hợp. Để phát triển kịch bản thay đổi lược đồ, các thay đổi được phát triển trên một cá thể cơ sở dữ liệu riêng biệt, hoặc trên máy chủ trung tâm, hoặc cục bộ (tùy thuộc vào sở thích cá nhân).

Answer 4

Tôi không nghĩ điều đó phụ thuộc chút nào. Mỗi môi trường nên có cá thể cơ sở dữ liệu riêng của nó. Cá nhân, tôi sẽ không bao giờ đề nghị mọi người trong nhóm làm việc trên cùng một bản sao của nguồn, và tôi xem mã cơ sở dữ liệu và cá thể giống như vậy.

Nếu bạn đang gặp vấn đề với những thay đổi cơ sở dữ liệu bị thiếu, đây là một triệu chứng của một vấn đề quy trình phát triển khác. Nó sẽ là analagous để quên thêm một tập tin mã để kiểm soát nguồn.

phát triển

Jeff Atwood has a pretty good article on source controlling database code.

khác nhau được cho là làm việc về các vấn đề khác nhau - làm thế nào để bạn tránh giẫm lên ngón chân của người khác trong khi kiểm tra đơn vị?

Tôi hoàn toàn sẽ ủng hộ môi trường tích hợp/kiểm tra, được cập nhật qua Continuous Integration process. Môi trường này thường phục vụ như là một bài kiểm tra litmus cho thủ tục triển khai của bạn.

Answer 5

Tại Redgate, chúng tôi khuyên mỗi nhà phát triển nên có ví dụ riêng của họ, vì hộp cát đảm bảo rằng các nhà phát triển không theo dõi các ngón chân của nhau. Tuy nhiên, có những ưu và khuyết điểm với cả hai mô hình.

Trong kinh nghiệm của chúng tôi nói chuyện với các nhà phát triển cơ sở dữ liệu, khoảng một nửa phát triển cơ sở dữ liệu được thực hiện trên môi trường chia sẻ và một nửa trên môi trường dành cho mỗi nhà phát triển.

Answer 6

Có trường hợp cơ sở dữ liệu riêng biệt cho nhà phát triển giúp họ làm việc riêng biệt tuy nhiên nếu chúng tôi là một nhóm lớn và làm việc nhiều thứ vào thời điểm đó thì tốt hơn là bạn nên có một môi trường chung để mọi thay đổi cần phải giao cùng một lúc không phá vỡ lẫn nhau và phụ thuộc của họ cũng có thể được tìm ra một cách chính xác. Điều này cũng giúp xác định nơi bất kỳ ứng dụng nào có thể bị hỏng do thay đổi. Vì vậy, tốt hơn là nên có một môi trường chung cùng với một số bản sao enviornment enviornment enviornment phát triển chỉ trong trường hợp chúng tôi có thể muốn thử nghiệm một cái gì đó lớn và phức tạp đó là rất quan trọng và cần phải làm việc dù sao đi nữa.

Nhưng vấn đề duy nhất là giữ nhiều môi trường đồng bộ với nhau vì bất kỳ thay đổi còn thiếu nào có thể gây tử vong.

Answer 7

Tôi biết mọi người ở đây đang nói về trải nghiệm quá khứ của họ nhưng đây không phải là một câu hỏi dễ dàng để trả lời phổ biến. Có những ưu và khuyết điểm đối với mỗi cách tiếp cận và cần được giải quyết dựa trên loại ứng dụng và nhóm mà bạn đang làm việc.

Nếu bạn không biết nên đi đường nào .. Tôi khuyên bạn nên sử dụng cơ sở dữ liệu phát triển được chia sẻ trước để xem bạn có gặp phải bất kỳ sự cố nào không. Nếu giải pháp này hoạt động, nó phải là phương pháp ưu tiên vì nó loại bỏ bước "tích hợp". Tuy nhiên, tùy thuộc vào loại nhu cầu của nhóm và môi trường, bạn có thể cần phải thích nghi.