Siteleri hazırlama, DB'deki senkronizasyon güncellemelerini nasıl yönetirsiniz?

Geliştiricilerin güncellemeleri canlı sunucuya bırakmadan önce bir hazırlama sitesi üzerinden test etmeleri genel olarak kabul edilir, ancak geliştirme güncellemeleri Wordpress DB'de değişiklikler gerektirdiğinde, canlı sitedeki kullanıcılar DB'yi de güncelleyeceğinden işler karmaşıklaşır.

Hayal edebileceğim tek (karışık) akış şudur:

1. Yerel sunucuda test (WAMP, XAMP, vb.)
2. Dağıtmaya hazır olduğunuzda, canlı siteyi bakım moduna geçirin
3. Canlı siteyi yedekle (Teksir, sqldump vb.)
4. Hazırlama sitesine kilitli bir canlı sitenin klonu oluşturma
5. Değişiklikleri yerel ortamdan hazırlama sitesine yükleyin
6. Hazırlama bölgesini test edin
7. Yaşamak için hazırlama sitesini itin.
8. Bakım modunu kaldır

Yukarıdaki akışın dezavantajları:

• geliştirici hazırlama sitesindeki güncellemeleri dikkatlice test ederken kesinti süreleri kullanıcılar için beklenenden daha uzun olabilir;
• değişikliklerin manuel olarak yönetilmesini gerektirebilir: örneğin, siteorigin sayfa oluşturucu düzenleri db'de saklanır, bu nedenle bir düzen değiştirildikten sonra, hazırlama alanına elle içe aktarılması gerekir; bu durumda, sayfaları hazırlama sitesine bırakıp içe aktarmak ve çalışıyorsa, canlı siteye aktarmak yeterli olabilir

Bunu başarmanın daha iyi ve daha otomatik bir yolu var mı acaba?

Ne düşünüyorsun?

EDIT, istendiği gibi, geçmişte bazı çözümler önerilmiştir, ancak hiçbiri kesin bir çözüm sunmamaktadır:

• 9/2010 - Geliştirme / aşamalandırma ve üretim arasında veritabanı senkronizasyonu
• 12/2011 - wp_options Tablosunu Değiştiren Güncellenmiş veya Yeni Eklentileri Dağıtma
• 9/2014 - Yeni yayınları / sayfaları geçersiz kılmadan yerel değişiklikleri canlı bir sunucuya nasıl yükleyebilirim?
• 1/2015 - Wordpress site bloglarını üretim ve sahnelemede nasıl koruyabilirim?

Özellikle WordPress'e hitap eden daha yeni barındırma sağlayıcıları genellikle bu acıyı hafifletmek için araçlara sahiptir. Müşterilerimi sadece kod yukarı hareket (geliştirmeden aşamalı üretime) ve DB şeyler sadece aşağı doğru (kod tersi) bu temiz Git özellikli iş akışı olan Pantheon koymak . Bir veritabanını üretimden sahnelemeye kopyalamak, arabirimleriyle tek bir tıklamadır. Bu iş akışına uyulması şartıyla, bu, üretim veritabanını bozma konusunu hemen hemen ortadan kaldırarak, her iki geliştirme DB aşamasında taze bir üretim DB verisi klonundaki değişiklikleri her zaman test etmemi sağladı.

Pantheon'u kullanmak zorunda değilsiniz - kendi araçlarınızı kullanarak (Git + WP Migrate DB gibi bir DB klonlama eklentisi) benzer bir yaklaşımı benimseyebilirsiniz. Sadece bu yolun benim için iyi çalıştığını görüyorum.

Soru: Evrelemeyi test ederken üretim sitenizi neden bakım moduna soktunuz? Çoğu durumda buna ihtiyaç olmamalıdır. Düşünebileceğim tek durum, önyükleme yapmak için felaketli bir hata ile beslenen ek kullanıcı verilerine karşı oldukça hassas bir çeşit kırılgan sisteme sahip olmaktır - ancak bu muhtemelen birinin ihtiyaç duyacağı farklı, daha büyük bir sorunun göstergesi olabilir. tüm mimarisini yeniden düşünmek.

GIT versiyonlamasını tüm sürece (dosya ve veritabanı) getiren VersionPress'e bir göz atın

Sitelerinde açıklandığı gibi:

VersionPress ağrısız evreleme sağlar . Bu, değişiklikleriniz için kolayca güvenli bir test ortamı oluşturabileceğiniz ve yalnızca hazır olduklarında bunları birleştirebileceğiniz anlamına gelir. Birleştirme burada anahtar kelimedir - VersionPress, canlı sitenizin yeni içeriğe sahip olduğu durumları sorunsuz bir şekilde ele alır.