WordPress Siteleri için Dev, Stage ve Prodüksiyon Dağıtımı?


41

Bu yüzden bir WordPress web sitesi için dev / stage / prodüksiyon iterasyonlarına (ayrı sunucularda) sahip olmam gerekiyor, genellikle git kullanırım ama bu açıkça ana veri tabanına bağlı olduğu için WordPress sitelerinde çalışmayacak. yapılandırması ... peki, hemen hemen her şey.

Peki benim sorum, siz nasıl yapıyorsunuz? Hızlı bir Google’a sahiptim ve birkaç eklenti olduğunu gördüm, tek yol bu mu? İş kolaylığı, hız, güvenilirlik, kullanıcı arabirimi vb. Açısından hangisi en iyi işi yapar?


pantheon.io , tek bir etki alanı için dev, test ve yaşıyor. Dosyalar için git kullanırlar ve veritabanını tek bir tıklamayla aralarında aktarırlar. Denemek ücretsizdir ve yalnızca 'canlı' olduğunuzda ödeme yaparsınız - youtube.com/watch?v=KpGTDeqwgX4
jgraup 17

Yanıtlar:


27

Gurur duyduğum bir kurulumum var ve ekibim için çok iyi çalışıyor.

Genel yapı

Tüm kurulumu devam ettim. Tüm değişiklikler, bir sistem güncellemesi yapmak, bir eklenti eklemek / güncellemek, bir tema eklemek / güncellemek, aynı iş akışından geçmek. Değişiklikler bir an önce geri alınabilir. Bir dağıtım sunucusu (eski P4 masaüstü) çalıştıran var gitosis ancak aynı kolaylıkla GitHub veya kullanabilir gitolite . Git'te iki "özel" şubem var masterve develop(aşağıda daha fazla açıklanmıştır). Üretim ve hazırlama sunucularım bulut tabanlı.

Geliştirme Ortamları

Her geliştirici kendi geliştirme sunucusunu kendi makinesinde çalıştırır. Veri tabanları açısından, canlı verilere ihtiyaç duyulması neredeyse hiç sorun olmamıştır. Biz esas olarak tema birimi test verilerini kullanıyoruz . Aksi halde ihracat ve ithalat çoğu şeyi kapsar. DB parçası çok önemliyse, çoğaltmayı ayarlayabilir ya da isteğe bağlı senkronizasyon için bir şeyler ayarlayabilirsiniz. Başlangıçta bu yapıyı kurduğumda, bunun çok önemli olacağını düşündüm, bu yüzden bunu yapmak için bir takım araçlar yazmaya başladım , ama şaşırtmak için gerçekten gerekli olmadılar. (not: gerekli olmadıkları için onları cilalamadım, bu yüzden hatalar var, örneğin seri hale getirilmiş verideki etki alanının yerini alacak).

Evreleme Ortamı

Kaydedilmesini itilir zaman developgitosis dala, bunlar otomatik bizim hazırlama sunucusuna konuşlandırılmış olsun. Aşama veritabanı, üretim veritabanının kölesidir.

Üretim ortamı

Taahhütler masterşubedeki gitosis'e itildiğinde , otomatik olarak üretim sunucusuna dağıtılır.

Wp-config.php sorunu

wp-config.phpSunucudan sunucuya benzersiz olmak istiyorsunuz , ancak sürüm kontrolü altında da tutmak istiyorsunuz. Benim çözümüm, evreleme ve üretim sürümlerini farklı adlandırılmış dosyalar olarak .gitignoreyoksaymak wp-config.phpve depolamaktı. Daha sonra her sunucuda, örneğin link wp-config.php -> wp-config-production.php. Her kullanıcı kendi DB'sini kendi kimlik bilgileriyle, kendi (takip edilmeyen) wp-config.php ayarlarıyla birlikte tutar.

Diğer notlar

Olağanüstü ve ucuz olan Rackspace Cloud kullanıyorum . Bununla evreleme ve üretim sunucularımın aynı kalmasını sağlayabilirim. Ayrıca şu anda hizmetlerini WordPress içinden kontrol etmeme izin vermek için API'lerini kullanan eklentiler de yazıyorum, bu harika.

Önbellek dizinleri, dosya yükleme dizinleri vb. Hepsi .gitignore'a eklenir. İsterseniz, yüklemeleri düzenli olarak kontrol etmek ve onları gitoza itmek için bir cron görevi ayarlayabilirsiniz.

Master / geliştirme yapısı, Vincent Driessen'in dallanma modelini kısmen taklit edecek şekilde ayarlanmıştır . Ayrıca git-flow onun git uzantısını kullanıyorum ve bunu da tavsiye ediyorum.

Bir yıldan fazla bir süredir bu yapı üzerinde çalışan 10 ya da daha fazla geliştiricim oldu ve birlikte çalışmak bir rüyaydı. Güvenilir, güvenli, hızlı, işlevsel ve çevik, daha fazlasını isteyemezsiniz!


