Geliştirme / aşamalandırma ve üretim arasında veritabanı senkronizasyonu


36

Geliştirme ve üretim arasında WordPress veritabanı senkronizasyonuyla ilgili bir sorunum var ve diğer insanların bunu nasıl çözdüklerini merak ediyorum. Bu sorunun farkındayım, ancak daha düzensiz ve daha gerçekçi kullanım durumlarını kapsamıyor.

Canlı bir WordPress web sitem var. Her şeyden kurtulup dev ortamımıza kopyaladım. Değişiklik yapmaya başladım. 1 hafta sonra güncellemelerimi dağıtmaya hazırım. Bu arada, üretim sitesindeki veritabanı değişti (yeni yazılar, yeni yorumlar vb.). Çıkış sırasında üretim ile geliştirme arasındaki değişiklikleri nasıl senkronize ederim ve bu işlemi otomatikleştirmek (en azından bir şekilde) mümkün mü?



Yanıtlar:


10

Kaybetmem daha iyi bir yol olabilir, ancak size 2 seçenek sunacağım:

1. Yeni yayınlarınızı ve yorumlarınızı dışa aktarmak için XML Dışa Aktar'ı kullanın. Ardından , yeni gönderileri ve yorumları tekrar dev veritabanına aktarmak için WordPress İçe Aktarıcı'yı kullanın.

Dev'e içe aktarmak ve veritabanını prodüksiyona taşımak en iyisidir çünkü içe aktardığınızda tüm yeni medya dosyalarını prodüksiyondan indirir.

Bu arada üretim değişti (yeni mesajlar, yeni yorumlar vb.)

Bu, herhangi bir değiştirilmiş içeriğin getirilmesi sorununuzu çözecektir.

2. Yeni tabloları dev'den eklemek için INSERT IGNORE INSO MySql komutunu kullanın. veya aynı tabloda yinelenen satırların üzerine yazmak için REPLACE komutunu kullanın.

MySql'i kullanmadan önce her iki veritabanını da yedekleyin ve gz veritabanını üretim sunucusuna taşıyın ve dökümü yükleyin (üretim ile aynıysa dev adını değiştirin.

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

MySQL komutları ile rahat değilim, bu yüzden seçenek 1 ile giderim.


XML dışa aktarma tezgahlarının bir miktar gönderinin durduğunu unutmayın; örneğin blogumda +10.000 gönderilerde kullanamıyorum.
edelwater

@ edelwater, evet bu max_execution_time için sunucu ayarlarına bağlıdır (genellikle 30 saniye), çok büyük ihracatlar için bu değerin daha yüksek (1-2 dakika veya daha fazla) ayarlanması gerekir
mike23

2

Tam olarak aynı veri türünden fazlasıysa (bazı yeni blog gönderileri, yeni yorumlar) Neden gerçekten senkronize etmeniz gerektiğinden emin değilim. Aynı şeyden daha fazlası olduğundan sitedeki kodun çalışma şeklini değiştirecek gibi değil. Yeni bir veri türü olmadığı sürece genellikle endişelenmiyorum.

Her zaman, sitenin verilerini iyi bir örneğe sahip olduğumdan emin değilim.


2
İyi bir nokta! Bununla birlikte, üretimin tamamen içerik alanında bazı değişiklikler varsa (gönderiler, yorumlar) ve dev, ayarlar ve kurulumda değişiklikler yaptıysa (örneğin 5 eklenti eklenmiş ve ayarlarını değiştirmişse), bu ayar değişikliklerini gerçekten iki kez yapmadan nasıl gerçekleştirirsiniz (bir dev zaman ve üretimde bir zaman)?
Alex

asıl soru bu değil mi ve bunun için bir cevabım yok.
curtismchale,

-1. Bazen onları senkronize etmemiz gerekir. Özellikle idveritabanından postalar / sayfalar için.
Francisco Corrales Morales,

2

Paralel olarak değişiklik yapma konusuna dokunursanız, yapılandırma yönetimi alanına dokunursunuz. Pek çok kalıpla, kendi toplulukları (http://www.cmcrossroads.com/) ve sürüm yönetimi (svn / git olarak) için değil, clearcase gibi yapılandırma yönetimi (kalıplar) desteği için araçlar çok fazladır. (tamamen farklı alanlar).

Bu durumda hala basit bir durum ve bazı sınırlamalar, bazı el işleri ve bazı listeler ile çalışmasını bulacaksınız.

İdeal çözümü daha açıklayıcı hale getirmeyi düşündüğüm senaryo: aynı kod tabanında çalışan birden çok geliştirici, birden çok test ortamı, birden çok kabul ortamı, muhtemelen dünyanın her köşesinde birden çok üretim kabul ortamı.

Bunu biraz daha profesyonel yapmak istersen:

a) Karşılaştığınız tüm Konfigürasyon Öğelerinin bir listesini yazın; bu, WordPress kodunun kendisi, harici eklentiler, içerik, meta veriler olabilir ve bunlardan hangisinin önemli olduğunu bir tür "yönetim" altına almak istediğinize karar verebilirsiniz.

