İş akışıma sürüm kontrolü nasıl eklerim?


11

Temalar geliştiriyorum, birçoğu. Bana bir PSD verildi, HTML / CSS'yi kodlayın, Wordpress'e kodu tokatlayın ve QC'd alırken düzeltmeler yapın. Yayına girdikten sonra, müşteriler normal gibi blog yayınlarını düzenleyebilir veya özel bir eklenti kullanarak fotoğraf yükleyebilir.

Bazen temada veya sayfa / yayın içeriğinde değişiklikler yapmam gerekir, bu da onları ya canlı hale getirmem ya da siteyi indirip müşteri tarafından onaylanacak bir geliştirme ortamına indirmem gerektiği anlamına gelir. Yedeklemem yok, sürüm kontrolüm yok ve bunun değişmesi gerektiğini anlıyorum.

Git ve Mercurial önerildi ve bu araçlardan yararlanmak istiyorum, ancak bunları bir iş akışına nasıl sığdıracağım konusunda kafam karıştı.

Bir geliştirme sunucusundaki bir sitedeki tüm değişiklikleri talep etmeli ve ardından onaylandıktan sonra bunları canlı yayınlamam gerekiyor mu? Blog yazıları yazmaya ne dersiniz? Dev'de yayın yazmak ve değişiklikleri canlı yayınlamak için aşırı doldurulmuş gibi görünüyor, ancak canlı sitede düzenlenmişlerse veritabanlarını nasıl senkronize edebilirim? İnterneti temizledim. Bazı rehberlik takdir edilecektir.


Bence bu kapsam dışı bir ekosistem sorusu olarak nitelendiriliyor. Devam eden tartışma için buraya bakın .
Chip Bennett

4
@ChipBennett Katılıyorum. WordPress'in temalar, eklentiler ve veritabanı arasındaki belirli bağımlılıkları ve bunların genel geliştirici uygulamalarını nasıl etkilediği açıktır.
fuxia

@toscho Kesinlikle buna ikna olabilirdim; bu yüzden Meta tartışmasına işaret ettim. :)
Chip Bennett

Yanıtlar:


9

Her şeyden önce, burada iki iş akışının olduğunu bilmeniz gerekir: sizin ve müşteriniz.

İş Akışınız

  • PSD alın
  • Kod HTML / CSS
  • Kod WordPress şablonu
  • Temayı canlı WordPress sitesine dağıtma

İş Akışları

  • Gerekli değişiklikleri yapın ve size e-posta gönderin
  • Mesaj yazma
  • Fotoğrafları yükle

Sorun

Burada sürüm kontrolü uygulamak, müşterilerinizin iş akışıyla hiçbir ilgisi yoktur. Her şey WordPress teması için kullandığınız kodu takip etmekle ilgilidir. Tüm tema dosyalarınız, özel eklentileriniz vb. Bir sürüm kontrol sisteminde olmalıdır (Git, Mercurial, Subversion veya kullanmayı seçtiğiniz her şey).

Ardından iş akışınız:

  • Kod yazma
  • Sürüm kontrol sisteminde değişiklik yapma
  • Üretim sahasında değişiklikler
  • Müşteriden yorumları geri alma
  • Kod yazma
  • Değişiklikleri yap
  • Kod yazma
  • Değişiklikleri yap
  • Üretim sahasında değişiklikler

Unutmayın, bu kodunuz için bir sürüm kontrol geçmişini korumakla ilgilidir . Kod, müşterilerinizin değişmemesi gereken bir şeydir - ve bir üretim sitesindeki kodu asla üretim sırasında değiştirmemelisiniz.

Ancak içerikteki değişiklikler (yayınlar, fotoğraflar vb.) Sürüm kontrol sisteminizin kapsamı dışındadır. Başka bir deyişle, geliştirmede değişiklik yapmaz ve sonra veritabanını üretime zorlarsınız. Bu zayıf bir geliştirme uygulaması. Dev ve prod veritabanlarının senkronize olması gerekiyorsa, rutin olarak üretim kutusundan bir yedek almalı ve yerel sürümünüzü bu yedeklemeden geri yüklemelisiniz.

Kod değişiklikleri geliştirmeden üretime akar.
Veritabanı değişiklikleri üretimden gelişime doğru akar.


İçerik verilerinin veritabanında nasıl depolandığını yöneten özel bir komut dosyanız yoksa veritabanlarını gerçekten eşitleyemezsiniz. Bu nedenle kodu iş akışınızdaki içerikten ayırırsınız, alternatif bir hazırlama sunucusu kullanmak veya db senkronizasyon komut dosyalarından birini denemek veya kendi yazmanızı yazmaktır.
Wyck

@EAMann Harika yanıt, teşekkür ederim! Açıkladığınız iş akışına ekleyeceğim tek şey, kod yazmak, değişiklikleri taahhüt etmek, geliştirme sitesine itmek, müşteriden yorum almak, ... İki ayrı iş akışını düşünmemiştim çünkü düzenli olarak müşteriler için kendimizi memnun. Bazen, içerik içindeki özel istekleri (özel stiller vb.) Karşılamak için içeriğe HTML koymamız gerekir. Bazen yayınlanmadan önce müşteri onayına ihtiyaç duyarlar, bu yüzden veritabanlarının senkronize edilmesi gerekir. Bu tür bir kurulum için en iyi uygulamalar var mı?
cfree

@Wyck Tema ile birlikte içerik bırakmak yerine, iki işlemi ayırmak mantıklı. Tema için bir geliştirme alanı ve birbirinden bağımsız düşen içerik için bir hazırlama alanı fikrini seviyorum. Gördüğüm tek sorun, müşterilerin canlı olarak yayınlamadan önce hem temayı hem de içeriği (sitenin tamamı; statik sayfalar) görmeyi sevmeleri.
cfree

Genellikle veritabanı değişikliklerini senkronize etme meselesi değildir. Ne demek istedi Eğer üretim veritabanının bir dökümü almak ve olmasıdır yerine onunla yerel geliştirme veritabanı. Doğru, bir komut dosyasıyla otomatikleştirebilirsiniz ... ancak muhtemelen çok sık yapmayacaksınız.
EAMann

3
Henüz değil, gerçekten WordPress tarafında bir diken değil, özellikle birçok CMS'nin bu sorunu olduğu için bir WordPress sorunu değil, buradan okuyabilirsiniz wordpress.stackexchange.com/questions/119/… daha derinlemesine, bazı orada senaryolar var ama çoğu evde çünkü belli bir ortama özgüler.
Wyck

1

Veritabanlarını senkronize eden bir yazılım kullanabilirsiniz. Ancak, verilerin kendisini http://chronicdb.com gibi bir şeyle sürümlendirme seçeneği de vardır.


Bu ilginç görünüyor; bazı sorunları çözebilir. Bunu kontrol edeceğim, teşekkürler.
cfree

1

Başka bir soruya bunun üzerine kapsamlı bir cevap yazdım . Şahsen git kullanıyorum ve harika. Başlamak için http://gitref.org/ ve http://help.github.com/mac-set-up-git/ adresine göz atmanızı tavsiye ederim . Kitabın türü iseniz, okumak ettik bu bir ve kesinlikle 22 $ e-kitap fiyat değer. Kendiniz yapın, bu karardan pişman olmayacaksınız.


Teşekkürler, geri dönmem gerekecek. Master / slave veritabanı kurulumu ilginç geliyor. Rehberlik için teşekkürler
cfree
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.