WordPress ve Git İş Akışı

Bu sorunun binlerce kez sorulduğunu biliyorum, ancak gerçekten WordPress ile çalışırken Git'ten en iyi şekilde nasıl yararlanabileceğimi araştırmaya çalışıyorum.

İnterneti araştırdım ve konuyu kısaca anlatan düzinelerce makale okudum. İşte son zamanlarda okuduğum en dikkat çekenlerden birkaçı.

- Sürüm Kontrolü WordPress

- Git ile WordPress Tema Dağıtımlarını Yönetme

- Özel WordPress temanızı FTP yerine git kullanarak yönetin

Şu anda, iş akışım böyle gözüküyor.

• WordPress'i yerel olarak yükleyin.
• Tema geliştir
• WordPress Veritabanlarını yerel sunucudan dışa aktarma
• WordPress Veritabanını uzak sunucuya alın
• WordPress dosyalarını ve temasını FTP yoluyla yükleyin
• Müşteri değişiklik yapar
• FTP yoluyla WordPress dosyalarını ve temasını indirin ve WordPress Veritabanlarını uzak sunucudan dışa aktarın
• Dosyaları yerel olarak değiştir
• Geliştirme değişiklikleri yap
• FTP üzerinden yeniden yükleyin, veritabanını uzak sunucuya aktarın ve alın

Git'in bu süreci kolaylaştırabileceğini biliyorum. Bunu yapmanın en iyi yolu, hem yerel hem de uzak bir wp-config.php dosyasına sahip olmanın yanı sıra, izlenmesi gerekmeyen bazı dizinleri yok sayan bir .gitignore dosyasına sahip olmak gibi görünüyor.

Fakat veritabanlarını nasıl idare ediyorsunuz? Müşteriler genellikle değişiklik yapacaktır (gönderiler / sayfalar / eklentiler). Hala uzak veritabanından veri aktarmaya ve yerel sunucuma geri aktarmaya ihtiyacım var mı?

Birisi burada benim için en iyi iş akışını önerebilir mi? Ve beni adımların içinden geçir.

Ayrıca, Bitbucket’i GitHub’ın aksine onlarla ücretsiz olarak özel repolar olarak kullanmak isterim.

Herhangi bir yardım takdir edilecektir.

Şimdiden teşekkürler!

WP Migrate DB Pro'nun geliştiricilerinden biriyim ve @ Ennui'nin sorusuna cevap vermek istiyorum:

Msgstr "Çalıştırılan db URL'sinin betiğini seri hale getirilmiş dizgilerin dikkate aldığını biliyor musunuz?"

Evet, serileştirilmiş verileri ele alıyor. Aslında, bu 2009 yılında eklentinin ücretsiz sürümünü geliştirmenin temel nedeni. :)

Ne yazık ki, yalnızca 41 itibarım var, bu yüzden @ Ennui'nin yorumuna cevap veremedi. Bunun için özür dilerim.

Bunu, “yapıcı değil” olarak kapatmak için oy kullanmaya sınır veriyorum, çünkü cevaplardan ziyade tartışma ve fikir talep edecek bir şey gibi görünüyor. Fakat...

İş akışım böyle gözükmüyor ve benim yaklaşımımı (ve cevabımı) şimdiye kadarki cevapların çoğundan farklı kılıyor.

1. WordPress'i yerel olarak yükleyin.
   1. Bu, en son kararlı sürümü içeren yerel bir çıplak Git deposundan klonlanır.
   2. Ayrıca, neredeyse her zaman yüklediğim birkaç eklentinin en son sürümünün yerel bir kopyasını da saklıyorum.
2. Temayı ve gerekli tüm eklentileri oluşturun
3. Genel bir hazırlama sunucusuna yükleyin
   1. Müşteriye erişim izni verilir, ancak kodu değiştiremez ve veritabanı düzenlemelerinin üretim sitesine aktarılmayacağını söyledi.
   2. Bu, kodu geliştirme sunucusuna geri yüklemek için hiçbir neden olmadığı anlamına gelir.
   3. Ve yerel veritabanını yeniden senkronize etmek için hiçbir neden yok
