Chiến lược triển khai cơ sở dữ liệu (SQL Server)

Question

Tôi đang tìm cách triển khai hàng ngày và giữ cho các tập lệnh cơ sở dữ liệu phù hợp với bản phát hành.

Hiện tại, chúng tôi có cách triển khai khá hợp lý nguồn của mình, chúng tôi có phạm vi mã đơn vị, tích hợp liên tục và quy trình quay vòng.

Sự cố đang giữ các tập lệnh cơ sở dữ liệu phù hợp với bản phát hành. Mọi người dường như thử kịch bản trên cơ sở dữ liệu thử nghiệm, sau đó chạy chúng trên trực tiếp, khi ánh xạ ORM được cập nhật (tức là, các thay đổi sẽ xuất hiện) thì nó sẽ chọn cột mới.

Vấn đề đầu tiên là không có tập lệnh nào được viết ở bất kỳ đâu, thường là mọi người "cố gắng" để đưa chúng vào thư mục Subversion nhưng một số người lười biếng chỉ chạy tập lệnh trực tiếp và hầu hết không có ai biết ai đã làm gì với cơ sở dữ liệu. Vấn đề thứ hai là chúng tôi có 4 cơ sở dữ liệu thử nghiệm và họ luôn luôn nằm ngoài hàng và cách duy nhất để thực sự xếp hàng chúng trở lại là thực hiện khôi phục từ cơ sở dữ liệu trực tiếp.

Tôi tin tưởng rằng một quy trình như thế này cần đơn giản, dễ hiểu và dễ sử dụng để giúp nhà phát triển, không cản trở họ.

Điều tôi đang tìm kiếm là các kỹ thuật/ý tưởng giúp dễ dàng cho nhà phát triển muốn ghi lại tập lệnh cơ sở dữ liệu của họ để chúng có thể được chạy như một phần của quy trình phát hành. Quy trình mà nhà phát triển muốn thực hiện theo số.

Mọi câu chuyện, trường hợp sử dụng hoặc thậm chí là liên kết sẽ hữu ích.

Answer 1

Đối với vấn đề này, tôi đã chọn sử dụng công cụ di chuyển: Migratordotnet.

Với di chuyển (trong bất kỳ công cụ nào), bạn có một lớp đơn giản được sử dụng để thực hiện các thay đổi của bạn và hoàn tác chúng. Dưới đây là ví dụ:

[Migration(62)] 
public class _62_add_date_created_column : Migration 
{ 
    public void Up() 
    { 
     //add it nullable 
     Database.AddColumn("Customers", new Column("DateCreated", DateTime)); 

     //seed it with data 
     Database.Execute("update Customers set DateCreated = getdate()"); 

     //add not-null constraint 
     Database.AddNotNullConstraint("Customers", "DateCreated"); 
    } 

    public void Down() 
    { 
     Database.RemoveColumn("Customers", "DateCreated"); 
    } 
} 

Ví dụ này cho thấy cách bạn có thể xử lý cập nhật dễ bay hơi, như thêm cột không rỗng mới vào bảng có dữ liệu hiện có. Điều này có thể được tự động dễ dàng, và bạn có thể dễ dàng đi lên và xuống giữa các phiên bản.

Đây là một sự bổ sung thực sự có giá trị đối với bản dựng của chúng tôi và đã sắp xếp hợp lý quy trình vô cùng.

tôi đã đăng một so sánh của các khuôn khổ di cư khác nhau trong .NET ở đây: http://benscheirman.com/2008/06/net-database-migration-tool-roundup

Answer 2

Đọc K.Scott Allen's series of posts on database versioning.
Chúng tôi đã xây dựng một công cụ để áp dụng các tập lệnh cơ sở dữ liệu theo cách được kiểm soát dựa trên các kỹ thuật mà anh mô tả và nó hoạt động tốt.
Điều này sau đó có thể được sử dụng như một phần của quá trình tích hợp liên tục với mỗi cơ sở dữ liệu thử nghiệm có thay đổi được triển khai cho nó khi một cam kết được thực hiện cho URL bạn giữ các kịch bản nâng cấp cơ sở dữ liệu. để bạn luôn có thể chạy một chuỗi các tập lệnh để lấy cơ sở dữ liệu từ phiên bản hiện tại của nó sang trạng thái mới cần thiết.
Điều này vẫn đòi hỏi một số quy trình và kỷ luật từ các nhà phát triển mặc dù (tất cả các thay đổi cần phải được đưa vào một phiên bản mới của tập lệnh cài đặt cơ bản và tập lệnh vá).

