Yeni içerik kaybetmeden sitenin geliştirme kopyasından canlı siteye değişiklikleri nasıl birleştiririm?

40

Bir sitenin geliştirme kopyasında yapılan çalışmaları canlı üretim kopyasına birleştirmek için en iyi yöntem nedir? Çoğu zaman, geliştirme en yeni özelliklerle başladığından beri siteye birçok içerik eklenmiştir. Bir siteye yapılan çoğu ekleme, veritabanı değişikliklerini içerecektir. Yani herhangi bir yeni dosyayı kopyalamak kolaydır, fakat veritabanına ne dersiniz? Üretim sitesini en son güncellediğinizden bu yana eklenen yeni içeriği kaybetmeden değişikliklerinizi mevcut üretim veritabanıyla nasıl birleştirirsiniz? Bu konuda yardımcı olabilecek herhangi bir modül var mı?

database updating

— Chaulky
kaynak

2

Karışıklığı giderin: Birleştirme ve geçiş iki farklı kelimedir. Sorunuzda her ikisini de kullandınız. Canlı site boşsa, geliştirme kopyasını canlı siteye / ana bilgisayara taşımalısınız. Canlı site zaten içeriğe sahipse, geliştirme içeriğinden canlı siteye kadar yeni içerikleri birleştirmeniz gerekir (Birleştirme biraz zordur). Ne yapman gerek?

— kullanıcı931,

16

İçerik sitesindeki içerik türlerinde, görünümlerde ve yapı değişikliklerinde veritabanını koda aktarmak için Özellikler'i kullanma bölümüne bakın .

İçerik geçişi için birçok seçenek var, ancak tek bir katı çözüm yok. Bir örnek Dağıtım paketidir .

— budda
kaynak

Demployment suite, hala Dev'te olmasına rağmen kesinlikle ilginç görünüyor (henüz bir Beta bile değil). Kendin mi kullandın? Örtmeyeceği bir şey biliyor musun?

— Chaulky

2

Burada temel olarak iki düşünce okulu kabul ettim (3. düşünce okulu, veri tabanı farklılaşması, tartışmayacağım çünkü karmaşıklık oldukça yüksek).

1) Üretim veritabanını bırakarak ve geliştirme veritabanının mysqldump dosyasını alarak dağıtın. İsteğe bağlı olarak, SQL dökümü içindeki dev URL'ye başvuran sabit kodlanmış mutlak bağlantılarda önceden bir bul / değiştir komutunu çalıştırın. Dev db'yi prod'a içe aktardıktan sonra, prod için dev'den farklı olan ayarları değiştirmek için SQL deyimlerini (genellikle komut dosyasıyla) otomatik olarak çalıştırın (örneğin, belki de değişkenler tablosunda ihtiyacınız olan harici sistemlere bağlanmak için bazı bağlantı ayarları vardır). dev versiyon yerine prod harici sistemlere işaret eder).

2) Yönetici ayarları için budda tarafından belirtildiği gibi Özellikler modülünü kullanın ve Tümünü Sil modülü ile birlikte içerik dışa aktarma / içe aktarma için Düğüm Dışa Aktarma modülünü kullanın . Yani iş akışı:

düğümleri / özellikleri dosyalara vermek için düğüm_export ve özelliklerini kullanın
İsteğe bağlı (ve umarım) sürüm kontrolü
Prod sistemine dosya yükle
Özellikleri yüklemek için sarhoş veya yönetici arayüzünü kullanın
Almak istediğiniz türlerin tüm düğümlerini silmek için drush delete-all veya admin arayüzünü kullanın.
Dışa aktardığınız düğümler dosyasındaki düğümleri almak için drush ne-import veya admin arayüzünü kullanın.

Bir not, içeriğin sadece bir yöne gittiği standart bir iş akışını benimsemeyi şiddetle tavsiye ederim. Dev -> Prod veya Prod -> Dev (Bunu tercih ederim).

Bunu yaptım ve bunu bazı büyük sistemlerde, oldukça iyi sonuçlarla yapıyorum, ancak bu elmayı dilimlemek, sizin için en uygun olanı seçmek için her zaman birçok yol bulunacaktır.

— coderintherye
kaynak

Seçenek 1'de, geliştirici sitesinde olmayan canlı siteye eklenen içeriği nasıl yeniden yaratıyorsunuz? Dev db ile hepsini üzerine yazıyorsunuz ve belki bazı ayarları / değişkenleri değiştiriyorsunuz. Ayrıca, şu anda sitelerinizde hangi düşünce okulu kullanıyorsunuz? Her bir yaklaşımın lehte ve aleyhte olanı

— Chaulky

Seçenek 1'de, düzenli olarak içeriği (önceki içeriği kaldırmış halde) göndermek için node_export kullanıyoruz. Hem dev hem de prod üzerinde içerik değişiklikleri yapıyorduk. Bu, aslında ideal olmasa da, birkaç yerde gördüğüm ortak bir senaryo. Bu yüzden eklerim, bir yönelirim ve ona bağlı kalırım, ya içerik dev -> prod veya prod -> dev olur, ancak ikisini de yapmamaya çalışın. Ve evet, temelde üzerine yazarız, yine de daha çok silmek ve yeniden yapmak gibi. Yeni işimde # 2 yapıyoruz, eski işimde # 1 yaptık ama # 2'ye geçiyoruz (hala onlara danışmanlık yapıyorum).

— coderintherye

1

SQL dosyasında sitenin canlı site kopyası ve geliştirme kopyasının döküm veritabanları (her iki döküm için de aynı parametreleri ve ayarları kullanın).
Ardından, her iki SQL dosyasını ExamDiff küçük bir karşılaştırma aracı kullanarak karşılaştırın . Dosya farklarını yan yana farklı renklerle görüntüler. Ayrıca doğrudan farklılıklara atlayabilirsiniz (kaydırma yapmadan). Farklılıkları inceleyin ve canlı sitenin SQL dosyasına satır ekleme / düzenleme. Bu dosyada geliştirme ortamı için mutlak bir yol / URL olmadığından emin olun. Bitti! Canlı site için veritabanını geri yükleme zamanı.
Hayatınızı kolaylaştırın:İlk adımda, yalnızca değiştirilmiş olan tabloları at. Örneğin, geliştirme kopyasında ayrı bir tabloyu hedefleyen bir modül düzenlediyseniz, yalnızca bu tabloyu boşaltın. Belirli bir tablo hakkında emin değilseniz, tüm veritabanı dökümü iyidir.

— user931
kaynak

Bu tekniğin bazı önemli durumlarda ciddi kısıtlamaları vardır. Örneğin, geliştirme sitesi yeni düğümlere sahipse, iki veritabanınız aynı düğüm kimliğine sahip girişleri içerecektir ve referansları çözmek ve bunları sql veritabanının bir metin dökümü ile birleştirmek mümkün olmayacaktır. Bu tür işlemler, diğer yanıtlarda belirtildiği gibi özellikler ve dağıtım yoluyla daha iyi ele alınmaktadır.

— greg_1_anderson