4. Çalışanlarımıza ve müşterinin geri bildirimlerine dayanarak yerel sitede değişiklikler yapın.
5. Değişiklikleri yükle
6. Gerektiği kadar tekrar edin (ancak artan dirençle :))
7. Her zaman olduğu gibi içerik sağlıyorsak, biz (müşteri değil) aşamalandırma sunucusundaki veritabanını temizler ve içerik yükleriz.
8. Yerel kodu üretim sitesine yükleyerek dağıtın.
9. Eğer içerik oluşturduysak, içerik vanilya ihracat aracıyla hazırlama alanından ihraç edilir ve üretim sahasına alınır.
   1. Bu, veritabanını taşımam gereken tek zaman ve oldukça standart araçlarla yapıldı. Ben kullanacağı Kadife Blues Güncelleme URL'ler gerekirse veritabanında temizlemek için.
10. Hata ayıklama
11. Son

Temel olarak, siteyi teslim edene kadar müşteriyi eşyalarımdan olabildiğince uzak tutuyorum.

Kod tek yönlüdür - yerelden sahnelemeye veya üretime. Asla diğer tarafa geçmez. Bu, bazı adımlarınızı ortadan kaldırır ve bana biraz huzur verir. Müşterimin kodumda titrettiği için suçlanmak istemiyorum ve sıfırdan uzak bir olasılık olan hacklenmiş bir dosyayı ithal etmek istemiyorum.

Ve veri tabanı sadece bir kez hareket eder, bu da sorunu büyük ölçüde azaltır. Bu yüzden veritabanını taşıma ihtiyacını azaltarak veya kaldırarak "veritabanı taşıma" sorununu yönettiğimi tahmin ediyorum. Ayrıca, ortaya çıkabilecek veritabanı bozulma sorunlarını azaltır ve bilgisayar korsanlığı alma şansını azaltır.

Doğru, üretim alanını yapılandırmam gerekiyor - kalıcı bağlantılar, menüler vb. - ancak bu beni üretim sahasında çalışmaya zorlar, bu yüzden bir tür hata ayıklama olduğunu düşünürüm. İşlerin üretim sahasında olması gerektiği gibi çalıştığını doğrulamama yardımcı oluyor.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Bunu henüz kendim denemedim, ancak her şeyi dağıttığını iddia ediyor - DB dahil.

Onunla gitmek için bir de öğretici var: Öğretici bölüm 1 | Bölüm 2

Ana kaya yığınına bir göz atın . Wordpress sürümünü ve üçüncü taraf eklentilerini yönetmek için besteci kullanır ve ayrıca dağıtımlar için capistrano, geliştirme için yerel sanal sunucular da dahil olmak üzere sunucuları ayarlamak için serseri / sorumludur.

Son zamanlarda bununla ilgili birçok test yaptım ve işte kullandığım iş akışı, bu da ne istediğinizi tam olarak yapıyor:

• WordPress çekirdeğini yönetmek ve wordPress'i güncellemek için wp-cli kullanıyorum.
• Eklentiyi ve tema bağımlılıklarını yönetmek için http://wpackagist.org ile birlikte besteci kullanıyorum .
• Git'i kullanıyorum ve çekirdek wp dosyalarını .gitignore'a koyuyorum. Yani çoğunlukla wp-config.php ve alt tema dosyaları gitmiş durumda.

Db geçiş araçlarına aşina değilim, ancak bu iş akışına harika bir katkı olur.

İşte iş akışının tüm detayları http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

"Klonlama" veritabanına gelince, WP Migrate DB Pro kullanıyorum: http://deliciousbrains.com/wp-migrate-db-pro/

Bu ücretli bir servistir, ancak fazla maliyetli değildir ve kolayca veritabanınızı dev sunucunuzdan canlı sunucunuza çekmenize veya çekmenize olanak sağlar. URL'leri ve yolda değiştirilmesi gereken diğer her şeyi değiştirir.