WP veritabanını git kullanarak birden fazla geliştirici arasında senkronize etmek

Git iş akışımı iyileştirmeye, WordPress geliştirme projelerime uygulandığı için çalışıyorum. Genellikle, bir içerik yönetim sistemi geliştirirken http://dev.finalsitename.com, üretim sürümünde kullanılacak özel posta tiplerini ve taksonomilerini içeren bir geliştirme sunucusu (benzeri ) oluşturacağım . Bu, müşterimin içeriğini siteye eklemeye başlamasını sağlar.

Bu görev üzerinde çalıştıkları sırada, genellikle yerel ev ortamımda kullanılacak özel programlama / eklentilerin yanı sıra görünüm ve his de oluşturuyorum. Hiçbir güncellemesinin üzerine yazmadığımdan emin olmak için, genellikle veritabanlarının bir kopyasını alıp benimkini değiştiririm. Ancak, WP yönetici alanına girip bir ayarı veya küçük bir şeyi değiştirmem gereken zamanlar var ...

Bir WordPress projesi üzerinde çalışan birden fazla geliştirici varsa, her biri site sürümümüzün (zaman damgalı) bir veritabanı dökümü yaparız ve yerel şubelerini uzak havuza geri koymadan önce kök dizine ekleriz. Bu yaklaşımla ilgili sorun, veritabanlarının hangisinin kullanılacağını belirlemenin kolay bir yolu olmadan senkronize olmadıklarıdır.

Diğer geliştiricilerin aynı veritabanında birden fazla geliştiricinin (ve müşterilerin / içerik üreticilerinin) çalışmasına izin verirken, veritabanlarını senkronize etmek için ne işi var?

En kolay 3 seçenek var ->

1. Çok sayıda yedeklemeyle bağlandığınız yalnızca bir uzak veritabanı kullanın. Bu şekilde sadece dosyalar hakkında endişelenmeniz gerekir, db hakkında değil.

2. WordPress'te yerleşik olarak bulunan içe aktarma ve dışa aktarma işlevini kullanın ve bunu doğrudan wp kök dizinine (yeni bir klasörde olduğu gibi) sürüm kontrolünüze atın. Tabi ekstra birkaç dakika sürse de ölümü çok basit ve otomatik hale getirebilirsiniz, fakat daha da önemlisi versiyon kontrolünün bir parçası olacak.

3. Gerçek veritabanı senkronizasyonunu sürümlendirmek için özel bir güncelleme komut dosyası kullanın. Dürüst olmak gerekirse, git ile bunu nasıl başarabileceğinizi bilmiyorum çünkü bu sadece bir senaryo ve ne olduğunu gerçekten bilmiyor, bu reklamı ücretsiz yapan 3. parti araçlar olduğunu biliyorum ( http: // www. liquibase.org/ ).

Veritabanlarını tamamen senkronize tutmanız gerekirse, yani. şema ve verilerde, yedeklemeleri temel alan özel bir versiyonlama sistemi geliştirebilirsiniz.

Veya verileri üretimden korumak ancak şemasını geliştirmek istiyorsanız, özel bir çözümle (tüm şema değişiklikleriyle sürümlü bir dosya) veya konseptine dayanan standart bir çözümle çalışabilirsiniz migration. Bu stackoverflow iş parçacığında birçok bilgi bulabilirsiniz: db şema değişikliklerini izleme mekanizmaları .

Bu inanılmaz derecede açık görünüyorsa üzgünüm ama eğer aynı yapıda veri tabanının aynı kopyasına sahip olmanız gerekiyorsa, bir ofis / merkezi SQL sunucunuz olması ve bunu kullanmanın bir anlamı olmaz mı? Denemeye ihtiyaç duyuyorsanız ancak yetkili defacto standardı olarak saklayın ve bu sunucunun ve yalnızca bu sunucunun yedeklerini alın, yerel olarak klonlayın.

Aksi halde, bir grup projesi üzerinde çalışırken farklı içeriklere sahip kendi kurulumlarımız vardır. Kod, masa yapılarının yükseltilmesi ve taşınmasıyla ilgilenir ve makinelerimize LAN üzerinden çalışan kodun yerel kurulumlarına eacothers'a erişebiliriz, bu nedenle içerik paylaşmamıza gerek yoktur.

İçeriğe giriyorsak, onu canlı sunucuya dışa ve içe aktaracağımız bir test sunucusunda çalıştırırız veya şu anda canlı örnek yoksa, doğrudan üretim sunucusuna geçirebiliriz.

Herhangi bir noktada, canlı test ve WIP verilerinin ayrılmasına ihtiyacınız varsa, yalnızca havuzunuzda bir canlı, test ve geliştirme dalı kullanın