Answer 3

Bạn nên cân nhắc sử dụng công cụ xây dựng như MSBuild hoặc NAnt. Chúng tôi sử dụng kết hợp CruiseControl.NET, NAnt và SourceGear Fortress để xử lý các triển khai của chúng tôi, bao gồm các đối tượng SQL. Nhiệm vụ build db của NAnt gọi sqlcmd.exe để cập nhật các script trong môi trường dev và dàn dựng của chúng sau khi chúng được kiểm tra vào Fortress.

Answer 4

Go đây:

http://www.codinghorror.com/blog/archives/001050.html

Cuộn xuống một chút vào danh sách 5 liên kết đến các trang web odetocode.com. Chuỗi năm phần tuyệt vời. Tôi sẽ sử dụng nó như là một điểm khởi đầu để có được ý tưởng và tìm ra một quá trình sẽ làm việc cho nhóm của bạn.

Answer 5

Nếu bạn đang nói về việc cố giữ các lược đồ cơ sở dữ liệu đồng bộ, hãy thử sử dụng Red Gate SQL Comparison SDK. Xây dựng một cơ sở dữ liệu tạm thời dựa trên một kịch bản tạo (newDb) - đây là những gì bạn muốn cơ sở dữ liệu của bạn trông như thế nào. So sánh newDb với cơ sở dữ liệu cũ của bạn (oldDb). Lấy một thay đổi được đặt từ so sánh đó và áp dụng nó bằng cách sử dụng Red Gate.Bạn có thể xây dựng quy trình nâng cấp này vào các thử nghiệm của bạn và bạn có thể thử và nhận tất cả các nhà phát triển để đồng ý rằng có một nơi mà kịch bản tạo cho cơ sở dữ liệu được lưu giữ. Thực hành tương tự này hoạt động tốt để nâng cấp cơ sở dữ liệu của bạn trên nhiều phiên bản và chạy các tập lệnh di chuyển dữ liệu và các quy trình giữa mỗi bước (sử dụng tài liệu XML để ánh xạ tập lệnh tạo và di chuyển dữ liệu)

Chỉnh sửa: Với kỹ thuật Cổng đỏ, bạn chỉ liên quan đến việc tạo tập lệnh, chứ không phải nâng cấp tập lệnh kể từ khi Red Gate xuất hiện cùng với tập lệnh nâng cấp. Nó cũng sẽ cho phép bạn thả và tạo chỉ mục, các thủ tục lưu trữ, chức năng, vv

Answer 6

Chúng tôi đã sử dụng SQL So sánh từ RedGate cho một vài năm nay:

http://www.red-gate.com/products/index.htm

Phiên bản pro có giao diện dòng lệnh mà bạn có thể sử dụng để thiết lập các quy trình triển khai của mình.

Answer 7

Chúng tôi sử dụng một phiên bản sửa đổi của phiên bản cơ sở dữ liệu được mô tả bởi K. Scott Allen. Chúng tôi sử dụng Database Publishing Wizard để tạo tập lệnh cơ bản ban đầu. Sau đó, một công cụ C# tùy chỉnh dựa trên SQL SMO để kết xuất các thủ tục, các khung nhìn và các hàm người dùng được lưu trữ. Thay đổi tập lệnh chứa các thay đổi lược đồ và dữ liệu được tạo bởi các công cụ Red Gate. Vì vậy, chúng tôi kết thúc với một cấu trúc giống như

Database\ 
    ObjectScripts\ - contains stored procs, views and user funcs 1-per file 
    \baseline.sql - database snapshot which includes tables and data 
    \sc.01.00.0001.sql - incremental change scripts 
    \sc.01.00.0002.sql 
    \sc.01.00.0003.sql 

Các công cụ tùy chỉnh tạo ra cơ sở dữ liệu nếu cần thiết, áp dụng baseline.sql nếu cần thiết, bổ sung một bảng SchemaChanges nếu cần thiết và áp dụng các kịch bản thay đổi khi cần thiết dựa trên những gì trong Bảng SchemaChanges. Quá trình đó xảy ra như là một phần của kịch bản xây dựng nant mỗi khi chúng ta thực hiện xây dựng triển khai thông qua cc.net.

Nếu ai đó muốn mã nguồn cho ứng dụng schemachanger tôi có thể ném nó lên trên codeplex/google hoặc bất cứ nơi nào.

Answer 8

