DB değişikliklerini Geliştirme'den KG'ye Üretim ortamlarına geçirmenin iyi bir yolu nedir? Şu anda biz:

1. Değişikliği bir SQL dosyasında kodlayın ve bunu bir TFS iş öğesine ekleyin.
2. İş eş gözden geçirilir
3. İş test etmeye hazır olduğunda, SQL QA'da çalıştırılır.
4. İş QA test edildi
5. Çalışma üretime hazır olduğunda, SQL üretim veritabanlarında çalıştırılır.

Bununla ilgili sorun çok manuel olması. Geliştiricinin unutması durumunda sql'yi veya hakem değerlendiricisini yakalamayı hatırlatarak geliştiriciye güvenir. Bazen, sorunu keşfeden testçi veya KG görevlisi olur.

İkincil bir sorun, bazen iki ayrı görev aynı veritabanı nesnesini değiştirdiğinde değişiklikleri el ile koordine etmeniz gerekmesidir. Bu sadece bu şekilde olabilir, ancak yine de bu sorunları veya “bir şeyi” işaretlemenin otomatik bir yolu olmalı gibi görünüyor.

Kurulumumuz: Geliştirme mağazamız, çok sayıda DB deneyimi olan geliştiricilerle doludur. Projelerimiz çok DB odaklı. Biz esas olarak bir .NET ve MS SQL mağazasıyız. Şu anda çalışmamızı takip etmek için MS TFS İş Kalemleri kullanıyoruz. Bu, kod değişikliklerini iş öğelerine bağladığından kod değişiklikleri için kullanışlıdır, böylece QA ve Üretim ortamlarına geçiş yaparken ne gibi değişiklikler yapmam gerektiğini tam olarak öğrenebilirim. Şu anda bir DB projesi kullanmıyoruz, ancak gelecekte buna geçebilir (belki de cevabın bir parçası olabilir).

Kaynak kontrol sistemime benim için bu gibi şeylerle ilgilenmek için çok alışkınım ve SQL için de aynı şeyi yapmak istiyorum.

Bir VS ortamında, güncelleme komut dosyalarını uygulamak için her zaman veritabanı projeleri kullandım. Senaryolarım için "DatabaseUpdate17.sql" veya "PriceUpdateFebruary2010.sql" gibi yaratıcı olmayan isimler kullanıyorum. Onları veritabanı projesi olarak kullanmak, bunları Team Server görevlerine, hatalarına (ve kod incelemeleri yaparsak onlara da dahil etmeme) bağlamamı sağlıyor. Ayrıca her bir veritabanına (üzerinde yetkim var) özellikle şemadaki değişikliklerin toplanması için bir tablo eklerim.

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

Bu 6 W'nin 3'üyle ilgileniyor .

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

Bir yamanın başlangıcının yanı sıra bir yamanın sonunu günlüğe kaydetmek için bir insert ifadesi içerir. Yamaların dışında gerçekleşen olaylar, dikkat edilmesi gereken şeyler.

Örneğin, "yama 17" için "başlangıç ​​yaması" eki şöyle görünür:

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

Ayrıca, endekslerin yeniden oluşturulduğunu da yakaladığından, bu olayları silmek için her ay aşağıdakileri izlemeniz gerekir:

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

Sunucu Arızalarında daha önce yayınlanan önceki sürüm .

SOX ve PCI-DSS uyumlu bir ortamda, üretim sunucularına asla erişemezsiniz. Bu nedenle senaryoların önceden netleştirilmesi ve uygulanması gerekir. Güncelleme komut dosyalarının en üstündeki yorumlar, yeni tabloların, depolanan işlemlerin, işlevlerin vb. Listelerinin yanı sıra değiştirilen tabloların, depolanan işlemlerin, işlevlerin vb. Listelerini içerir.

İkincil bir sorun, bazen iki ayrı görev aynı veritabanı nesnesini değiştirdiğinde değişiklikleri el ile koordine etmeniz gerekmesidir. Bu sadece bu şekilde olabilir, ancak yine de bu sorunları veya “bir şeyi” işaretlemenin otomatik bir yolu olmalı gibi görünüyor.

Bunu otomatik olarak izlememizi sağlayan bir araçla hiç karşılaşmadım. Önceki işverenler “veri tabanı sahibi” ilkesini kullandılar - veri tabanından şahsen tek ve tek kişi. Bu kişi, bu veritabanına karşı çalışan tek geliştirici olmayacak, ancak tüm değişikliklerin bunlardan geçmesi gerekiyor. Bu, değişikliklerin çarpışmasını ve birbirlerine zarar vermesini önlemek için oldukça iyi çalıştı.

