Küçük web ekibi için yerel veritabanı geliştirme süreci nasıl kurulur?


14

Arka fon

Gelecekte takımı büyütme potansiyeli ile yaklaşık 4 programcı ve 4 tasarımcıdan oluşan küçük bir web ekibi için yeni bir geliştirme süreci oluşturmaya çalışıyorum. Ürünümüz, tasarladığımız ve barındırdığımız müşteri web sitelerine güç veren merkezi bir uygulamadır.

Daha önce, hepimiz tek bir dev veritabanı ile bir dev sunucusunda FTP üzerinden çalışıyorduk. Bir süre "çalıştı" * , ancak yeni bir yöne doğru ilerliyoruz, bu yüzden sürecimizi olgunlaştırmanın zamanı geldi.

Percona Server 5.5 kullanıyoruz, ancak maliyeti düşük tutma fikri ile bu veritabanı agnostik olmalıdır.

Hedefler :

Aşağıdaki düşünülerek veritabanı geliştirme için sürekli bir entegrasyon (CI) süreci oluşturmak için arıyorum:

  1. Geliştiriciler, geliştirme kodunu çalıştırmak için verilerin yerel kopyasına sahiptir.
  2. Veritabanı yapısını önceki bir değişiklik kümesine geri alabilir
  3. Şema tasarım düzeltme değişikliklerine karşı yeni özellik şema değişikliklerini ayırabilir
  4. Test için veritabanı yapısını yerel olarak değiştirebilme

İlk Konsept