Có một loạt các liên kết trong các bài đăng này mà tôi sẽ muốn theo dõi (hệ thống của tôi "cuộn của riêng tôi" năm trước, phải xem có tương đồng) hay không. Một điều bạn sẽ cần, và rằng tôi hy vọng được đề cập trong các liên kết này, là kỷ luật. Tôi không hoàn toàn thấy cách bất kỳ hệ thống tự động nào có thể hoạt động nếu bất kỳ ai cũng có thể thay đổi bất cứ điều gì bất cứ lúc nào. (Câu hỏi của bạn ngụ ý rằng điều này có thể xảy ra trên hệ thống sản xuất của bạn, nhưng rõ ràng điều đó không thể đúng.)

Dành riêng cho nhiệm vụ quản lý thay đổi cơ sở dữ liệu, đặc biệt là sản xuất cơ sở dữ liệu, là một giải pháp rất phổ biến.Đối với việc duy trì tính nhất quán trên cơ sở dữ liệu phát triển và thử nghiệm X: nếu nó/chúng được sử dụng bởi nhiều người dùng, một lần nữa bạn được phục vụ tốt nhất bằng cách thực hiện một hành động cá nhân như một "ngôi nhà thanh toán bù trừ" cho các thay đổi; nếu mọi người có cá thể cơ sở dữ liệu riêng của họ, thì họ chịu trách nhiệm giữ nó theo thứ tự và có cơ sở dữ liệu "nguồn" trung tâm nhất quán sẽ rất quan trọng khi họ cần một cơ sở dữ liệu cơ sở được làm mới.

Dưới đây là một bài đăng gần đây Stack Overflow rằng có thể quan tâm: how-to-refresh-a-test-instance-of-sql-server-with-production-data-without-using

Answer 9

Cuốn sách Refactoring Databases địa chỉ nhiều về những vấn đề ở mức độ khái niệm.

Theo như các công cụ, tôi biết rằng DB Ghost hoạt động tốt cho SQL Server. Tôi đã nghe nói rằng phiên bản Data Dude của Visual Studio đã thực sự được minh chứng trong bản phát hành mới nhất nhưng tôi không có bất kỳ kinh nghiệm nào về nó.

Theo như thực sự kéo ra khỏi liên tục phát triển cơ sở dữ liệu phong cách tích hợp, nó được thực sự tài nguyên instensive thực sự nhanh chóng vì số lượng bản sao cơ sở dữ liệu bạn cần. Nó rất có thể thực hiện được khi cơ sở dữ liệu có thể vừa trên một trạm làm việc của nhà phát triển nhưng không thực tế khi cơ sở dữ liệu quá lớn mà nó cần được triển khai trên một mạng lưới. Để làm điều đó bạn về cơ bản cần 1 bản sao của cơ sở dữ liệu cho mỗi nhà phát triển [nhà phát triển thực hiện thay đổi DDL, không chỉ thay đổi cho procs] + 6 bản sao phổ biến. Các bản sao phổ biến như sau:

1. INT DEV -> Nhà phát triển "kiểm tra" việc tái cấu trúc để INT DEV để thử nghiệm tích hợp. Khi kiểm tra tích hợp vượt qua, cơ sở dữ liệu này được sao chép sang DEV.
2. DEV -> Đây là bản sao phát triển "chính thức" của cơ sở dữ liệu. INT DEV được làm mới thường xuyên với một bản sao của DEV. Các nhà phát triển làm việc trên các phép tái cấu trúc mới có được một bản sao mới của cơ sở dữ liệu từ DEV.
3. INT QA -> Ý tưởng tương tự như INT DEV ngoại trừ nhóm QA. Khi kiểm tra tích hợp vượt qua ở đây, cơ sở dữ liệu này được sao chép sang QA và tới DEV *.
4. QA
5. INT PROD -> Ý tưởng giống như INT QA ngoại trừ sản xuất. Khi thử nghiệm hội nhập vượt qua đây, cơ sở dữ liệu này được sao chép sang PROD, QA *, và DEV *
6. PROD

* Khi sao chép cơ sở dữ liệu trên dòng/QA/PROD DEV, bạn cũng sẽ cần phải chạy kịch bản để cập nhật dữ liệu thử nghiệm liên quan đến môi trường cụ thể (ví dụ: thiết lập người dùng trong QA mà nhóm QA sử dụng để kiểm tra nhưng không tồn tại trong sản xuất).

Answer 10

