Cách tốt để di chuyển các thay đổi DB từ môi trường Phát triển sang QA sang Môi trường sản xuất là gì? Hiện tại chúng tôi:

1. Kịch bản thay đổi trong tệp SQL và đính kèm nó vào một mục công việc TFS.
2. Công việc được đánh giá ngang hàng
3. Khi công việc đã sẵn sàng để thử nghiệm thì SQL sẽ chạy trên QA.
4. Công việc được kiểm tra QA
5. Khi công việc đã sẵn sàng để sản xuất thì SQL sẽ chạy trên cơ sở dữ liệu sản xuất.

Vấn đề với điều này là nó rất thủ công. Nó phụ thuộc vào nhà phát triển ghi nhớ để đính kèm sql hoặc người đánh giá ngang hàng bắt nó nếu nhà phát triển quên. Đôi khi, cuối cùng, người thử nghiệm hoặc người triển khai QA là người phát hiện ra vấn đề.

Một vấn đề thứ hai là đôi khi bạn cần phải phối hợp các thay đổi theo cách thủ công nếu hai tác vụ riêng biệt thay đổi cùng một đối tượng cơ sở dữ liệu. Điều này có thể chỉ là như vậy nhưng có vẻ như vẫn nên có một số cách tự động để "gắn cờ" những vấn đề này hoặc một cái gì đó.

Thiết lập của chúng tôi: Cửa hàng phát triển của chúng tôi có đầy đủ các nhà phát triển với nhiều kinh nghiệm về DB. Các dự án của chúng tôi rất định hướng DB. Chúng tôi chủ yếu là một cửa hàng .NET và MS SQL. Hiện tại chúng tôi đang sử dụng MS TFS Work Item để theo dõi công việc của chúng tôi. Điều này rất hữu ích cho việc thay đổi mã vì nó liên kết các thay đổi với các mục công việc để tôi có thể tìm hiểu chính xác những thay đổi tôi cần đưa vào khi di chuyển sang môi trường QA và Sản xuất. Chúng tôi hiện không sử dụng dự án DB nhưng có thể chuyển sang dự án đó trong tương lai (có thể đó là một phần của câu trả lời).

Tôi rất quen với hệ thống kiểm soát nguồn của mình chăm sóc những thứ như thế này cho tôi và muốn có cùng một thứ cho SQL của tôi.

Trong môi trường VS, tôi luôn sử dụng các dự án cơ sở dữ liệu để triển khai các tập lệnh cập nhật. Tôi có xu hướng sử dụng các tên không thể tưởng tượng như "DatabaseUpdate17.sql" hoặc "PriceUpdateF / 2010.sql" cho các tập lệnh của tôi. Có chúng là các dự án cơ sở dữ liệu cho phép tôi buộc chúng vào các nhiệm vụ của Team Server, các lỗi (và nếu chúng tôi cũng đã đánh giá mã, cho chúng). Tôi cũng bao gồm trong mỗi cơ sở dữ liệu (mà tôi có thẩm quyền) một bảng dành riêng cho việc thu thập các thay đổi đối với lược đồ.

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

Vâng, điều đó chăm sóc 3 trong số 6 Ws .

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

Tôi bao gồm một câu lệnh chèn để ghi lại phần đầu của bản vá cũng như phần cuối của bản vá. Các sự kiện xảy ra bên ngoài các bản vá là những điều cần xem xét.

Ví dụ: phần chèn "bắt đầu bản vá" cho "bản vá 17" sẽ trông như sau:

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

Vì nó cũng bắt được khi các chỉ mục được xây dựng lại, bạn sẽ cần chạy các mục sau mỗi tháng hoặc lâu hơn để xóa các sự kiện đó:

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

Phiên bản trước đó được đăng trên Server Fault .

Trong môi trường tuân thủ SOX và PCI-DSS, bạn sẽ không bao giờ có quyền truy cập vào các máy chủ sản xuất. Do đó, các kịch bản cần phải rõ ràng và được thực hiện trước. Các ý kiến ​​ở đầu tập lệnh cập nhật bao gồm danh sách các bảng mới, procs được lưu trữ, hàm, v.v. cũng như danh sách các bảng đã sửa đổi, procs được lưu trữ, hàm, v.v. Nếu dữ liệu được sửa đổi, hãy giải thích những gì đang được sửa đổi và tại sao.

Một vấn đề thứ hai là đôi khi bạn cần phải phối hợp các thay đổi theo cách thủ công nếu hai tác vụ riêng biệt thay đổi cùng một đối tượng cơ sở dữ liệu. Điều này có thể chỉ là như vậy nhưng có vẻ như vẫn nên có một số cách tự động để "gắn cờ" những vấn đề này hoặc một cái gì đó.

Tôi chưa bao giờ bắt gặp một công cụ cho phép chúng tôi tự động theo dõi điều này. Các nhà tuyển dụng trước đây đã sử dụng nguyên tắc "chủ sở hữu cơ sở dữ liệu" - một và chỉ một người chịu trách nhiệm cá nhân về cơ sở dữ liệu. Người này sẽ không phải là nhà phát triển duy nhất làm việc với cơ sở dữ liệu đó, mà thay vào đó, tất cả các thay đổi phải trải qua. Điều này đã làm việc hợp lý tốt để giữ cho những thay đổi khỏi va chạm và làm hỏng lẫn nhau.

