Sürekli değişen veritabanı boyutlarını nasıl ele alırsınız?

9

Son iki aydır veri tabanlarında sürüm yönetimini ele alacak çözümler veya uygulamalar arıyordum. İnsanların bunu ele almak için en iyi süreç olarak gördüklerini arıyorum.

Veritabanlarımız için 3 ortamımız var:

gelişme
Kullanıcı Kabul Testi (UAT)
Üretim

Sorun bazen geliştirme veritabanımızdaki bazı şeylerde değişiklik yapıyoruz ve dağıtılma zamanı geliyor, bazı özellikler UAT'a yayınlanmaya hazır olmayabilir.

Son zamanlarda tüm varlıklarımızı (düzenli taahhütlerle) depolamak için Red Gate SQL Source kontrolünü kullanmaya başladık.

Değişiklik kümelerinden yola çıkmayı düşünüyordum (yani, her şeyden önce değişiklik kümesi X ve geri şimdi UAT'a itiliyor), ancak bu, insanların kafa karıştırıcı olabilecek bir konuşlandırma yapmadan önce sadece kodlarını kaynak kontrolüne kontrol ettikleri anlamına geliyor. özellikle insanlar unutkan olduğu için). Değişiklik kümesi yaklaşımı ile ilgili bir başka sorun, saklanan yordamda düzeltilmesi gereken bir hata varsa, değişiklik kümesi sayısının revizyon için maksimum değişiklik kümemizin kapsamı dışında kalmasıdır, böylece bunu yapmamız gerekiyorsa veritabanını maksimum bir değişiklik kümesinden yeniden oluşturursak, hatayı tekrar dışarı çıkarırdık.

Süreç hakkında herhangi bir öneriniz var mı?

Teşekkürler

— judda
kaynak

Veritabanı komut dosyalarınızın "gerçek" kodunuzla aynı kaynak denetiminde olmadığı anlaşılıyor. Bu neden? "Kaynak kodu" olarak ele alıp tek tek dallara koyabilir misiniz?

— Mike M.

Şu anda betiklerin geliştirme sürümünü sadece kaynak kontrolünde saklıyoruz ve UAT / Production her ikisi de aktif geliştirme ile senkronize değil. Kaynak kontrolündeki komut dosyalarının her biri, bir geliştirici her taahhütte bulunduğunda güncellenir. Bireysel şubelerle ilgili sorun, herkesin kullandığı 1 merkezi veritabanımızın olması (daha büyük değişiklikler için ayrı veritabanlarını kollara ayırıyoruz).

1

Sürüm için bir şube oluşturabilir ve yalnızca bu sürümle ilgili değişiklikler yapabilirsiniz. Diğer tüm değişiklikler bagajda yapılmalıdır. Bunu başarmak için iki geliştirme veritabanına ihtiyacınız olacaktır. Bu bir sorun olur mu?

Bu, muhtemelen oldukça hızlı bir şekilde güncelliğini yitirmesi gibi görünüyor. Hayır? Projelerimden biri için veritabanının büyük bir revizyonunun ortasındayız, bu yüzden veritabanını değiştirilmemiş versiyonunda aktif gelişimin devam edebilmesi için bir tane yaptık. Bununla birlikte, her gün dallı versiyonumuzun daha da eski hale geldiğini görüyorum ki bu iyi olup olmadığından emin değilim ... Daha önce böyle durumlarla hiç uğraşmak zorunda kalmadım.

— judda

5

Taşıma İşlemleri

Reponuzda bulunan ve uygulamanızla birlikte etiketlenen bir yukarı ve aşağı.

Şemanızı değiştiren ve şema sürümünü güncelleyen sql flatfiles ile DIY bile yapabilirsiniz. Gerçekten tek yapmanız gereken:

taşıma işlemlerinizi kaynak kodun yanında tutun, bunlar birlikte biçimlendirilmeli ve etiketlenmelidir
tüm ortamlarda her zaman yönetilen değişiklikleri (taşıma) kullanın
hiçbir ortamda geçici değişikliklere asla izin verme

Peki dev geliştirme değişiklikleri yapabilirsiniz, ama her zaman db havaya uçurmak ve değişikliği yakaladıktan sonra göç ile yeniden inşa gerekir.

— dietbuddha
kaynak

Komut dosyalarında bir hata bulunursa ne olur? Sql betiğine geri dönüp güncellenir misiniz?

— judda

1

Hayır, yeni bir geçiş oluşturursunuz (bu, şema sürümünü artırır). Veritabanındaki şema sürümüne bakarak, düzeltmenin dağıtıldığını bu şekilde bilirsiniz.

— dietbuddha

Yardımın için teşekkürler. İlk bakışta bu çok sağlam bir yaklaşım ve dallanma stratejimize benzer.

— judda

2

Kaynak kontrolü!

Geliştirme ikili dosyalarınızı svn / git / p4 aracılığıyla doğrudan üretime dağıtmıyorsunuz, neden veritabanlarınız bunu tek başına yapsın ki? Geliştiricilerin yerel değişikliklerini test etmeleri için özel örnekler alın, ancak geliştirme db'sine gitmesi gerektiğinde, kontrol edilen ddl dosyaları üzerinden gitmesi gerekir. Hatta bu ddl değişikliklerini otomatik olarak uygulamak için araçlar yazabilirsiniz (bunu doğru yapmak için mevcut bir yol bilmiyorum).

Bir kez yerinde db şema değişiklikleri etrafında kısıtlamalar var (Artık sqlplus -> sorun ddl!) Ve sıkı hesap kontrolü (herkes için ddl erişim yok) var, bu daha yönetilebilir hale gelmelidir.

— Subu Sankara Subramanian
kaynak

1

Ne yazık ki veritabanlarımız özel oturumları çalıştırmak için geliştiriciler arasında iletilemeyecek kadar büyük. Bunun yanı sıra, daha fazla takım temelli gelişime yatkın görünmüyor, çünkü şu an itibariyle, ikisini birbirine bağlayan UI çalışması için insanlarla konuşurken gelişimi sonlandırıyorum. Tüm değişiklikleri kontrol ederek ve daha sonra oldukça büyük bir güçlük gibi görünüyor veritabanında en son almak için başlamak gerekir.

— judda

Neden geliştirme db üretim db ile aynı boyutta olması gerekir? Aynı şemaya sahip olabilirler ve hatta tüm verilerle özel bir yük testi filosuna sahip olabilirsiniz, ancak yerel geliştirici veritabanları küçük olabilir. Bu aynı zamanda veri sızıntısıyla ilgili endişeleri de önler.

— Subu Sankara Subramanian

Tüm verilerimiz, istemciden bize sağlanan dosyaları işleyen ve daha sonra ihtiyaç duyduğumuz verilere dönüştüren veri yükleme sürecimiz yoluyla yüklenir. Bu nedenle, tüm veri yüklerinin yine de geliştirme aşamasında doğrulanması gerektiği için geliştirici ve ürün verilerini ayırmamız imkansızdır. Aynı boyutta olması gerekmiyor, ancak oluşturduğumuz raporların anlamlı bilgiler üretebilmesi için karşılaştırılabilir miktarda veriye ihtiyacı var.

— judda

Tüm DB'nin çoğaltılması gerekmez. Oracle'da her kullanıcının kendi şeması vardır ve bir uygulama şemamız vardır. Uygulama şemasındaki tüm nesneler için genel eş anlamlılar oluşturun. Daha sonra her kullanıcı kendi şemalarındaki nesneleri (tablolar, SP'ler) değiştirebilir ve kendileri gibi bağlanırlarsa nesne adları kullanılır. Şemada olmayan nesneler için eş anlamlılar kullanılır. Biz böyle çalışıyoruz.

— softveda

0

Taşıma kullanma önerisini takiben ... belki Ruby on Rails ve Entity Framework 4.3 gibi Taşımaları destekleyen bir O / RM kullanın. Değişiklik kümeleri açısından hangi Taşımaların uygulanacağını (genellikle) seçemezsiniz.

Başka bir geçerli seçenek (microsoft yığınındaysanız, platformdan hiç bahsetmediniz), SQL'inizi Visual Studio Veritabanı araçlarıyla yönetmektir. Yeniden düzenleme (sütunları yeniden adlandırma / kaldırma, vb.) Ve model doğrulaması yapar. Örneğin, saklanan bir proc artık orada olmayan bir sütuna başvuruyorsa sizi bilgilendirir.

— Michael Brown
kaynak