Chúng tôi sử dụng Visual Studio for Database Professionals và TFS để phiên bản và quản lý triển khai cơ sở dữ liệu của chúng tôi. Điều này cho phép chúng tôi xử lý cơ sở dữ liệu giống như mã (kiểm tra, kiểm tra, khóa, xem lịch sử phiên bản, chi nhánh, xây dựng, triển khai, thử nghiệm, v.v.) và thậm chí bao gồm chúng trong cùng một tệp giải pháp nếu muốn.

Các nhà phát triển của chúng tôi có thể làm việc trên cơ sở dữ liệu cục bộ để tránh bước vào những thay đổi của nhau trong môi trường được chia sẻ. Khi họ kiểm tra các thay đổi cơ sở dữ liệu vào TFS, chúng tôi đã tích hợp liên tục để xây dựng, kiểm tra và triển khai vào môi trường dev tích hợp của chúng tôi. Chúng tôi đã xây dựng riêng biệt trên các nhánh phát hành để tạo ra các kịch bản triển khai khác biệt cho từng môi trường tiếp theo.

Sau đó, nếu một lỗi được phát hiện trong bản phát hành, chúng tôi có thể đi tới chi nhánh phát hành và sửa mã và cơ sở dữ liệu cùng một lúc.

Đây là một sản phẩm tuyệt vời, nhưng việc áp dụng nó đã bị cản trở sớm do lỗi tiếp thị của Microsoft. Nó ban đầu là một sản phẩm riêng biệt trong Hệ thống Team.Điều này có nghĩa là để sử dụng các tính năng của phiên bản nhà phát triển và ấn bản cơ sở dữ liệu cùng một lúc, bạn được yêu cầu phải nâng cấp lên phiên bản Team Suite đắt hơn nhiều. Chúng tôi (và nhiều khách hàng khác) đã khiến Microsoft đau buồn về điều này, và chúng tôi rất vui khi họ công bố năm nay là DB Pro has been folded into the developer edition và ngay lập tức bất kỳ ai được cấp phép với phiên bản nhà phát triển đều có thể cài đặt ấn bản cơ sở dữ liệu.

Answer 11

Một giải pháp khả thi là xem xét triển khai kiểm tra DML trên cơ sở dữ liệu thử nghiệm của bạn, sau đó chỉ cần lăn các nhật ký kiểm tra đó vào một kịch bản để thử nghiệm cuối cùng và triển khai trực tiếp. SQL Server 2008 cải thiện đáng kể về kiểm tra DML, nhưng ngay cả SQL Server 2005 cũng hỗ trợ nó thông qua các trigger.

Answer 12

Gus được đề cập một cách trực tiếp DB Ghost (ở trên) - Tôi coi đây là giải pháp tiềm năng.

Một cái nhìn tổng quan ngắn gọn về cách công ty của tôi đang sử dụng DB Ghost:

• Sau schema cho một DB mới đã được giải quyết một cách hợp lý trong quá trình phát triển ban đầu, chúng tôi sử dụng Ghost DB 'dữ liệu và Schema scripter' để tạo tập lệnh (.sql) cho tất cả các đối tượng DB (và bất kỳ dữ liệu tĩnh nào) và chúng tôi kiểm tra các tệp kịch bản này vào điều khiển nguồn (công cụ tách các đối tượng thành các thư mục như 'Thủ tục lưu trữ', 'Bảng', v.v.) . Tại thời điểm này, chúng ta có thể sử dụng một trong hai công cụ DB GHost 'Packager' hoặc 'Packager Plus' để tạo một tệp thực thi độc lập để tạo một DB mới từ các tập lệnh này.
• Mọi thay đổi đối với lược đồ DB đều được đăng ký vào nguồn bằng cách đăng ký vào các tệp tập lệnh cụ thể.
• Bất cứ lúc nào, chúng tôi có thể sử dụng trình đóng gói để tạo tệp thực thi (a) tạo DB mới hoặc (b) cập nhật DB hiện tại. Một số tùy chỉnh là bắt buộc đối với một số thay đổi phụ thuộc vào đường dẫn nhất định (ví dụ: thay đổi yêu cầu dữ liệu được cập nhật), nhưng chúng tôi có các bản cập nhật trước và sau khi cập nhật tập lệnh được chạy.

Quá trình 'cập nhật' liên quan đến việc tạo một 'nguồn' DB sạch và sau đó (sau khi cập nhật tập lệnh tùy chỉnh), so sánh giữa lược đồ của DB nguồn và DB mục tiêu. DB Ghost cập nhật DB mục tiêu để khớp với