Bir wp kurulumunu benzer bir şekilde kurmak üzereyim (ancak svn kullanıyoruz) ve eklentileri ve wp güncelleme işleminizi onaylamak istedim: güncellemeyi tamamlayın ve dev'i kontrol edin, değişiklikleri yapın, aşamalandırma için dağıtın, kontrol edin, canlı yayında. Özet olarak, depodaki güncellemeler yoluyla değişikliklere kattığınız canlı sunucuda bir wp kurulum güncellemesi yapmazsınız?
paullb,

1
Güncelleme rutini tarafından yapılan DB değişiklikleri hakkında ne. Bunlar DB üretimine nasıl etkilenir?
paullb

Bu iş akışı @ paullb doğrudur ve DB güncellemeleri hakkında endişelenmenize gerek yoktur. WordPress'in çalışma şekli, güncelleştirmeler değişiklik algılandıktan sonra tetiklenir, bu nedenle tam olarak bir manuel güncelleme (çekirdek veya bir eklentiye) çalışır!
Matthew Boynes

@MatthewBoynes, merhaba. Hala bu çalışmayı gelişiminiz için kullanıyor musunuz? öyleyse, bu iş akışını projeme uygulayacağım. teşekkür ederim :)
khakiout

Bilmiyorum, ancak yalnızca şu anda üzerinde çalıştığım ve çoğunlukla WordPress.com VIP'de barındırılan projeler için geçerli olmadığından. Uygulanabilir olsaydı, yine de kullanırdım (ve aslında, daha önce çalıştığım şirket kullanmaya devam ediyor).
Matthew Boynes

4

Öncelikle, Sürüm Kontrolüne ne yapacağınızı düşünmenin önemli olduğunu düşünüyorum . Ben öneriyoruz karşı VC altında tüm WP dizini koyarak. Wp-content / themes / YourThemeName 'i VC altına koymanın en mantıklı olduğunu düşünüyorum. Çok sayıda karmaşık eklenti içeren büyük bir site için, wp-content / plugins de dahil olmak üzere durumunu görebiliyordum. Kesinlikle yapmak zorundaysanız, wp-content / upload'leri ekleyebilirsiniz. Aşağıdaki cevaplar, neyi kontrol ettiğinize bağlı olarak biraz değişecektir.

Buna bakıldığında, işte kullandığım şey:

Yerel: Makinenizde bir LAMP yığını kurun. Geliştirme sitenizle aynı URL'yi kullanın. Geliştirme ortamını URL açısından simüle etmek için VirtualHosts ve .host dosyası girişlerini kullanın. Sadece temanızı VC yapıyorsanız, wp-content / plugins, wp-content / uploads ile bağlantı kurmak için SSHFS kullanın. Gerçekten ağır bir kaldırma yapmadığınız sürece, projenin gelişimine ilişkin veritabanını kullanmayı düşünün.

Geliştirme: Repo'nuzun çalışan bir kopyasını WP ortamınıza alın. Her repo işleminde bu repoyu güncellemek için POST-COMMIT Hook'u SVN olarak ayarlayın. Bu senkronize tutacak. (Fakir bir adamın sürekli entegrasyonunu düşünün.)

Yapım: Bir son adayı temsil eden adlandırılmış versiyon etiketine bakın. Yeni bir sürüm kullanmanız gerektiğinde, etiketi değiştirin ve repoyu güncelleyin.


Dev bir ortam, gece yapılarını test etmek için çok uygundur ve git wordpress her 30 dakikada bir otomatik olarak güncellenir, merkezileşmeden ve ekipler için daha iyi çalışır. svn kullanmak için.
Wyck

1
Tüm WP dizinini sürüm kontrolü altına almadığınız için nedeninizi merak etmeniz yeterli. Bu iş akışında bir darboğaz gibi görünüyor. WP'yi repoya koymak tüm devlere aynı kod temeli ve WP versiyonunu verir. Aynı zamanda ortamlar arasında tutarlılık sağlar. Koşullu wp-config dosyalarına Wyck'in linkini (cevabında) bakınız.
Brian Fegter

2

Son zamanlarda RAMP'i keşfettik . Not: bu işlemin sadece bir kısmıdır, ancak içerik veritabanlarını sunucular arasında senkronize etmek muhtemelen en zor kısmıdır.


2

Bunu git ve mercurial ile yapıyorum, sadece özel bir repo kullandığınızdan emin olun.

Seçenek 1.

Tek sorun git ve gitmeden önce görmezden gelmesini söyleyebilirsiniz config.php, init önce.

Kullanım .gitignoreveya git update-index --assume-unchanged config.php(kullanmadan önce farz-değişmeden komutu hakkında biraz okuyun)

Seçenek 2

Config.php dosyasında, url'yi kontrol eden ve doğru kimlik bilgilerini uygulayan bir koşullu kullanın, "eğer sunucu url = dev sonra A kodunu kullanırsa, B kodunu kullanırsanız, vb.

Mark bunu daha iyi açıklıyor, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

ps. Ayrıca geleneksel bir "dosya sunucusu" yerine, dosyaları doğrudan uzak bir depodan da sunuculayabilirsiniz. (Bu konuda http://www.youtube.com/watch?v=8ZEiFi4thDI hakkında gerçekten sıkıcı bir video yaptım )

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.