Bạn đã xem SQL Source Control chưa? Bạn có thể sử dụng nó để kết nối Máy chủ SQL của mình với TFS / SVN / Vault hoặc VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Một giải pháp khác là sử dụng một cái gì đó như PowerDesigner, ERWin, v.v để thiết kế và quản lý các thay đổi đối với cơ sở dữ liệu của bạn.

Chúng tôi đang bắt đầu chuyển sang chính sách nơi cơ sở dữ liệu được mô hình hóa trong PowerDesigner. Tất cả các thay đổi đối với cấu trúc / mã cơ sở dữ liệu được thực hiện trong mô hình, được kiểm tra vào kiểm soát nguồn và sau đó thay đổi các tập lệnh được tạo từ các mô hình để thực hiện các thay đổi trong cơ sở dữ liệu. Các kịch bản thay đổi này cũng được kiểm tra để kiểm soát nguồn. Những thay đổi lớn được đánh giá ngang hàng và PowerDesigner giúp việc này trở nên rất dễ dàng bằng cách sử dụng các tính năng tích hợp.

PowerDesigner là một công cụ mô hình hóa chung không chỉ hỗ trợ cơ sở dữ liệu, vì vậy chúng tôi bắt đầu sử dụng nó để quản lý các yêu cầu, tạo sơ đồ khái niệm, vật lý và kiến ​​trúc (OOM cũng vậy), v.v. Về cơ bản, chúng tôi đang sử dụng nó để cung cấp xương sống cho chúng tôi quy trình kỹ thuật phần mềm.

(Tôi không có cách nào liên kết với Sybase, người đã phát triển PowerDesigner - chỉ nghĩ rằng tôi sẽ ném nó vào đó).

DB ma

DB Ghost là công cụ yêu thích của tôi để quản lý cơ sở dữ liệu.

Lợi ích

1. Tất cả các đối tượng trong cơ sở dữ liệu của bạn được lưu trữ dưới dạng các tập lệnh trong kiểm soát nguồn.
2. Bạn cũng có thể tập lệnh 'dữ liệu tĩnh' (dữ liệu bảng tra cứu).
3. Bạn có thể cập nhật kiểm soát nguồn theo cách thủ công hoặc bằng cách tạo kịch bản cho cơ sở dữ liệu phát triển 'mô hình'.
4. Bạn có thể xây dựng cơ sở dữ liệu (nhanh chóng) từ các tập lệnh trong kiểm soát nguồn (bao gồm cả dữ liệu tĩnh).
5. Bạn có thể triển khai các thay đổi đối với các phiên bản của cơ sở dữ liệu, bao gồm mọi trường hợp sản xuất:
   • Bạn có thể so sánh 'cơ sở dữ liệu xây dựng' (được tạo từ các tập lệnh) với cơ sở dữ liệu hiện có và tạo tập lệnh thay đổi.
   • Bạn có thể hướng DB Ghost tự động đồng bộ hóa các thay đổi giữa hai phiên bản của cơ sở dữ liệu, ví dụ: cơ sở dữ liệu xây dựng và cơ sở dữ liệu sản xuất của bạn.

[4] đặc biệt tiện dụng để thực hiện các thay đổi cục bộ hoặc tạo các trường hợp riêng cho các môi trường khác nhau. Trên thực tế, thật dễ dàng khi tôi tạo một cơ sở dữ liệu riêng cho mọi tính năng hoặc lỗi tôi làm việc trên đó ảnh hưởng đến cơ sở dữ liệu.

Chi tiết

Ưu điểm chính của việc sử dụng nó so với việc duy trì các kịch bản di chuyển hoặc thay đổi rõ ràng là bạn hầu như không cần phải duy trì các kịch bản di chuyển hoặc thay đổi rõ ràng - bạn hầu như chỉ có thể duy trì 'phiên bản hiện tại' của cơ sở dữ liệu của mình. Một khía cạnh khó chịu của việc quản lý tập lệnh di chuyển là không có cách nào dễ dàng để xem, ví dụ: danh sách các cột trong bảng (dựa trên tập lệnh di chuyển). Tất nhiên một số thay đổi cần được thực hiện dưới dạng di chuyển rõ ràng, nhưng chúng đủ dễ để xử lý như các tập lệnh riêng biệt.

Một kết quả đặc biệt tốt đẹp của việc có thể quản lý cơ sở dữ liệu dưới dạng (một bộ) tập lệnh và cũng có thể nhanh chóng tạo các phiên bản mới là đơn vị kiểm tra mã cơ sở dữ liệu quan trọng là rất dễ dàng (và cũng khá thú vị). Tôi sử dụng tQueryt để kiểm tra đơn vị.

Tôi chỉ muốn có một công cụ tương tự cho các DBMS khác.

Tôi biết nó nghe có vẻ quá mức đối với hầu hết các DBA:

Bạn đã cân nhắc sử dụng Ruby on Rails để theo dõi các thay đổi của Cơ sở dữ liệu (và chỉ các thay đổi DB). Bạn không cần phải chạy bất kỳ ứng dụng nào hoặc viết bất kỳ mã ruby ​​nào, v.v. Nhưng tôi thấy phong cách di chuyển (đó là cách họ gọi nó) khá hữu ích: http://guides.rubyonrails.org/migations.html

Sql Server cũng được hỗ trợ, bạn có thể phải sử dụng JRuby + JDBC.