Tamamen kaldırsa da, SVN ve LiquiBase kullanarak aşağıda bir işlem çizdi #4.

  • bagajdan bir 'geliştirme' dalı oluştur
  • merkezi 'geliştirme' db sunucusu 'geliştirme' dalında çalışır
  • yerel geliştiriciler kalkınma şubesine köle olarak kurulur ( #1yukarıda belirtilmiştir)
  • likibaz değişiklik setleri, merkezi geliştirme veritabanını güncellemek için bir taahhüt sonrası kanca yürüten geliştirme şubesine düzenli olarak taahhüt edilir (bu geliştirme sunucusuna köle olarak çalışan yerel makinelere damlar) (liquibase #2yukarıda sağlar)
  • özellikler veya şema düzeltmeleri KG'ye geçmeye hazır olduğunda, DBA (ben) geliştirme dalından bagajdaki uygun değişiklikleri birleştirir. Bu işlem, hazırlama veritabanı sunucusuna uygulanacak bir sql betiği oluşturur.
  • Hazırlama sunucusu, Üretim ile aynı yapıya sahip olması gereken TRUNK'u ve KG'deki değişiklikleri yansıtmalıdır
  • hazırlama sunucusunda sql komut dosyasını yürüttükten sonra, değişikliklerde bazı KG yapın.
  • Her şey iyi görünüyorsa, yapıyı TAG. Bu, üretimde DBA tarafından manuel olarak çalıştırılacak .sql betiğini oluşturur (gerekirse yoğun olmayan saatler için)

Bu işlem, tüm geliştiricilerin aynı 'geliştirme' dalını çalıştırmasını gerektirir, yani herhangi bir zamanda veritabanı şemasının yalnızca bir sürümü vardır (bunu istediğimden emin değilim).

Ayrıca şemada yapılan herhangi bir değişikliğin yerel olarak test edilemeyeceği ve doğru yapılmazsa diğer geliştiricileri etkileyebileceği anlamına gelir. Çevremizde, geliştiriciler yeni tablolar ekleyebilir ancak mevcut yapıyı nadiren değiştirebilir. DBA olarak tasarım düzeltmeleri tarafımdan yapılır. Ancak, düzeltmeleri yerel olarak test edememe, sürecin en büyük sorunum.

Verilerin nispeten güncel bir kopyasını korurken (önerilen işlemimde çoğaltma ile sağlandığı gibi) yukarıdaki süreç yerel gelişmeye izin vermek için nasıl değiştirilebilir? Verilerin geçen haftaya kadar güncel olmasını gerektirmiyorum.


* 'Çalıştı' derken, yeterdi ama bir PITA idi.

Yanıtlar:


12

Ortamları yönetme

Bence kesinlikle tek bir veritabanı sürümüne zorlanmak istemiyorsunuz. Kaçınılmaz olarak birden fazla geliştirme iş akışına sahip olacak yeterli geliştiriciniz ve geliştirme iş akışlarından bağımsız olarak mevcut üretim ortamına düzeltme ekleri uygulama gereksinimleri var.

Sürümleri yükseltmek için yama komut dosyaları oluşturmak için Liquibase veya manuel bir işlem kullanabilirsiniz. Manuel bir işlemle başlamanızı ve yamalarda KG için şema karşılaştırma aracını kullanmanızı öneririm. Son derece karmaşık olmayan bir veritabanının temiz, otomatik, şeffaf senkronizasyonu biraz ütopiktir.

Merkezi veri modeliniz, süslemenizi her hangi bir sistemde tutabilir. Sıkıcı kurumsal depo araçlarından her şeyi tablo komut dosyaları oluşturmak için kullandım. Subversion gibi sıradan kaynak kontrol araçlarıyla güzelce oynatılan tablo komut dosyaları oluşturun ve tüm depo araçları iyi bir sürüm oluşturma işi yapmaz.

Ana veri modeli deponuz olarak ne kullanırsanız kullanın, bu modelden bir ortam dağıtmak için oldukça temiz bir mekanizmaya ihtiyacınız vardır. Bir ortama kolayca dağıtılacak şekilde yapılandırılmalıdır. Ayrıca, yayınlanan bir sürümden diğerine yama yapmak için bir mekanizmaya ihtiyacınız vardır.

Ne yaptım

Geliştirme ortamlarını yönetirken geçmişte aşağıdakileri yaptım. Özellikle yüksek teknoloji değil, ancak sürüm kontrolü ve otomatik yapılara uygundur, bu nedenle bir ortamı belirli bir sürüme yaymayı kolaylaştırır ve çok sayıda ortamı maitasyon oldukça pratiktir.

Merkezi bir havuzu koruyun: Bu, bir sürüm kontrol sistemlerinde tutulan bir veritabanı oluşturma komut dosyaları kümesi veya bir veri modelleme aracında bir havuz modeli olabilir. İstediğini al. Bu model, çok fazla manuel müdahale olmadan bir ortamın komut dosyalarından çıkarılmasına izin veren bir oluşturma mekanizmasına sahip olmalıdır.

Çok sayıda referans veriniz varsa, bunun için bir yük mekanizmasına ihtiyacınız olacaktır. Nasıl yapmak istediğinize bağlı olarak, bunu bir veritabanında veya bir dosya kümesinde tutabilirsiniz. Dosyaların avantajı, kod tabanınızla aynı sürüm kontrol sisteminden de versiyonlanıp etiketlenebilmeleridir. Bir kaynak kontrol havuzundaki bir grup CSV dosyası ve toplu yükleyici komut dosyaları bunu kolayca yapabilir.

Geliştirme ortamlarını dağıtmak için bir seçenek, üretim veritabanının yedeklerini uygun sürüme yamalamak ve geliştiricilerin bir geliştirme ortamına geri yüklemelerini sağlamaktır.

Devreye almayı kolaylaştırın: Herhangi bir CI derleme işlemi gibi, veritabanı tek bir komut dosyasından konuşlandırılabilir olmalıdır. Veritabanı bağlantılarının parametreleştirilmesi veya komut dosyasının konumdan bağımsız olması ve yalnızca bağlantı üzerinden çalıştırılabilmesi için ayarlayın.

Düzeltme eki komut dosyaları: Yayımlanan her sürümden komut ileri ve muhtemelen geri almanız gerekir.

Havuz modelinden test ortamları oluşturun: Bu, havuzla senkronize olmayan ortamlarda geliştirmenin testte yakalanmasını sağlar.

Dağıtım işlemini sınayın: Otomatik düzeltme eki komut dosyaları oluşturulur, ancak bunlar oluşturulabilir olmalıdır. Yama komut dosyalarını oluşturmak için kullanmasanız bile, şema karşılaştırma araçları bunun için oldukça iyidir.

  • Test ettiğiniz depo modeli derlemesiyle bir referans ortamı oluşturun

  • Üretim sürümünüzün bir yedeğiyle veya geçerli sürümüne dayalı bir derlemeyle bir duman testi ortamı oluşturun.

  • Düzeltme eki komut dosyasını duman testi ortamına karşı çalıştırın.

  • Duman testi ortamını referans ortamıyla karşılaştırmak için şema karşılaştırma aracını kullanın. Düzeltme eki komut dosyası, iki veritabanının aynı olmasına neden olmalıdır, böylece farklılıkları araştırabilirsiniz.

Bu süreçle ilgili sevdiğim şey

Bu biraz ağırdır ve oldukça bürokratik ve opak üretim ortamlarına yerleştirilmek üzere tasarlanmıştır. Bununla birlikte, aşağıdaki güçlü yönlere sahiptir:

  • Geliştiriciler ihtiyaç duydukları yerde tamir edebilirler.

  • Birden fazla dal ve gelişme akışı barındırabilir.

  • Dağıtım komut dosyalarının kendileri tekrarlanabilir bir şekilde test edilebilir. Bu, tekrarlanabilirlik kanıtlanabileceğinden, dağıtım sorunlarının giderilmesinde çok yararlıdır.

  • Şema karşılaştırma araçları, dağıtımın kendisi için KG sağlar.

  • Testler her zaman piyasaya sürülmesi beklenen şeylere karşı yapılır ve bu, senkronize olmayan ortamlardan kaynaklanan sorunları yakalar.

  • Havuz modellerine ve yama komut dosyalarına dayalı dağıtım, kontrolsüz çöpün yanlışlıkla geliştirme ortamlarından üretime geçmediği anlamına gelir.

  • Çoğu zaman uygulama otomatikleştirilebilir, ancak dağıtım düzeltme eki komut dosyalarını el ile hazırlamak ve sınamak genellikle istenir.

  • Ortamlar, kasnaklardan atlamak zorunda kalmadan ucuz ve kolay yerleştirilebilir.

  • Geliştiriciler, basit bir oluşturma ve dağıtım işlemine uygun bir sistem yapmaya zorlanıyor.

  • Geliştiriciler temel veritabanı yönetimi görevlerini öğrenmeye zorlanır, ancak test ve üretim ortamları noob hatalarından yalıtılır.

İhtiyaçlarınızı nasıl karşılar?

  1. Geliştiriciler, geliştirme kodunu karşı çalıştırmak için verilerin yerel bir kopyasına sahiptir

    . Dağıtım komut dosyaları veya DB görüntüleri, kullanılabilir herhangi bir sürümden bir ortam oluşturabilecekleri anlamına gelir.

  2. Veritabanı yapısını

    , dağıtım komut dosyalarına göre sıralanmış olarak önceki bir değişiklik kümesine geri alabilir . Geliştiriciler DDL veya denetimli bir işlemle oluşturulan veritabanı yedekleme görüntüleri aracılığıyla geliştiriciler sahip olduğunuz belirli bir sürüme bir ortam getirebilir.

  3. Yeni özellik şema değişikliklerini şema tasarım düzeltme değişikliklerine göre

    ayırabilme Ortak bir sürüme yönelik yamalar svn ağacında ayrı bir çatalla korunabilir. Veritabanı yedekleri referans ortamları olarak kullanılıyorsa, kaynak kontrol projelerinin dallanmasıyla aynı klasör yapısına sahip bir yerde saklanması gerekir.

  4. Test için veritabanı yapısını yerel olarak değiştirebilme

    Basit dağıtım işlemi geliştiricilerin bir ortamı yerel bir duruma geri yüklemesini ve kolayca geri yüklemesini veya karşılaştırma yapmak ve değişiklik kümeleri yapmak için bir referans ortamı oluşturmasını sağlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.