b) meydana gelebilecek iş akışlarını tanımlayın; örneğin bir düzeltmeyle ne olur, yeni bir şey olduğunda gelişme ile ne olur, hangi durumda kendi tarafınızdaki içeriği değiştirirsiniz, ne denir, ne denir ve kim yapar? örneğin yeni bir yazı veya yeni bir eklenti.

c) Paralel çalışma için öncelikle hangi CI'leri yönetmek istediğinizi açıklayın, akışın daima geliştirmeden üretime mi yoksa gerçekten iki yolla mı yapılacağına karar verin.

d) (a) altındaki CI tiplerinin her biri için bir çözüm yazmak. Örneğin, metin olan TÜM (veya php dosyaları, ancak XML dosyalarında ALSO düz metinler gibi dışa aktarılan metinler) birleştirme mümkündür. Bu gerçekten sorun değil ama iyi bir birleştirme aracına ihtiyacınız var. örn. ClearCase ile 3 şekilde elde edersiniz, aşağıdaki durumları birleştirirsiniz: 1) önemsiz birleşimler: bunları otomatik olarak yapacak 2) önemsiz olmayan otomatik: bunu otomatik olarak yapacak, ancak kontrol etmelisiniz 3) önemsiz olmayan otomatik: Çatışma, örneğin 1 hatta birkaç değişiklik yapıldı. Önemsiz olmayanlar, el ile bakmanız gereken en az kısımdır, iyi bir birleştirme aracı, bu örnekte sizi açık alanda (örneğin bir birleştirme işlemi yapar ve belirli bir dosya için diğer ticari veya ticari olmayan birleşme birimlerine bağlayabileceğiniz) yönlendirir. tipleri). Dahası, (a) altında sadece kopyalanması gereken dosyalar belirlediyseniz, davranışları birleştirilmeyecek, ancak birleştirme olmadan diğer sürümün üzerine yazılacak şekilde kopyalanacak (örneğin, değiştirmemiş olduğunuz eklentiler). Bu türlerin çoğu farklı davranışlarla mümkündür. Fakat CI'ler arasındaki ilişkileri yazınız.

O zaman metin temelli olmayan birleştirmeler için, bunların nasıl kullanılacağına dair bir karar vermeniz gerekir, örneğin 2 yerde değiştirilmiş görüntüler. Burada üretimin her zaman tercih edildiğine (en azından benim düşündüğüm gibi) karar verebilirsiniz, ki bu onu basitleştirir.

Yani ... bu sorunu çözmek için farklı akışları destekleyen bir sürüm yönetim aracına ihtiyacınız var. Her akış bir parçayı temsil eder. (Bu ihtiyaçlarınızı bağlı olarak son derece karmaşık olabilir, ancak bu durumda çok basit olduğunu düşünüyorum).

Artık bu akışların WordPress kurulumları altında olmasını sağlayabiliyor ve bunları veritabanının içeriği ile de senkronize edebiliyorsanız ... o zaman birleştirme işlemini CM / versiyonlama aracında gerçekleştirebilir ve ardından diğer ortamlara geri aktarabilirsiniz.

Mesele şu ki ... önce bunu yazmalısın. Bu teknik bir kesmek değil. Yapılandırma Yönetimi etrafındaki varsayılan bir kalıptır, bu yüzden burada da garip olan hiçbir şey yoktur, ancak yazmanız gerekir. Örneğin, kurulu bir eklentinin başka bir ortamda farklı olan bazı verilerle veritabanında değişiklikler yaptığını öğrenebilirsiniz, bu yüzden bunun için fazladan bir işlem yapmanız gerekir.

Teknik olarak hemen hemen her zaman her şey mümkün. Her zaman aynı yaklaşımı ve aynı CM desenlerini kullanmakla birlikte onlarca ya da yüzlerce kez daha karmaşık olan senaryolar için http://www.cmcrossroads.com/forums adresini kontrol edin .

Kısacası: altında bir sürüm yönetim katmanı koymak, birleştirmek otomatikleştirmek ve çatışmaları işlemek, sonra hedef ortamda içe aktarın. Buraya uyan bir akış stratejisi düşün ve yaz. Ufacık bir weeny bit CM yönetimi gerçekleştirin. Aksi takdirde bazı db kopya kesmek, komut dosyaları vb yüklemek profesyonel bir çözüm olurdu ...


2

Üretim verilerini nasıl bizim aşamamıza senkronize ettiğime dair bir yazı yaptım, şu blog yazımı kontrol et: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database uçtan uca entegre üretim-için-evreleme-enviorment /

Kodu ve diğer şeyleri de senkronize etmek istiyorsanız, ilgili yoksayma dosyasıyla bir git veya ticari havuz oluşturmanızı tavsiye ederim.

Aşamalı prodüksiyon yapmak için farklı güncellemeler yapmak istiyorsanız, o zaman geçiş komut dosyaları oluşturmak en güvenli ve en iyi yoldur.

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.