SQL Kaynak Kontrolü'ne baktınız mı? SQL Server'ınızı TFS / SVN / Vault veya VSS'ye bağlamak için kullanabilirsiniz - http://www.red-gate.com/products/sql-development/sql-source-control/

Başka bir çözüm, veritabanınızdaki değişiklikleri tasarlamak ve yönetmek için PowerDesigner, ERWin gibi bir şey kullanmaktır.

PowerDesigner'da veritabanlarının modellendiği bir politikaya geçmeye başlıyoruz. Veri tabanı yapısındaki / kodundaki tüm değişiklikler modelde yapılır, kaynak kontrolünde kontrol edilir ve daha sonra veri tabanındaki değişiklikleri uygulamak için modellerden değişiklik komut dosyaları oluşturulur. Bu değişiklik komut dosyaları kaynak kontrolünde de kontrol edilir. Büyük değişiklikler eş gözden geçirilir ve PowerDesigner bunu yerleşik özellikleri kullanarak çok kolaylaştırır.

PowerDesigner, veritabanlarından daha fazlasını destekleyen genel bir modelleme aracıdır, bu nedenle gereksinimleri yönetmek, kavramsal, fiziksel ve mimari diyagramlar (OOM de) vb. Oluşturmak için kullanmaya başlıyoruz. yazılım mühendisliği süreci.

(PowerDesigner'ı geliştiren Sybase'e bağlı değilim - sadece oraya fırlatacağımı düşündüm).

DB Hayalet

DB Ghost , veritabanlarını yönetmek için en sevdiğim araçtır.

Yararları

1. Veritabanınızdaki tüm nesneler kaynak kontrolünde script olarak saklanır.
2. Sen de 'statik veri' (arama tablosu verisi) yazabilirsin.
3. Kaynak kontrolünü manuel olarak veya bir 'model' geliştirme veritabanı yazarak güncelleyebilirsiniz.
4. Sen edebilirsiniz inşa (statik veriler dahil) kaynak denetiminde komut bir veritabanı (hızlı).
5. Tüm üretim örnekleri de dahil olmak üzere veritabanındaki örneklere değişiklikleri dağıtabilirsiniz :
   • 'Derleme veritabanını' (komut dosyalarından oluşturulmuş) varolan bir veri tabanı ile karşılaştırabilir ve bir değişiklik komut dosyası oluşturabilirsiniz.
   • DB Ghost'yu, veritabanının iki örneği arasındaki (ör. Bir inşa veritabanı ve üretim veritabanınız) değişiklikleri otomatik olarak senkronize etmek üzere yönlendirebilirsiniz.

[4], yerel değişiklikler yapmak veya farklı ortamlar için ayrı örnekler oluşturmak için özellikle kullanışlıdır. Aslında o kadar kolaydır ki üzerinde çalıştığım her özellik veya hata için ayrı bir veritabanı oluşturuyorum, bu da veritabanını etkiliyor.

ayrıntılar

Açık değişiklik veya geçiş komut dosyalarının sürdürülmesinde kullanılmasının temel avantajı, çoğunlukla açık değişiklik veya geçiş komut dosyalarının bakımını yapmanıza gerek kalmamasıdır - çoğunlukla veritabanınızın yalnızca 'güncel sürümünü' tutabilirsiniz. Geçiş komut dosyalarını yönetmenin can sıkıcı bir yönü, örneğin bir tablodaki sütunların listesini (geçiş komut dosyalarına göre) görmenin kolay bir yoludur. Elbette bazı değişikliklerin açık göçler olarak yapılması gerekir, ancak ayrı komut dosyaları olarak işlenebilecek kadar kolaydırlar.

Veritabanlarını (bir dizi) komut dosyası olarak yönetebilmenin ve hızlı bir şekilde yeni örnekler oluşturabilmenin özellikle güzel bir sonucu, önemli veritabanı kodlarını test etmenin çok kolay (ve oldukça eğlenceli) olmasıdır. Birim testi için tSQLt kullanıyorum .

Keşke diğer DBMS'ler için de benzer bir araç olsaydı.

DBA’ların çoğu için aşırı kulağa geldiğini biliyorum:

Veritabanı değişikliklerini (ve yalnızca DB değişikliklerini) izlemek için Ruby on Rails'i kullanmayı düşündünüz mü? Herhangi bir uygulamayı çalıştırmanız veya yakut kodu yazmanız gerekmez. Ancak, göç stilini (bu şekilde adlandırdıkları gibi) oldukça yararlı buldum: http://guides.rubyonrails.org/migrations.html

SQL Server da desteklenmektedir, ancak JRuby + JDBC kullanmanız gerekebilir.