Chúng tôi thường xuyên thay đổi DB sản xuất (chúng tôi có 14 khách hàng trong 7 môi trường sản xuất khác nhau) nhưng chắc chắn triển khai một tập hợp đủ lớn thay đổi với bản cập nhật DB Ghost (được tạo trong quá trình xây dựng). Bất kỳ thay đổi sản xuất nào không được đăng ký nguồn (hoặc không được đăng ký vào chi nhánh thích hợp được phát hành) đều bị LOST. Điều này đã buộc mọi người phải đăng ký thay đổi một cách nhất quán.

Để tóm tắt:

• Nếu bạn thực thi một chính sách mà tất cả các bản cập nhật DB được triển khai sử dụng một DB ma cập nhật thực thi, bạn có thể 'lực' nhà phát triển để check-in liên tục thay đổi của họ, bất kể họ là được triển khai thủ công trong thời gian tạm thời.
• Thêm một bước (hoặc bước) vào quy trình xây dựng của bạn để tạo một bản cập nhật DB Ghost sẽ có hiệu lực thực hiện kiểm tra để xác minh rằng DB có thể được tạo từ tập lệnh (tức là vì DB Ghost tạo một DB nguồn '', ngay cả khi tạo gói thực thi cập nhật) và nếu bạn thêm một bước (hoặc bước) để thực thi gói cập nhật [trên bất kỳ bốn DB kiểm tra nào bạn đã đề cập], bạn có thể giữ cho các DB thử nghiệm của bạn phù hợp với nguồn.

Có một số hãy cẩn thận và một số hạn chế trong những thay đổi được 'dễ dàng' triển khai với công cụ này (thực sự là một bộ công cụ có liên quan), nhưng tất cả chúng đều khá nhỏ (ít nhất là cho công ty của tôi):

• Đổi tên đối tượng phải được thực hiện theo một trong các tập lệnh tùy chỉnh
• Toàn bộ DB luôn được cập nhật (ví dụ: các đối tượng trong một lược đồ không thể cập nhật được) gây khó khăn cho việc hỗ trợ các đối tượng khách hàng cụ thể trong ứng dụng chính DB

Answer 13

Red Gate có một bài báo mô tả cách đạt được tự động hóa xây dựng: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Được tích hợp với SSMS và hệ thống kiểm soát nguồn hiện tại của bạn.

Answer 14

Tôi đã viết một công cụ dựa trên .NET để xử lý phiên bản cơ sở dữ liệu theo cách tự động. Chúng tôi đã sử dụng công cụ này trong quá trình sản xuất để xử lý các bản cập nhật cơ sở dữ liệu (bao gồm các bản vá) cho nhiều môi trường, ghi nhật ký từng cơ sở dữ liệu đã chạy và thực hiện tất cả theo cách tự động. Nó có một giao diện điều khiển dòng lệnh để bạn có thể tạo các tập lệnh batch sử dụng công cụ này. Kiểm tra xem nó ra: https://github.com/bmontgomery/DatabaseVersioning

Answer 15

Đối với những gì đáng giá, đây là ví dụ thực sự về cách tiếp cận đơn giản, chi phí thấp được sử dụng bởi chủ nhân cũ của tôi (và tôi đang cố gây ấn tượng với chủ nhân hiện tại của tôi như là bước cơ bản đầu tiên).

Thêm bảng có tên 'DB_VERSION' hoặc tương tự. Trong MERYI kịch bản nâng cấp, hãy thêm hàng vào bảng có thể bao gồm ít hoặc nhiều cột như bạn thấy phù hợp để mô tả nâng cấp nhưng tối thiểu tôi sẽ đề xuất {VERSION, EXECUTION_DATE, DESCRIPTION, EXECUTION_USER}. Bây giờ bạn có một hồ sơ cụ thể về những gì đã xảy ra. Nếu ai đó chạy tập lệnh trái phép của riêng họ, bạn vẫn cần phải làm theo lời khuyên của các câu trả lời ở trên, nhưng đây chỉ là một cách đơn giản để cải thiện đáng kể trên điều khiển phiên bản hiện tại của bạn (ví dụ: không có).

Bây giờ, bạn có một kịch bản nâng cấp từ v2.1 đến v2.2 của cơ sở dữ liệu và bạn muốn xác minh anh chàng maverick đơn lẻ đã thực sự chạy nó trên cơ sở dữ liệu của mình, bạn chỉ có thể tìm kiếm các hàng nơi VERSION = 'v2 .2 'và nếu bạn nhận được kết quả, đừng chạy tập lệnh nâng cấp này. Có thể được tích hợp vào ứng dụng tiện ích bảng điều khiển nếu cần.